16 ms·

Never use MongoDB (2013)

131 points by mikecarlton 6y ago

deleted 6y ago
[deleted]
eatwater123 6y ago
Unless you want to.
nchase 6y ago
This article appears here pretty frequently: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=never%20use%20mongodb&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
manishsharan 6y ago
plot twist .. use MongoDB api /drivers on Document Layer on FoundationDB ;-)
williesleg 6y ago
C'mon man!
offtop5 6y ago
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.
- jayd16 6y ago
  Changing SQL schema is honestly just not that hard... but even still, you can always use json columns in postgres if you don't want the db to enforce a schema.
  - vosper 6y ago
    Agreed, I've never understood this. There are lots of good migrations tools around for SQL databases. If people mean "you don't need to run migrations with Mongo, you can just start adding fields to documents as they're accessed, and clean up as-needed" then... don't do that. That's how the Mongo DB I am responsible for was managed for most of the last 10 years. It's a nightmare now, we can barely change it at all.
  - offtop5 6y ago
    If your just prototyping you don't need a schema. Complaining mongo doesn't scale is like saying your Mita can't off-road
    - Scarbutt 6y ago
      If you are prototyping a local file will do, or store json in a text field in sqlite, or in a json column in postgres. You will even have more flexibility than mongo since you will not have the constraint of their document data model.
      - offtop5 6y ago
        Only your last option will allow me to send a webpage link to a friend for him to try it. The idea is if you have just a couple of days to crack out of MVP you don't want to waste time with postgres or whatever. The problem ends up being then your boss is like, all right this works keep going with it
        setr 6y ago
        I don't understand why postgres w/ json enables a website, where sqlite and text files don't. You just ship the sqlite/text file with the rest of the webserver code? It's less work than setting up mongo, postgres, or whatever long-running data store. Just deploy the web application... and you're done.
        offtop5 6y ago
        So that would make sense, if it's purely for show. For a recent project we actually used firebase but I wanted to enable myself to update the database without redeploying the website. I generally dislike when people try to write off a technology just because they don't know how to use it. Don't hammer in screws, but it doesn't mean you should throw out all of your hammers
        deleted 6y ago
        [deleted]
  - yawnxyz 6y ago
    yeah json columns are a game changer and will definitely "disrupt" nosql usage, at least for my own projects
- adwww 6y ago
  This is what the company I work for claimed. Now we are 10 years old and have a monster of a relational database stored in MongoDB. There's never a good moment to switch database, but there is always a new problem caused by storing relational data in a document store.
- ogre_codes 6y ago
  Before PostgreSQL added BSON support this may have been true, but now it's pretty easy to build an SQL database that you can extend arbitrarily just like with Mongo. You probably shouldn't use that too much, not for anything remotely production, but it's there if you need that flexibility or an easy place to dump javascript objects. When you are just getting started, it's super easy to manipulate SQL data structures regardless.
