[kchodorow]

No one is ruling it out as being the default in the future. However 1) it was a pretty major code change and 2) this is the first release to make it publicly available.

Do you really want that enabled by default right off the bat?

[snissn]

ya i kinda want 'durability' to be enabled by default, actually

[true_religion]

I thought the whole idea behind MongoDB is to deploy at scale. In other words, deploy over 100s of boxes and don't worry about RAID, or single sever durability because at that scale any single server is liable to fail so you'll need to ensure platform-wide durability via replication.

MongoDBs killer feature was/is sharding. If your deployment isn't going to require sharding from the get go, then I'm not sure why you'd be attracted to it instead of any of the other more mature alternatives.

Adding single server durability just gives MongoDB more possible use cases (e.g. small site, single server, low overhead enviroment, etc.).

[stoneg]

Currently (mongodb 1.6.x) sharding is a killer feature that might kill yourself. It's just a marketing propaganda.

I once tried switch to sharding to avoid high write lock ratio(MongoDB use DB level lock currently, only one write operation allowed at the same time). After sharding, MongoDB even don't know how to count my colleciton. db.mycollection.count() return values at random. mongorestore also failed in sharding setup, there's no error message when I was restoring millions of documents, but after it reported successfully restored, I checked the DB, no documents there.

We switched back to more reliable master/slave setup finally. So before trying sharding, you should watch this video http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-sc... . It's so true to some extend.

[true_religion]

I've seen the video but I didn't give it much credence.

But if what you say is generally true, then MongoDB is giving a terrible showing for software that's past beta.

[stoneg]

It's true, we also experienced data loss (several millions of log data caused by dirty shutdown, it's data file is very fragile) issue like this thread http://groups.google.com/group/mongodb-user/browse_thread/th...

I found the following two posts very insightful：

1, http://www.mikealrogers.com/2010/07/mongodb-performance-dura...

"This (mongodb's write plolicy) is kind of like using UDP for data that you care about getting somewhere, it’s theoretically faster but the importance of making sure your data gets somewhere and is accessible is almost always more important."

2, http://www.paperplanes.de/2011/1/10/mongodb_and_data_durabil...

"It's okay to accept trade-offs with whatever database you choose to your own liking. However, in my opinion, the potential of losing all your data when you use kill -9 to stop it should not be one of them, nor should accepting that you always need a slave to achieve any level of durability. The problem is less with the fact that it's MongoDB's current way of doing persistence, it's with people implying that it's a seemingly good choice. I don't accept it as such."

[dm_mongodb]

development agility is a goal of the project too, in addition to scale-out. i've seen a lot of happy users with a single server (or two) and that's all they need.

[sibsibsib]

It's great for this. I'd love not having to worry about replication for small side projects.