Hugely helpful man, thanks!

To address some of the disadvantages:

- repair database only needs to happen where the DB was shut down improperly e.g. power failure. You’d use replication to mitigate this so you can repair a database without loss of service. This lack of single server durability will be “fixed” in 1.8 later this year. We’ve never had to do a repair in over a year of usage.

- Indexing blocks but you can use background indexes to prevent that.

- Initial sync/replication is an issue with any database where you have to do a full resync

- Disk space inefficiency is resolved in the latest version and further compaction will be introduced in a future release.

- Namespace limits – do you need 24k indexes and/or collections per database?

- Map reduce is fairly slow right now – this is perhaps the only real problem that you might need to choose CouchDB over MongoDB.

It’s also important to note that MongoDB has commercial support behind it, and they are very responsive. This has been extremely useful for us.

For my app, which is a web nased surveillance system, see: http://demo1.xanview.com (user/pass: demo/demo) – I plan to predict some of the views like “large object”, “long event”, etc and when an adhoc query is needed (which I don’t think will be often), a user will be able to generate an extra view with a name and description which will show up in the interface in gray with a progress spinner until it’s finished processing as adding views doesn’t block.

All this is theory though, I’m still evaluating which database technology to choose. However it seems the MongoDB disadvantages are pretty huge: database unavailable for hours at a time when you repair, add an index, initial sync/replicate, inefficiency reclaiming disk space, inability to do master/master replication, namespace limits, no incremental map/reduce so queries are expensive.

CouchDB’s disadvantages seem to be no adhoc queries and slower with smaller loads or am I missing something?

I think the best option would be to create a separate cluster within each data centre and send queries to the appropriate cluster within the application logic.

Thanks for your posts, they’re really useful and helpful and made life a bit easier :-)

Great post David!