- setr 6y ago
  I disagree -- an RDBMS is pretty much safe/sane for any design, though it may not be the fastest. NoSQL databases (specifically, eventually consistent DBs) are only safe/sane in specific scenarios. If you don't know what your needs are, you should always start with an RDBMS -- it's not that difficult to go "up" to a NoSQL db from there (you're only losing information, and if you can't safely move because of loss of ACID... you'd probably have been really fucked if you started off without it), but you can't easily migrate back "down" to the RDBMS -- a NoSQL database stores almost no information about your data or its constraints. And your application will almost always want transactional guarantees and to model relationships properly -- generally only small chunks of the design (design-wise; data-wise it might be 90% of the app) can be treated with eventual consistency and have real scaling needs, which you can shift over to your nosql system. Apps are generally just metadata tracking with a dash of real work.
  - yawnxyz 6y ago
    as a UX designer / product engineer, it's easier for me to jump into a nosql than to wire up a postgres instance for a small proof of concept project that I know won't really go anywhere
    - nucleardog 6y ago
      sqlite? All my proof of concept (and some production) stuff just uses that until I need features or concurrency that it can’t provide.
    - ndiscussion 6y ago
      Sorry, this might come off as obtuse, I don't mean it that way. Perhaps I'm misreading your title, but I find it odd that a UX designer or product person would be the one writing proofs of concept that require a database. Unless you mean for solo projects? In that case, it may work for you, but if you're not a database expert, it makes sense you would work around your limitations. That doesn't necessarily mean it's a best practice.
- 35fbe7d3d5b9 6y ago
  Careful here: while this may be true of some NoSQL stores that I've not used, this is a tarpit for the wide column datastores I'm familiar with (Dynamo, Cassandra, and others). It's very easy to get going quickly and find out that you've tripped over antipatterns, and now your database is "a database, a Ruby app, and 30ms of latency on every call". It's easy to think "I'll model this later" and end up hitting the database five times in a row to answer a question. With these systems, up front modeling of your data model and access patterns is essential if the trade off you are trying to make (far less functionality for smooth performance at ridiculous scale) will ever make sense.
jonstaab 6y ago
> 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. What? Her database can't possibly be indexed properly.
- mywittyname 6y ago
  Yeah, this sounds like a design defect. But since the author doesn't really describe what they did, it is hard to really figure it out. I'm guessing this is some sort of query with a self-join going on, where the mongo request is a basic fetch by id.
  - mbreese 6y ago
    The use of the term “denormalized” suggests to me that it was a query that involved a lot of joins. Which is certainly something that could have been otherwise addressed with a different design. Comparing fetching from a normalized design to a denormalized one isn’t really a fair comparison.
    - dathinab 6y ago
      I fear the problem is that the person doesn't do joins but separate sub-queries which then get recombined in RAM in the client. Given the software stack described there is a realistic chance of this happening implicitly due to ORM mappers. But then the way tables don't map well to 1-to-many mappings and joins still returning data in tables this can also be a problem. Especially if a large field get duplicated a lot. RDBMS really should go from 2d-Tables to proper nested types for results IMHO.
      - fabian2k 6y ago
        That would be nice, though I suspect that it is really much more complicated than it seems. You can emulate this to some extent in Postgres with the various JSON functions and essentially return a tree from a single query. But my experience was that I quickly got to a point where the query plan got really complex and planning time started to dominate.
petepete 6y ago
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.
- throwawayboise 6y ago
  That's the problem with using document databases when you really need an RDBMs. You end up reimplementing an RDBMS, badly.
  - mywittyname 6y ago
    It's so painful to come onboard projects that should have been designed originally in an RDBM, but that was never a consideration because, "they are slow." People fight the migration tooth and nail until it becomes nearly impossible to move forward.
fortran77 6y ago
But it's web scale! http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/
flowerlad 6y ago
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.
- Mavvie 6y ago
  You can do all that with SQL too. And do you have any very large tables? > joins will kill you when you have very large tables nitpick, but table size doesn't directly matter (much). if your queries are very specific and only return a couple rows, then you can have huge tables and join across them without issue. Joins only get particularly painful if you're doing aggregation/reporting queries across large parts of it
  - interlocutor 6y ago
    SQL databases don't support easy schema evolution, sharding and so on.
    - SomeCallMeTim 6y ago
      PostgreSQL directly supports table sharding. https://pgdash.io/blog/postgres-11-sharding.html https://pgdash.io/blog/postgres-11-sharding.html Schema evolution is supported by pretty much every ORM you'd care to use; it's not the job of the SQL database to handle the migration. I'm using Prisma and you literally change the software spec for the schema and say "migrate", and it creates the migration SQL and applies it to the Postgres DB programmatically. That gets you deterministic schema evolution and not the "my schema isn't actually reliable" that NoSQL/no-schema databases rely on. And then you have CockroachDB/YugabyteDB that give you extreme horizontal scalability, with full PostgreSQL compatibility... And bang, the last reason to use MongoDB vanishes.
      - 6y ago
deleted 6y ago
[deleted]
cyxxon 6y ago
> 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. 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.
01acheru 6y ago
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... 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! No tool will fix wrong assumptions or bad design, we can dive into philosophy here but I’m more of a practical person so... :)
- larrik 6y ago
  This advice is fine for programming languages, but not for data stores. Using them incorrectly (or in MongoDB's case and sometimes MySQL's, correctly) could lead to things like data loss or crashed servers. Simply building your product on one of them is not proof they are good enough.
  - Geminidog 6y ago
    No, there are programming languages that are just plain bad to use, his philosophy is wrong not only for datastores but for reality in general. All tools, including programming languages can be bad no matter the skill of the user.
    - artificial 6y ago
      Found the person that doesn't like BrainF*ck. /s
      - redwall_hp 6y ago
        With Excel as a data store!
    - 01acheru 6y ago
      Glad to see that you actually know what is right ;) All tools can be bad, but that means that probably you cannot use it well or build something good with it. Every good enough tool can be used to build something good enough, or else it wouldn’t be good enough. And it’s also realistic to assume that every tools popular enough is good enough for something. But you see, it’s starting to get philosophical over here
