This article keeps coming up every once in a while and reminds me of all those “Why JS sucks”, “Never use PHP”, “Java is enterprise only”, “Ruby only works on hobby projects” etc...<p>But then in real life people built great software with all the above, so I’ll just say a great classic: pick something you know, use it well, build something good, end of story!<p>No tool will fix wrong assumptions or bad design, we can dive into philosophy here but I’m more of a practical person so... :)
Despite having used document oriented databases for many years(largely because they were shoved down my throat and I inherited someone else's architecture), I never really managed to figure out why people find them so compelling. There has been a shift in the last two years and people have started running away from them. Specifically the web-dev crowd adored them and I guess it's easy to fetch a document in the exact structure you need it but sooner or later you inevitably reach the point where you have to analyze data. And here mongo(and all the similar alternatives) become the biggest pain in the a...neck you can think of. Couchbase tried to tackle this issue with n1ql to a certain degree but at large scale it is still not particularly useful. To my mind, having a relational database which has a good architecture can't be matched by any document oriented database. But getting a large system/database right does take more effort. There are numerous ways to make relational databases incredibly scalable but again, it takes a lot more effort.
> On my laptop, PostgreSQL takes about a minute to get denormalized data for 12,000 episodes, while retrieval of the equivalent document by ID in MongoDB takes a fraction of a second.<p>What? Her database can't possibly be indexed properly.
I use MongoDB in my application. The approach I took is to store data in flat documents (relational style) and only de-normalize when necessary for performance. The relational model was invented for a reason -- it is flexible and it is easy to update data in one place and so on. The downside of relational is that joins will kill you when you have very large tables. To avoid joins, I use lookups when possible, and de-normalize only to the extend needed. I get the best of both worlds.
I first read this article while working on a project where the company had basically written a RDBMS using MongoDB. It was so many different kinds of bad I lost count.
This article appears here pretty frequently: <a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=never%20use%20mongodb&sort=byDate&type=story" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...</a>
As a sysadmin that often gets the privilege of pretending to design the smallest of complex systems, one of my regular components has been CouchDB because of its built in http api.<p>I've never been anti-Mongo, but this one little piece has made CouchDB an affordable choice for people like me who are not equipped to otherwise defend the choice.<p>Is there a missing piece that could deal Mongo back in the next time I try to convince someone that there's as straight a path to the sysadmin solutions I generally compose?
We've used MongoDB at our SaaS and have grown to well over $1m ARR and never had an issue.<p>Maybe if you're trying to build a massive ($B) company, starting with PostgreSQL makes more sense for you. For everything else, MongoDB works just fine.<p>Just use the technologies that you know and can move fastest with. Startups rarely succeed/fail because of which technologies you choose to use.
Mongo and other nosql databases are still the absolute fastest way to get started particularly you don't know what your data is eventually going to look like.
I'll never ever use MongoDB again, because every single time I've ended up running a cluster it has always been the most troubled part of my stack. I've been burned <i>way</i> too many times to ever considering touching that stove again.
I think there are two separate aspects that get conflated into one.<p>1) Document database - rather than a strict rigid schema, you can store nested json documents in tables/collections. Or the idea of soft schema where the whole database doesn't need to be blocked for a schema change and you have some leeway in integrity.<p>2) Relational database - Ability to make complex sql queries that join data from multiple tables.<p>Mongodb has some support for joining but it doesn't have a sql variant. If your data is mostly key:val store then it's great. You can shard it, and have replicas. It's easy to make a fast reliable backend with mongodb. Many popular sites run on mongodb backend.<p>However with new json types in MySQL and Postgres, it too has support for inserting documents and querying subkeys. It can be sharded and replicated (albeit with a bit more configuration).<p>Couchbase which is like mongo (in its document store capabilities) N1QL which offers agility of SQL and flexibility of JSON.<p>So like any tool, it has it's tradeoffs.<p>Then again kudus to the author for evoking our reptillian brains: "Never use MongoDB" incites emotions and gets you on top of HN. If it was called "When to use MongoDB", it wouldn't get the same reaction.
> On a social network, however, nothing is that self-contained. Any time you see something that looks like a name or a picture, you expect to be able to click on it and go see that user, their profile, and their posts. A TV show application doesn’t work that way. If you’re on season 1 episode 1 of Babylon 5, you don’t expect to be able to click through to season 1 episode 1 of General Hospital.<p>That is exactly what I'd expect, and that is how small websites like IMDB work. I am on the page for a General Hospital episode, and via the actors in the episode or whatever other part I can click through to Babylon 5, or the other way around, or anywhere else.
> But there are actually very few concepts in the world that are naturally modeled as normalized tables. We use that structure because it’s efficient, because it avoids duplication, and because when it does get slow, we know how to fix it.<p>Urmmm...How?
MongoDB + Ruby sparks joy for me. It's come a long way since 2013 and latest features like transactions (though nowhere near SQL level of robustness) are enough for my use cases. To each his or her own.
In the early tens we ran an engineering project to improve critical sections in applications using transactional memory. We had a PhD level intern applying our techniques to various open source projects. One target was MongoDB. After a few days of investigation of the Mongo source code, he had to give up because he couldn't even find the critical sections in the source. They had locking, but it was extremely convoluted.<p>So yes I would agree with that. Never use MongoDB.
If curious see also<p>2016 <a href="https://news.ycombinator.com/item?id=12290739" rel="nofollow">https://news.ycombinator.com/item?id=12290739</a><p>Discussed at the time: <a href="https://news.ycombinator.com/item?id=6712703" rel="nofollow">https://news.ycombinator.com/item?id=6712703</a>
I'm not a fan of MongoDb (although I have used it for many years) but it has its place in the market and there is need for it. "Never use MongoDb" is a clickbate title. I really wish I could down votes this post but I can't. I can only upvote unfortunately.
Ok, so besides the technical faults of Mongo within the context of its category, what is the ideal use-case of a document oriented store?<p>If you use metadata documents to model your relations you might get away with the most dangerous foot guns, but then why not jump straight into graph databases?
I'm by no means a fan of Mongo, but the product has improved quite a lot over the years.<p>Mongo now supports multi-document (and multi-node) transactions, joins, and has a decent storage engine.<p>So you might even have a chance of keeping your data actually consistent.
But it's web scale!<p><a href="http://www.mongodb-is-web-scale.com/" rel="nofollow">http://www.mongodb-is-web-scale.com/</a>
TLDR never use software architects who don't realize how MongoDB is a really bad fit for their needs. Mistakes are possible, but not thinking about requirements is negligence.