• Zope/ZODB FAQ for IT Administrators

last modified January 21, 2009 by jonstahl

Contributions welcome!

We can't finish this document without you! If you have experience advocating for Plone in an institutional setting and/or addressing resistance from folks who object to the ZODB, please help us refine this document!

This is a space to draft a one-page FAQ for eventual publishing on plone.org.

The problem this document is intended to solve

For some potential Plone customers, such as universities and larger companies, a significant barrier to adopting Plone can be resistance from IT departments to the Zope Object Database (ZODB). This is especially common when the team responsible for hosting a Plone deployment is separate from the team responsible for the initial Plone implementation. Most of these objections trace back to the fact that the ZODB is unfamiliar, and the natural tendency of people to resist or exaggerate unknown risks.

This document is therefore intended to provide reassuring facts about the ZODB that Plone advocates can use to overcome potential objections from those who argue that Plone's ZODB backend is too different, unfamiliar and/or risky to deploy.

This document is intended to be structured as a FAQ, with a brief narrative introduction. It should be written in clear, straightforward language that will be understandable by IT decisionmakers who are unfamiliar with Plone. It should be positive in tone, factual, authoritative, and free from hyperbole or unsupported opinion. Please provide links/references to supporting documents whenever possible.

Introduction: The Zope Object Database: Simple, Stable and Scalable

Plone's database backend is the the Zope Object Database, aka "the ZODB." The ZODB is an object database system, ideally suited for the data storage needs of enterprise-quality CMS products like Plone. The ZODB is easy to maintain, extremely stable and reliable, and easy to scale via replication and clustering.

Because the ZODB is an object database, rather than a relational database, it is extremely well-suited to storing the kinds of content that most websites produce -- hierarchical content with lots of different data schemas. Because the ZODB is not a relational SQL database, it is immune to common security problems like SQL injection attacks. The ZODB's transactional nature means that it is resistant to data corruption and instability. And, best of all, because it doesn't have tables or schemas, the ZODB requires minimal maintenance from an IT team, other than routine backups and packing, which can be performed via simple shell scripts.

Frequently Asked Questions about the ZODB

Is the ZODB a relational database? Does it use SQL?

The ZODB is not a relational database. It does not use SQL.

A relational database is organized as tables of columnar data. The tables are interrelated by one or more columns of data which are repeated in separate tables. SQL is a language used to select data from one or more tables at once by specifying patterns of desired data between interrelated tables.

The ZODB is an object database. Objects are bundles of data organized in patterns which can be much more representative of real world relationships than columnar data. Some of the data in objects can be behaviors which act upon the data in an object, so that an object tends to be a self-contained bundle of data which "knows" how to process itself.

Python is the query language for the ZODB. Python is a popular object oriented programming language. Everything in Python is an object. A ZODB is simply a place to "persist" Python objects.

The objects in a ZODB are organized like a tree springing from a common root, just as objects are organized in object oriented applications. This tree is called an "object hierarchy," which means that object databases belong to a class of databases known as hierarchical databases. The difference between an object database and prior conceptions of hierarchical databases is that objects have behaviors and know how to process themselves.

The advantages of object databases over relational databases are amplified in web applications. All modern web applications are object oriented, as is the web itself. Web applications which rely on relational databases must spend resources translating objects from the programming lanaguage in which the application is implemented into tables in a database, and vice versa. This is called "Object to Relation Mapping" or ORM. Developers of web applications backed by relational databases tend to spend a great deal of effort on ORM activities. The development of many web applications is often hampered by the bad fit of forcing real world data modeled by objects into interrelated groups of tables, causing performance bottlenecks.

Developers of ZODB application use Python to simply specify the "path" to an object in the hierarchy of objects stored in a ZODB. The ZODB transparently handles the creation of objects in the application from the ZODB storage, and the persistence of objects from the application in the ZODB storage.

The ZODB is simply a way of persisting objects. The ZODB can be backed by any number of different storage mechanisms. The simplest and most maintainable is a single file containing all the objects. Another storage divides the object tree into branches, storing each branch in a separate file called a "mount point." Yet another storage is a hierarchy of files and directories, one file per object, with the directories structured like the tree of the object hierarchy.

If a relational database is an institutional must for data storage, the ZODB can be backed by a relational database for storage. The ZODB is still queried using Python. Tables within the relational database then will contain "serialized" objects instead of mapped data. ZODB mount points can also store some branches of the object hierarchy in a relational database and other branches in other storage mechanisms.

What maintenance does the ZODB require?

A key benefit of the ZODB is it's transactional nature with the possibility to roll back earlier transactions, which is known as 'undo feature' in Zope and Plone. Therefore the data of each transaction must be stored, which means the ZODB is constantly growing. The maintenance of a ZODB is mainly the deleting of transactions to reduce the size of the Database. This can be done manually via the webinterface, but there exist several solutions to automate this with a scheduler. This allows you to keep your ZODB small and always have undo data in a round robin way (e.g. the last 7 days).

Do I need any special Zope-specific knowledge to administer the ZODB?

Yes, but the required Zope-specific knowledge is limited to simple actions in the Zope webinterface which are all done with a couple of clicks. E.g. creating a mountpoint or packing the Database requires the administrator to touch Zope.

How secure is the ZODB?

The ZODB is extremely secure.  Because it does not use SQL, applications built on top of the ZODB (like Plone) are completely immune to SQL injection attacks, which plague poorly-designed SQL-backed web applications.

How do I scale and replicate the ZODB?

Zope includes ZEO (Zope Enterprise Objects) which provides a distributed object architecture to Zope sites demanding high-performance and scalability. 


Can I store Plone data in a relational database instead of the ZODB?

While the ZODB normally stores its data in a simple file on your filesystem (aka FileStorage), it is possible to have the ZODB store its data in PostgreSQL, MySQL or Oracle RDBMS backends, using RelStorage.   However, because your data are still stored as Python "pickles," this does not mean that your Plone data becomes SQL-queryable by other applications.