ashtonkem 6y ago
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 way too many times to ever considering touching that stove again.
- ryanianian 6y ago
  What do you mean by "troubled," and what docs did you follow to set up and run the cluster? Caring and feeding for a database (of any type) with any type of HA has a learning curve. Hence the growing number of PaaS services that handle the setup and maintenance for you (AWS's RDS, Mongo's Atlas, etc)
  - cj 6y ago
    MongoDB's own management software (Cloud Manager, Ops Manager) is littered with bugs to the point where it's nearly unusable for certain actions. (One of which being restoring backups) It was really, really bad 3-4 years ago. Regularly entering irrecoverable error states while performing basic management operations via MongoDB's management GUI. I've noticed a significant improvement in the past ~1 year.
  - ashtonkem 6y ago
    By troubled I mean it would regularly go into what I called "three stooges" mode where each node swore that another was the master. Of course this would mean that writes would stop dead in their tracks. Given that this happened to me across companies, teams, and a half decade of time, I've decided that this is a case where the problem is Mongo and not me.
    - ryanianian 6y ago
      The only constant there is you which means it is perhaps you. Setting up and caring for a DB cluster is a complicated thing, to the point of there being non-BS certification courses for nearly every major HA database including Mongo. It very well could be that there was a well-documented flag that you never learned. This doesn't mean you're being unreasonable. I'd be cranky with any DB getting itself in a split-brain scenario, but my conclusion wouldn't be a bug in the software but rather it's a bug in my understanding. It's worth noting that getting in this state should either be impossible, or it should be obvious about how it arrived at such a state with links to relevant documentation. (There's also little incentive to make it super easy to run in production on your own. They sell that as a service after all. It wouldn't surprise me if the product had invariants that assumed production-level configurations and that nobody's tested with whatever configs ended up making it go nuts.)
jasondc 6y ago
This article from 8 years ago highlights how far MongoDB has come: transactions, left outer joins ($lookup), etc.
- nickkell 6y ago
  How many years before it reaches feature parity with a traditional RDBMS though? And when will it get a query language as good as SQL? That said, I will admit the change streams feature is amazing. That completely changed the way I thought about building reactive applications
- ashtonkem 6y ago
  The issue is that MongoDB isn't chasing a fixed target. RDBMS have gotten better in the mean time.
axegon_ 6y ago
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.
- w0m 6y ago
  > why people find them so compelling My theory is that it's easy to add a field by adding logic into the app instead of munging tables relationships. Moves the logic to where developers are more comfortable. Scalability/etc is irrelevant for most use cases anyway.
  - hnarn 6y ago
    > Scalability/etc is irrelevant for most use cases anyway. I literally can't parse what you mean by this
    - nailer 6y ago
      Most apps don’t get a lot of traffic
    - w0m 6y ago
      I'd guess 95% of what we use databases for; actual performance of the database is irrelevant.
- whatsmyusername 6y ago
digitalsushi 6y ago
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. 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. 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?
- jacobwilliamroy 6y ago
  mongo-express maybe? https://github.com/mongo-express/mongo-express https://github.com/mongo-express/mongo-express But if couchDB works, it works. Personally I'd love to shoehorn LISP into everything I do, but most of the time I just use python and bash because things tend to get done faster when I do.
a13n 6y ago
We've used MongoDB at our SaaS and have grown to well over $1m ARR and never had an issue. 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. Just use the technologies that you know and can move fastest with. Startups rarely succeed/fail because of which technologies you choose to use.
- bdcravens 6y ago
  If your data store is nothing but a persistence layer for an application, perhaps that makes sense. In many companies the need to regularly access the database for analytics and BI is a thing; this isn't limited to $B companies. Most of the tooling available works best with SQL databases. (Though the BI connector at https://docs.mongodb.com/bi-connector/current/ https://docs.mongodb.com/bi-connector/current/ looks interesting for this purpose)
alpineidyll3 6y ago
For the record we use mdb in production, and it's been fine.
leke 6y ago
> 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. Urmmm...How?
dudeinjapan 6y ago
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.
eecc 6y ago
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? 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?
andikleen2 6y ago
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. So yes I would agree with that. Never use MongoDB.
the_duke 6y ago
I'm by no means a fan of Mongo, but the product has improved quite a lot over the years. Mongo now supports multi-document (and multi-node) transactions, joins, and has a decent storage engine. So you might even have a chance of keeping your data actually consistent.
franklyt 6y ago
SQL is a solution to a problem in the vein of prematurely optimizing for many use cases where mongodb is called for.
dang 6y ago
If curious see also 2016 https://news.ycombinator.com/item?id=12290739 https://news.ycombinator.com/item?id=12290739 Discussed at the time: https://news.ycombinator.com/item?id=6712703 https://news.ycombinator.com/item?id=6712703
AtlasBarfed 6y ago
Jepsen review 2020: https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 ... not good.
nojvek 6y ago
I think there are two separate aspects that get conflated into one. 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. 2) Relational database - Ability to make complex sql queries that join data from multiple tables. 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. 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). Couchbase which is like mongo (in its document store capabilities) N1QL which offers agility of SQL and flexibility of JSON. So like any tool, it has it's tradeoffs. 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.
amir734jj 6y ago
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.
HelloNurse 6y ago
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.

