I'm sorry but I hate ZODB with a passion.<p>- It does not scale.<p>- Poor support for replication or sharding.<p>- It is slow. Really slow. Un-pickle every time you get something from cache.<p>- It is error prone. Forget a commit or forget to handle conflict errors and you're in big trouble.<p>- No interoperability. Want to write a service in C++ to access your db? You're out of luck.<p>- As your system grows you'll have conflicts all over the place.<p>- Some server side stuff needs to have your objects, e.g. if you want to do conflict resolution.<p>- Migrations/change to schemas are painful, once you change your object you're no longer going to be able to de-serialize it.<p>- You have to roll your own if you want change notifications.<p>So if you're just looking to persist some Python objects in a small system, great. Otherwise I'd stay away from this.
The ZODB is and was a Python pickle store in the first place. The question about what makes a "database" can be answered differently. Functionality like indexes and query languages are in the Zope world application level functionality build on top of the ZODB. The ZODB turned out being a database solution for many large scale projects (up to several 100 GB). There are options for sharding (mount points) and replications (ZRC, Relstorage). The ZODB is unlikely the solution that you would use nowadays for "big data" however keep in mind that the ZODB is already 15 years old and severed many people in professional solutions for more than a decade. We know of many businesses still using the ZODB in mission critical applications. But yes, the ZODB is an object store and not a RDBMS - it's a completely different beast - like always: use the right tool for each project. And the ZODB was already "NoSQL" by the end of the 90s of the last millennium. No need to hate the ZODB - it is just another database option - and in some case I would still use the ZODB today over tinkered garbage database solutions like MongoDB having a braindead replication and sharing model.
I had to work with ZODB on a couple of projects and it has been overall a rather painful experience. Inability to run ad hoc queries and necessity to manage indexes and maintain consistency at the application level has been a source of annoying bugs for me. Not worth it IMHO.
ZODB is kind of neat, but how does it fare with non-python client libraries? I note the phrase "you can store anything that is pickleable" so I am thinking not?
If you like ZODB (like me), you might also like DyBASE: <a href="http://www.garret.ru/dybase.html" rel="nofollow">http://www.garret.ru/dybase.html</a><p>BTW I used ZODB to add persistence and acknowledgment to the Python Queue class: <a href="http://blog.databigbang.com/adding-acknowledgement-semantics-to-a-persistent-queue/" rel="nofollow">http://blog.databigbang.com/adding-acknowledgement-semantics...</a>
If you are interested in object-oriented databases for Python check out Durus: <a href="https://www.mems-exchange.org/software/DurusWorks/" rel="nofollow">https://www.mems-exchange.org/software/DurusWorks/</a><p>It's design is based on ZODB but with a number of simplifications and no dependencies on Zope.