[LeafStorm]

Just for comparison, CouchDB has had one major bug that could cause the loss of data, detailed here: http://couchdb.apache.org/notice/1.0.1.html

The bug was only triggered when the delayed_commits option was on (holds off on fsyncing when lots of write operations are coming in) and there was both a write conflict and a period of inactivity - when the database was shut down, any writes that happened afterwards would not be saved.

They immediately worked to develop a process that would prevent any data from being lost if you didn't shut down the server, then a week later had released an emergency bugfix version without the bug. Then later they released a tool that could recover any data lost from the bug if the database hadn't been compacted.

That's the kind of attitude database developers need to have towards data integrity.

[itaborai83]

One of the things that I love about Couch is that the standard way to shutdown the process is simply doing a kill -9 on the server process. No data loss. No Worries. Want to back up your data? rsync it and be done with it.

Couch may have its warts, but it is damn reliable.

[maxogden]

I've heard from many people that with Couch you get "all of your disappointment up front"

[itaborai83]

I feel that Couch has too much server side programming. It can be off puting sometimes. If anyone wants to make some money, I'd suggest them putting a server on top of a couch cluster that receives mongo queries.

I mean, how hard can it be to

1) Manage some indexes,

2) Keep some metadata around and

3) Build some half-assed single index query planner?

Couch is already a solid piece of technology. It just needs a better API to "sit" on top of it, kinda like what Membase is doing now.

edit: or on top of Riak, Cassandra, PostgreSQL or etc ... on the API side, Mongo has clearly won.

[markazevedo]

Which is to say, not much?