131 points by mikecarlton 6y ago

deleted 6y ago

[deleted]

eatwater123 6y ago

Unless you want to.

nchase 6y ago

This article appears here pretty frequently: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=never%20use%20mongodb&sort=byDate&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

manishsharan 6y ago

plot twist .. use MongoDB api /drivers on Document Layer on FoundationDB ;-)

williesleg 6y ago

C'mon man!

offtop5 6y ago

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.

jayd16 6y ago
Changing SQL schema is honestly just not that hard... but even still, you can always use json columns in postgres if you don't want the db to enforce a schema.
- vosper 6y ago
  Agreed, I've never understood this. There are lots of good migrations tools around for SQL databases. If people mean "you don't need to run migrations with Mongo, you can just start adding fields to documents as they're accessed, and clean up as-needed" then... don't do that. That's how the Mongo DB I am responsible for was managed for most of the last 10 years. It's a nightmare now, we can barely change it at all.
- offtop5 6y ago
  If your just prototyping you don't need a schema. Complaining mongo doesn't scale is like saying your Mita can't off-road
  - Scarbutt 6y ago
    If you are prototyping a local file will do, or store json in a text field in sqlite, or in a json column in postgres. You will even have more flexibility than mongo since you will not have the constraint of their document data model.
    - offtop5 6y ago
      Only your last option will allow me to send a webpage link to a friend for him to try it. The idea is if you have just a couple of days to crack out of MVP you don't want to waste time with postgres or whatever. The problem ends up being then your boss is like, all right this works keep going with it
      - setr 6y ago
        I don't understand why postgres w/ json enables a website, where sqlite and text files don't. You just ship the sqlite/text file with the rest of the webserver code? It's less work than setting up mongo, postgres, or whatever long-running data store. Just deploy the web application... and you're done.
        offtop5 6y ago
        So that would make sense, if it's purely for show. For a recent project we actually used firebase but I wanted to enable myself to update the database without redeploying the website. I generally dislike when people try to write off a technology just because they don't know how to use it. Don't hammer in screws, but it doesn't mean you should throw out all of your hammers
      - deleted 6y ago
        [deleted]
