I've been using MongoDB for well over a year now in around 6 apps (moved on from CouchDB) and I agree prior to 1.8 it should have been made more obvious that there were still some stability issues.
I have seen first hand some of the issues raised, we've had data disappear, recurring random crashes, ect. But I think the difference is 'everyone' knew that there were issues with MongoDB, you just needed to check in jira. Jumping to 1.0 too early is clearly part of the reason for this backlash as not everyone thinks to check the issues because they've come to believe 1.0 means its ready for mass adoption.
That being said, I love MongoDB and I would still use it in other apps, just got to decide if it's the right tool for the job.
Why did you move from couch? I'm considering couch for a project, and am not especially knowledgeable in the space. Couch has worked fine for a low-load, minimal-functioning prototype store (no replication needs, etc.). Its scary feature to me is dealing with compacting-- how and when to schedule it so a large db won't get bogged-down.
What I haven't tested, though, is how long compaction takes- that is, how it scales with db size and whether more frequent compaction means closer to constant scaling.
Once the prototype was up I started working on other parts of the system (and the business for that matter) and only half-paid-attention to the mailing list.
It is better to do it during downtime. You can basically provide scheduling rules such as 'compact when fragmentation % > X AND time-of-day window is Y'.
At the time, I really liked the idea of couch doc versions, but considering that go away after compaction I was sad about that it didn't give me versioning for free.
I think it just came down to preference, MongoDB has a nice way of doing quieres, without having to use views, also its a bit faster, although I've seen people speed up couch by using protocol buffers etc. Now that I havent been following couch for a while the fragmentation in between couch versions, doesn't help when evaluating if I should try it again.
I find that strange, also. It just seems like, either compact continuously (and don't make me worry about enormous dbs because of hidden files, and the trouble that can happen when it gets too large (> 1/2 disk space, so I understand)), or give easy access to the versions. I'd prefer the first, but from a user perspective (although maybe not a db-designer perspective), either-or makes sense.
That's the fallout of eventual concurrency, though.
I have seen first hand some of the issues raised, we've had data disappear, recurring random crashes, ect. But I think the difference is 'everyone' knew that there were issues with MongoDB, you just needed to check in jira. Jumping to 1.0 too early is clearly part of the reason for this backlash as not everyone thinks to check the issues because they've come to believe 1.0 means its ready for mass adoption.
That being said, I love MongoDB and I would still use it in other apps, just got to decide if it's the right tool for the job.