ZODB has significant advantages over other persistence technologies. In relational databases it is hard and slow to store a tree. JSON databases do store trees but not graphs. MongoDB has problems with fine-grained transaction management across document boundaries. PostgreSQL has excellent transaction management, but does not support arrays of heterogeneous objects. And of course once you are in a pure dynamic Python environment, there are all kinds of things that you can do that you could not even imagine doing with a traditional database.
To summarize, ZODB makes it really easy to build and distribute persistent Python applications. This introductory page answers the major questins, and links to the key resources that you will need if you are considering using the ZODB.
Here I talk about various ZODB Competitors.
Here are listed 9 ZODB addons.
You can use persistent python objects directly, or with one of the multiple web frameworks built on top of them. This section introduces the different web frameworks built on top of Persistent Python Objects. It takes a historical perspective, starting with the oldest frameworks. Perhaps the most interesting ones are the newest ones at the end of the list.
There are several parts to multiple-database. Transaction management uses two phase commit to ensure that the transaction is successfully completed across all databases. Garbage collection cleans up the garbage across all databases. You also need a scheme to figure which database a particular object id is located in.
ZODB is very interesting software, very different from mainstream databases, and so it is only natural to ask about performance. Yes, it offers great speed of software development, but how does it perform at runtime. In particular a ZODB application is just a python application, with potentially lots of disk access to small python objects. And also with lots of traversals of the graph of objects, particularlly if used in Zope. So how does ZODB perform?