- yawnxyz 6y ago
  yeah json columns are a game changer and will definitely "disrupt" nosql usage, at least for my own projects
adwww 6y ago
This is what the company I work for claimed. Now we are 10 years old and have a monster of a relational database stored in MongoDB. There's never a good moment to switch database, but there is always a new problem caused by storing relational data in a document store.
ogre_codes 6y ago
Before PostgreSQL added BSON support this may have been true, but now it's pretty easy to build an SQL database that you can extend arbitrarily just like with Mongo. You probably shouldn't use that too much, not for anything remotely production, but it's there if you need that flexibility or an easy place to dump javascript objects. When you are just getting started, it's super easy to manipulate SQL data structures regardless.
setr 6y ago
I disagree -- an RDBMS is pretty much safe/sane for any design, though it may not be the fastest. NoSQL databases (specifically, eventually consistent DBs) are only safe/sane in specific scenarios. If you don't know what your needs are, you should always start with an RDBMS -- it's not that difficult to go "up" to a NoSQL db from there (you're only losing information, and if you can't safely move because of loss of ACID... you'd probably have been really fucked if you started off without it), but you can't easily migrate back "down" to the RDBMS -- a NoSQL database stores almost no information about your data or its constraints. And your application will almost always want transactional guarantees and to model relationships properly -- generally only small chunks of the design (design-wise; data-wise it might be 90% of the app) can be treated with eventual consistency and have real scaling needs, which you can shift over to your nosql system. Apps are generally just metadata tracking with a dash of real work.
- yawnxyz 6y ago
  as a UX designer / product engineer, it's easier for me to jump into a nosql than to wire up a postgres instance for a small proof of concept project that I know won't really go anywhere
  - nucleardog 6y ago
    sqlite? All my proof of concept (and some production) stuff just uses that until I need features or concurrency that it can’t provide.
  - ndiscussion 6y ago
    Sorry, this might come off as obtuse, I don't mean it that way. Perhaps I'm misreading your title, but I find it odd that a UX designer or product person would be the one writing proofs of concept that require a database. Unless you mean for solo projects? In that case, it may work for you, but if you're not a database expert, it makes sense you would work around your limitations. That doesn't necessarily mean it's a best practice.
35fbe7d3d5b9 6y ago
Careful here: while this may be true of some NoSQL stores that I've not used, this is a tarpit for the wide column datastores I'm familiar with (Dynamo, Cassandra, and others). It's very easy to get going quickly and find out that you've tripped over antipatterns, and now your database is "a database, a Ruby app, and 30ms of latency on every call". It's easy to think "I'll model this later" and end up hitting the database five times in a row to answer a question. With these systems, up front modeling of your data model and access patterns is essential if the trade off you are trying to make (far less functionality for smooth performance at ridiculous scale) will ever make sense.

jonstaab 6y ago

> 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. What? Her database can't possibly be indexed properly.

mywittyname 6y ago
Yeah, this sounds like a design defect. But since the author doesn't really describe what they did, it is hard to really figure it out. I'm guessing this is some sort of query with a self-join going on, where the mongo request is a basic fetch by id.
- mbreese 6y ago
  The use of the term “denormalized” suggests to me that it was a query that involved a lot of joins. Which is certainly something that could have been otherwise addressed with a different design. Comparing fetching from a normalized design to a denormalized one isn’t really a fair comparison.
  - dathinab 6y ago
    I fear the problem is that the person doesn't do joins but separate sub-queries which then get recombined in RAM in the client. Given the software stack described there is a realistic chance of this happening implicitly due to ORM mappers. But then the way tables don't map well to 1-to-many mappings and joins still returning data in tables this can also be a problem. Especially if a large field get duplicated a lot. RDBMS really should go from 2d-Tables to proper nested types for results IMHO.
    - fabian2k 6y ago
      That would be nice, though I suspect that it is really much more complicated than it seems. You can emulate this to some extent in Postgres with the various JSON functions and essentially return a tree from a single query. But my experience was that I quickly got to a point where the query plan got really complex and planning time started to dominate.

petepete 6y ago

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.

throwawayboise 6y ago
That's the problem with using document databases when you really need an RDBMs. You end up reimplementing an RDBMS, badly.
- mywittyname 6y ago
  It's so painful to come onboard projects that should have been designed originally in an RDBM, but that was never a consideration because, "they are slow." People fight the migration tooth and nail until it becomes nearly impossible to move forward.

fortran77 6y ago

But it's web scale! http://www.mongodb-is-web-scale.com/ http://www.mongodb-is-web-scale.com/

flowerlad 6y ago

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.

Mavvie 6y ago
You can do all that with SQL too. And do you have any very large tables? > joins will kill you when you have very large tables nitpick, but table size doesn't directly matter (much). if your queries are very specific and only return a couple rows, then you can have huge tables and join across them without issue. Joins only get particularly painful if you're doing aggregation/reporting queries across large parts of it
- interlocutor 6y ago
  SQL databases don't support easy schema evolution, sharding and so on.
  - SomeCallMeTim 6y ago
    PostgreSQL directly supports table sharding. https://pgdash.io/blog/postgres-11-sharding.html https://pgdash.io/blog/postgres-11-sharding.html Schema evolution is supported by pretty much every ORM you'd care to use; it's not the job of the SQL database to handle the migration. I'm using Prisma and you literally change the software spec for the schema and say "migrate", and it creates the migration SQL and applies it to the Postgres DB programmatically. That gets you deterministic schema evolution and not the "my schema isn't actually reliable" that NoSQL/no-schema databases rely on. And then you have CockroachDB/YugabyteDB that give you extreme horizontal scalability, with full PostgreSQL compatibility... And bang, the last reason to use MongoDB vanishes.
    - 6y ago

deleted 6y ago

[deleted]

cyxxon 6y ago

> 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. 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.

01acheru 6y ago

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... 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! No tool will fix wrong assumptions or bad design, we can dive into philosophy here but I’m more of a practical person so... :)

