Unfortunately both are useless for mortals because there is no transactions and locks.
It's just impossible to write applications where uniqueness and real ACID transactions are required. Please don't send me to CouchDB bulk document API, I don't wanna dance with conflicts and inconsistency every time I am going to write simple application with user registration for example. The same for apps with direct purchases where you need to update quantity of item in stock. Just impossible. Solutions with "inventory tickets" sounds insane. Unique fields as an _id also sounds insane, because it's impossible to create complex "unique keys".
Both are cool, seriously, and you know. Lots of developers are going to use this software, but every time the lack of such features just rejecting these people.
1. Add real transactions to CouchDB/Mongo
2. Add unique indexes to CouchDB. IIRC Mongo has already.
3. Add map/reduce chaining to CouchDB
4. Dominate the world!
There are transactions in MongoDB, they just wrap one operation on one document. But that one operation can be quite complex.
Example, one op can pick a money account, decrement its balance, and push an entry to the list of outbound transfers. After a few more similarly atomic steps, you have a safe and restartable money transfer.
The upside of working with this extra complication is that your data scales via sharding far beyond the maximum size of a MySQL installation.
Both are cool, seriously, and you know. Lots of developers are going to use this software, but every time the lack of such features just rejecting these people.
1. Add real transactions to CouchDB/Mongo 2. Add unique indexes to CouchDB. IIRC Mongo has already. 3. Add map/reduce chaining to CouchDB 4. Dominate the world!