12 ms·

Having worked with neither of them my perception is that MongoDB has "better performance". While I would never rely on that for making decisions about which to

Having worked with neither of them my perception is that MongoDB has "better performance". While I would never rely on that for making decisions about which to use, I'm sure that has some real consequences, particularly where search popularity is concerned.

rdtsc 15y ago
You just don't know about the other side of the coin -- no durability to start with. You'll be flying fast, until one day you realize your data is corrupted. Not saying it is bad thing to optimize for speed, it is just a bit dishonest to downplay the negative effects especially after calling a product a DATA-base. http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of http://nosql.mypopescu.com/post/392868405/mongodb-durability... http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/ http://blog.boxedice.com/2010/02/28/notes-from-a-production-...
- latch 15y ago
  Seriously, now you are just spreading FUD. You even said a few posts up that there WAS durability. With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.
  - rdtsc 15y ago
    > You even said a few posts up that there WAS durability. When did I say that? Just cut-and-paste my phrase if you are replying to it. I don't remember saying it. > With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol. I never said MongoDB wasn't faster. It is in most situations. I was criticizing their hand-wavy attitude and what I perceived was shady marketing when it came to their trade-off. That turned me off and made me look for another product. Besides, what exactly do those implementation features mean? CouchDB has an append-only BTRee so it doesn't need journalling: http://guide.couchdb.org/draft/btree.html http://guide.couchdb.org/draft/btree.html Updates-in place are great but they again are a trade-off. Now you also need a journal. Binary protocol -- ok. That probably makes a significant difference in some case. I would actually like CouchDB to have a msgpack or protobuf driver. Not saying MongoDB is worse or better, it just works differently.

rdtsc 15y ago

You just don't know about the other side of the coin -- no durability to start with. You'll be flying fast, until one day you realize your data is corrupted. Not saying it is bad thing to optimize for speed, it is just a bit dishonest to downplay the negative effects especially after calling a product a DATA-base. http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of http://nosql.mypopescu.com/post/392868405/mongodb-durability... http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/ http://blog.boxedice.com/2010/02/28/notes-from-a-production-...

latch 15y ago
Seriously, now you are just spreading FUD. You even said a few posts up that there WAS durability. With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol.
- rdtsc 15y ago
  > You even said a few posts up that there WAS durability. When did I say that? Just cut-and-paste my phrase if you are replying to it. I don't remember saying it. > With respect to the speed of writes, MongoDB has, at least, three other things going for it [that CouchdB doesn't]: 1) the journal file is append only, 2) updates can often be done in-place, 3) a binary protocol. I never said MongoDB wasn't faster. It is in most situations. I was criticizing their hand-wavy attitude and what I perceived was shady marketing when it came to their trade-off. That turned me off and made me look for another product. Besides, what exactly do those implementation features mean? CouchDB has an append-only BTRee so it doesn't need journalling: http://guide.couchdb.org/draft/btree.html http://guide.couchdb.org/draft/btree.html Updates-in place are great but they again are a trade-off. Now you also need a journal. Binary protocol -- ok. That probably makes a significant difference in some case. I would actually like CouchDB to have a msgpack or protobuf driver. Not saying MongoDB is worse or better, it just works differently.