larrik 6y ago
This advice is fine for programming languages, but not for data stores. Using them incorrectly (or in MongoDB's case and sometimes MySQL's, correctly) could lead to things like data loss or crashed servers. Simply building your product on one of them is not proof they are good enough.
- Geminidog 6y ago
  No, there are programming languages that are just plain bad to use, his philosophy is wrong not only for datastores but for reality in general. All tools, including programming languages can be bad no matter the skill of the user.
  - artificial 6y ago
    Found the person that doesn't like BrainF*ck. /s
    - redwall_hp 6y ago
      With Excel as a data store!
  - 01acheru 6y ago
    Glad to see that you actually know what is right ;) All tools can be bad, but that means that probably you cannot use it well or build something good with it. Every good enough tool can be used to build something good enough, or else it wouldn’t be good enough. And it’s also realistic to assume that every tools popular enough is good enough for something. But you see, it’s starting to get philosophical over here

ashtonkem 6y ago

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 way too many times to ever considering touching that stove again.

ryanianian 6y ago
What do you mean by "troubled," and what docs did you follow to set up and run the cluster? Caring and feeding for a database (of any type) with any type of HA has a learning curve. Hence the growing number of PaaS services that handle the setup and maintenance for you (AWS's RDS, Mongo's Atlas, etc)
- cj 6y ago
  MongoDB's own management software (Cloud Manager, Ops Manager) is littered with bugs to the point where it's nearly unusable for certain actions. (One of which being restoring backups) It was really, really bad 3-4 years ago. Regularly entering irrecoverable error states while performing basic management operations via MongoDB's management GUI. I've noticed a significant improvement in the past ~1 year.
