Er, wow. I don't get the impression he has any idea what's going on. The title is incredibly misleading, especially given that this is a ~2 month old post. A

Er, wow. I don't get the impression he has any idea what's going on. The title is incredibly misleading, especially given that this is a ~2 month old post. As of this writing, 1.4.x is the stable branch, with 1.5.x as the unstable. I should note that I've been running MongoDB in Production since last August. Development, deployment and go Live occurred on a pre-GA 0.9.x version and I never encountered ANY issues. With almost a year of uptime I've had no data loss or anything else. At the same time I understood I was using an unstable version and was careful to also understand what was going on under the covers. So here's the REALLY important thing you should understand if you're using MongoDB because it probably has to do with his data "loss": Data operations in Mongo, viz. insert/update are asynchronous - from both a API client and a disk-persistence standpoint. One of the things that gives you the speed boost you see from MongoDB is this concept. When your language driver sends new rows, it does NOT by default wait around to see if Mongo saved it correctly. It sends it off, makes sure MongoDB got the data and returns to you. You can force it to wait, and you can ask it for the lastError - but normally you don't wait for a "I got it in correctly" answer. Additionally, once MongoDB receives it, it goes into memory... it writes to disk lazily, rather than immediately (if you sent 1000 increment commands between the last disk write and the next, it would batch them into a single increment, etc). Yes, these things can lead to data "loss" - or the appearance thereof. If you're sending in a bad update or insert statement and not checking for errors, data will "disappear" - by which I mean it was bad data and never accepted for write.