Look, traditional databases are hard: you have to think about tables, foreign keys, column types, constraints, cascading deletes - it’s all just so much work, and we’re trying to build things here! It’s simpler with Mongo: You can just drop your JSON right into it.
You don’t need to do migrations, either, which is neat - just leave any now-unused bits of data floating around in the document; the code’s not looking at it anymore, so who cares?
/sarcasm, but seriously, I don’t think adoption was ever mostly about web scale or whatever. I think it was about laziness and/or allowing people with no database knowledge to get their data persisted, and to run queries, without having to learn about relational databases or how to think about data modelling. And there’s not no value in that. But good god some of them left a mess for the rest of us.
I have run into a lot of folks who say it’s “good for prototyping.” The problem with that is that you end up building your app around that prototype instead of throwing that code out and starting from scratch. Then you want relationships within your data and have no good way of doing it. Then I pull my hair out trying to fix it.
I prefer using Postgresql for most things. It’s fast, and if you understand SQL to some extent, you can do some really powerful things relatively quickly. Sure, it’s more work to set up than slapping some JSON in there, but you can at least relate items!
Using Mongo for prototyping data is an argument for a better stack and flow.
Django alllows you to make your models and write simple tests with input data (using factoryboy or fixtures) and get very rapid turnover. Repeat that until you’re satisfied enough to make a first commit and use migrations from there on.
You just got your first logic/unit tests almost for free as well!
I’m sure all the other cool kids are doing it too.
I implemented a system that used MongoDB in 2011. The author of this piece didn’t hit on the main reason we used Mongo: automatic failover.
I didn’t need high write performance or big horizontal scalability. Easy schema modifications turned out to be more pain than they were worth, but that wasn’t the main reason.
The main reason was that I was running ops by myself at our startup. My real job was backend development. At the time, MongoDB was the only (“free”) system that we evaluated that would automatically fail over while I was sleeping, or busy working on the actual product. Elections were great (provided the quorum was set up properly). It was like RAID for databases. RDS wasn’t ready for us yet (and especially: nobody was offering managed Postgres, with failover, at a reasonable price, then). We didn’t strictly need high availability, but it sure was nice to nearly-never have to step away from Real Work™ to tend to a broken-on-the-ops-side DB (and I spent that time fixing yellow Elasticsearch clusters).
I think it was the right choice at the time, yes. But times have changed. New [small] stuff goes into managed RDS, DynamoDB, or gets set up so a DBA team can take it over (usually after migrating out of the RDS we used for development, if that’s what they want).
Could you please go into a little more detail about why you had such frequent database failures? Always curious to hear war stories like this so I can maybe identify a failure in the future and look super smart :)
We didn’t have frequent MongoDB database failures. I suppose it’s a little like that old Head & Shoulders commercial… “Why are you using H&S? You don’t have dandruff!” (Causality is hard (-: ).
I have a general policy of building everything to be HA, even when it’s not strictly needed by the business side, as long as they’re on board. When I shifted trust to the cloud (AWS in this case), instead of building out redundant pipes to our own DCs, this is cheap insurance once it’s set up.
The frequent Elasticsearch failures were due to lots of things back then. ES has matured, but I still pay Amazon to run it when I can.
I get the impression that my workplace picked MongoDB because of separation of duties. The database people worked on the database, the developers worked on the products. When the developers wanted to create a new product, they would need to drag the DBAs into the process. This might have been fine if there weren’t so many more developers than DBAs, which lead to constant bottlenecks.
Then MongoDB comes around and it’s schemaless! No need to drag the slow DBAs into the process. Go, go, go!
I imagine that lots of organizations used it as a technical solution to an organizational problem.
You can implement document storage in a relational database, but you can’t implement a relational schema in a document database. Most data is relational.
Betteridge’s Law of Headlines seems to apply.
It’s pretty refreshing to read something concerning MongoDB that isn’t firmly in the “against” camp. It seems easy to look at MongoDB through the lens of a product that needs MySQL (or whatever other non-MongoDB stand-ing you want) and say that MongoDB is terrible, but that also feels disingenuous.
The thrust of the article really rings true: considering tradeoffs x, y, and z, is adoption worthwhile? I’ve worked with MongoDB and applications that use it daily for the past 5-or-so years and found it to be pretty great. In our cases we needed none of what we would be “giving up.” We are, however, currently migrating away for a number of reasons. None of those reasons are discontentedness with MongoDB. It’s really been great.
I once worked on a product with obviously highly relational data, but the “architect” decided that Mongo was the right choice. I swear it was just because he’d come across the MEAN stack and liked the acronym.