ZODB In Real Life

Compared to "any key-value store", the key features for ZODB would be automatic integration of attribute changes with real ACID transactions, and clean, "arbitrary" references to other persistent objects.

The ZODB is bigger than just the FileStorage used by default in Zope:

• The RelStorage backend lets you put your data in an RDBMS which can be backed up, replicated, etc. using standard tools.
• ZEO allows easy scaling of appservers and off-line jobs.
• The two-phase commit support allows coordinating transactions among multiple databases, including RDBMSes (assuming that they provide a TPC-aware layer).
• Easy hierarchy based on object attributes or containment: you don't need to write recursive self-joins to emulate it.
• Filesystem-based BLOB support makes serving large files trivial to implement.

Overall, I'm very happy using ZODB for nearly any problem where the shape of the data is not obviously "square".

I would recommend it.

I really don't have any criticisms. If it's an object store your looking for, this is the one to use. I've stored 2.5 million objects in it before and didn't feel a pinch.

I've used ZODB for more than ten years now, in Zope and outside. It's great if your data is hierarchical. The largest data store a customer operates has maybe. I don't know, 100GB in it? Something on that order of magnitude anyway.

Here is a performance comparison against Postgres.

If you're writing a WSGI web app, these packages may be useful:

• repoze.tm2 (docs)

• repoze.zodbconn (docs)