At first, the descriptions of CouchDB and Tokyo Cabinets sounded suspiciously like multivalued databases, such as Reality and UniVerse (both circa 1970). CouchDB is a RESTful web service package, which has a storage engine that uses MVCC (Postgres, Oracle, InnoDB), and b-tree indexes (used by most RDBMSs), with sequence ids (supported by most RDBMSs). So, really comparing CouchDB to MySQL or Postgres is to compare apples and baked tarts made with apples. The Tokyo Cabinet SourceForge project says: "Tokyo Cabinet is a library of routines for managing a database. The database is a simple data file containing records, each is a pair of a key and a value. Every key and value is serial bytes with variable length. Both binary data and character string can be used as a key and a value. There is neither concept of data tables nor data types. Records are organized in hash table, B+ tree, or fixed-length array. As for database of hash table, each key must be unique within a database, so it is impossible to store two or more records with a key overlaps." A blog writer says: "Tokyo Cabinet is a simple, small, fast key/value store. Similar to DBM, it’s a very basic database. If you combine it with Tokyo Tyrant, it becomes a very capable, scalable network database (like mysql or couchdb)." So, is CouchDB's storage engine any more performant in a flexible CMS situation like Drupal than SQL storage engines? That remains to be seen. There's no obvious reason why it should be, since it does pretty much everything an RDBMS does (indexing, ACID compliance, etc.). CouchDB does provide some extras which could be useful, such as the built-in views already mentioned. And its document orientation might be great for large files (images, documents, etc.). Would the RESTful API be an advantage over SQL? And Tokyo Cabinets -- hmmm. Serialized data versus structured data and database wide unique keys. DBM primitives? Again, it remains to be seen whether it's faster than an SQL engine when combined with something like Tokyo Tyrant to provide the needed concurrency capabilities. ..chris