- ashtonkem 6y ago
  By troubled I mean it would regularly go into what I called "three stooges" mode where each node swore that another was the master. Of course this would mean that writes would stop dead in their tracks. Given that this happened to me across companies, teams, and a half decade of time, I've decided that this is a case where the problem is Mongo and not me.
  - ryanianian 6y ago
    The only constant there is you which means it is perhaps you. Setting up and caring for a DB cluster is a complicated thing, to the point of there being non-BS certification courses for nearly every major HA database including Mongo. It very well could be that there was a well-documented flag that you never learned. This doesn't mean you're being unreasonable. I'd be cranky with any DB getting itself in a split-brain scenario, but my conclusion wouldn't be a bug in the software but rather it's a bug in my understanding. It's worth noting that getting in this state should either be impossible, or it should be obvious about how it arrived at such a state with links to relevant documentation. (There's also little incentive to make it super easy to run in production on your own. They sell that as a service after all. It wouldn't surprise me if the product had invariants that assumed production-level configurations and that nobody's tested with whatever configs ended up making it go nuts.)

jasondc 6y ago

This article from 8 years ago highlights how far MongoDB has come: transactions, left outer joins ($lookup), etc.

nickkell 6y ago
How many years before it reaches feature parity with a traditional RDBMS though? And when will it get a query language as good as SQL? That said, I will admit the change streams feature is amazing. That completely changed the way I thought about building reactive applications
ashtonkem 6y ago
The issue is that MongoDB isn't chasing a fixed target. RDBMS have gotten better in the mean time.

axegon_ 6y ago

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.

w0m 6y ago
> why people find them so compelling My theory is that it's easy to add a field by adding logic into the app instead of munging tables relationships. Moves the logic to where developers are more comfortable. Scalability/etc is irrelevant for most use cases anyway.
- hnarn 6y ago
  > Scalability/etc is irrelevant for most use cases anyway. I literally can't parse what you mean by this
  - nailer 6y ago
    Most apps don’t get a lot of traffic
  - w0m 6y ago
    I'd guess 95% of what we use databases for; actual performance of the database is irrelevant.
whatsmyusername 6y ago

digitalsushi 6y ago

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. 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. 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?

jacobwilliamroy 6y ago
mongo-express maybe? https://github.com/mongo-express/mongo-express https://github.com/mongo-express/mongo-express But if couchDB works, it works. Personally I'd love to shoehorn LISP into everything I do, but most of the time I just use python and bash because things tend to get done faster when I do.

a13n 6y ago

We've used MongoDB at our SaaS and have grown to well over $1m ARR and never had an issue. 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. Just use the technologies that you know and can move fastest with. Startups rarely succeed/fail because of which technologies you choose to use.

bdcravens 6y ago
If your data store is nothing but a persistence layer for an application, perhaps that makes sense. In many companies the need to regularly access the database for analytics and BI is a thing; this isn't limited to $B companies. Most of the tooling available works best with SQL databases. (Though the BI connector at https://docs.mongodb.com/bi-connector/current/ https://docs.mongodb.com/bi-connector/current/ looks interesting for this purpose)

alpineidyll3 6y ago

For the record we use mdb in production, and it's been fine.

leke 6y ago

> 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. Urmmm...How?

dudeinjapan 6y ago

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.

eecc 6y ago

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? 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?

andikleen2 6y ago

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. So yes I would agree with that. Never use MongoDB.

the_duke 6y ago

I'm by no means a fan of Mongo, but the product has improved quite a lot over the years. Mongo now supports multi-document (and multi-node) transactions, joins, and has a decent storage engine. So you might even have a chance of keeping your data actually consistent.

franklyt 6y ago

SQL is a solution to a problem in the vein of prematurely optimizing for many use cases where mongodb is called for.

dang 6y ago

If curious see also 2016 https://news.ycombinator.com/item?id=12290739 https://news.ycombinator.com/item?id=12290739 Discussed at the time: https://news.ycombinator.com/item?id=6712703 https://news.ycombinator.com/item?id=6712703

AtlasBarfed 6y ago

Jepsen review 2020: https://jepsen.io/analyses/mongodb-4.2.6 https://jepsen.io/analyses/mongodb-4.2.6 ... not good.

nojvek 6y ago

I think there are two separate aspects that get conflated into one. 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. 2) Relational database - Ability to make complex sql queries that join data from multiple tables. 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. 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). Couchbase which is like mongo (in its document store capabilities) N1QL which offers agility of SQL and flexibility of JSON. So like any tool, it has it's tradeoffs. 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.

amir734jj 6y ago

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.

HelloNurse 6y ago

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.