Bigger news is that Jepsen tests are now part of the MongoDB continuous integration suite: <a href="https://evergreen.mongodb.com/build/mongodb_mongo_master_ubuntu1404_jepsen_bf4385aed5e528a8cf1edb7955c8c2164dda04f0_16_10_28_14_33_06" rel="nofollow">https://evergreen.mongodb.com/build/mongodb_mongo_master_ubu...</a><p>Open and available for everyone to see, for every build of MongoDB. Is there another database that has this much transparency? (for every build)
MongoDB receives a fair amount of criticism here but the company is a fantastic place to work. I'm proud that I was able to learn and grow as a developer alongside all of those who have been trying (and succeeding) to make a great database.<p>The team at MongoDB really cares a lot about making the best database product possible. I knew it when I was there and still think so after I've left.
It's been a long way from the "Call Me Maybe: MongoDB" post from years back. Aphyr/Kyle took them to task in so many ways for playing fast and loose with data integrity, and rightly so. MongoDB could have said, "that guy's full of BS, ignore him," but instead they did the smart thing and paid Kyle to help solve the problem.<p>n.b. I can't find the original "Call Me Maybe" post, but this later one [1] is similar.<p>[1]: <a href="https://aphyr.com/posts/284-jepsen-mongodb" rel="nofollow">https://aphyr.com/posts/284-jepsen-mongodb</a>
I hadn't noticed this before, but aphyr has an elaborate and articulate ethics policy: <a href="http://jepsen.io/ethics" rel="nofollow">http://jepsen.io/ethics</a><p>I like it.
MongoDB 3.4 passes the rigorous and tough Jepsen test. Jepsen designs tests to make databases fail in terms of data consistency, correctness, and safety... MongoDB 3.4 passed through their newest tests.<p>I think that this really shows how mature of a Database MongoDB is.
I think this is 10th year of MongoDB's existence. This year they seem to be having not just popular but good product. It will be interesting to see if ratio for Good/Popularity is similar for most non-traditional databases.
Good news to hear!
We just finished a fairly big IoT project where we needed to ship a replicated database which was fast, easy to deploy and reliable. We tried other DBs but none was so stable to be shipped with a standalone application completely black boxed to the customer. I was septic in the beginning but after 800 installations in 2 month we have no complains. Also not from early adopters which run now for appr. a year.
This is great news. Historically I've accepted the risk of data loss and coded checks when needed. I will never rely on my database, regardless of which one I am using for complete data consistency. It is, however, nice to see strides being made towards even better robustness. Go MongoDB!
I see many people say that Mongo is unfot for a production db, but it is actually used in production by many companies.<p>Obviously this is true of many products, but how serious is it in practice? The criteria for 'good enough' can't be passing Jespen because very few db's do.<p>Storing schemaless json is a very valid use case. And the fact is there aren't really many proper NoSql alternatives, other than RethinkDB, which I hope becomes popular, and maybe Couch. e.g. Cassandra is often touted but its a k-v store, not a document db.<p>There's a reason Mongo became and continues to be popular. I still think Rethink is superior in every way.
I know there are a lot of bad vibes on HN about MongoDB, but I also know several companies which MongoDB enabled with the right libraries to much faster iterate on "schema" and business requirements (in their growth phase) than with other databases at that time (some years ago). The schemaless approach of MongoDB suited their fast changing needs much better than e.g. RDBMs.<p>What currently still makes MongoDB nicer than e.g. Postgres JSON are the libraries embracing schemaless while JSON in PG libs still feels tacked on.<p>Recently I had some bad experience with MongoDB support though.<p>No experience with RethinkDB.
These 'from the ground up' totally all-new-code approaches to DBs are just a scary proposition. Think of the thousands of man-years of effort that went into building MySQL, testing its codebase, and perfecting it's robustness (fail-proof-ness). What does MongoDB bring that couldn't have 'built on top' of MySQL codebase, and used MySQL transational layer as it's underpinnings. Sure, MongoDB gets all its performance gains from delaying writes to the DB (eventually consistent), caching in memory, and dispensing with ACID, however there is nothing about MongoDB that couldn't have been written to use the DB layer of MySQL at the point where it actually does its writes to disk. In this way, MongoDB would have revolutionized the world rather than mostly "fragmenting" the storage space.<p>I guess there are those who will say that even using batch-commits, that MongoDB could never have achieved the performance it currently does (by bypassing any ACID) if it was built on top of MySQL. But regardless, why not focus efforts on improving MySQL batch processing performance rather than throwing it all out, starting from scratch, and writing directly to disk. I know MongoDB became a success, but I think that is 'in spite of' their decision to start from scratch and not 'because of' it. Also think of the power that would be available if there were some relational table capability (true real MySQL ACID) right inside MongoDB whenever it was needed, if they were the 'same animal', rather than having to use two totally and completely separate DBs if you need NoSQL and also ACID in an app, which 99% of apps DO NEED, at some point, once an app grows beyond the round-one funding startup-toy phase and MongoDB falls flat in it's RDB capabilities.