joepie91's Ramblings

MongoDB is evil. It...

  • ... loses data (sources: 1, 2)
  • ... in fact, for a long time, ignored errors by default and assumed every single write succeeded no matter what (which on 32-bits systems led to losing all data silently after some 3GB, due to MongoDB limitations)
  • ... is slow, even at its advertised usecases, and claims to the contrary are completely lacking evidence (sources: 3, 4)
  • ... forces the poor habit of implicit schemas in nearly all usecases (sources: 4)
  • ... has locking issues (sources: 4)
  • ... has an atrociously poor response time to security issues - it took them two years to patch an insecure default configuration that would expose all of your data to anybody who asked, without authentication (sources: 5)
  • ... is not ACID-compliant (sources: 6)
  • ... is a nightmare to scale and maintain
  • ... isn't even exclusive in its offering of JSON-based storage; PostgreSQL does it too, and other (better) document stores like CouchDB have been around for a long time (sources: 7, 8)

... so realistically, there's nothing it's good at, and a bunch of stuff it's outright bad at. And these bulletpoints are facts, not 'just your opinion'. You can go out and verify them yourself.

For most cases, what you want is actually a relational database. PostgreSQL is a good option for these cases, and you can use a query builder or ORM to make working with it easier. In Node.js, some options are Knex (as a query builder), Bookshelf, Sequelize, or Waterline (as ORMs).

If your project involves user accounts, or any kind of relationship between two records, then you should use a relational database, and not a document store - after all, your data is relational.

If you find yourself using Mongoose, you should also be using a relational database. Libraries like Mongoose just try to (poorly) emulate schemaful relational databases using a document store, so you might as well just use a relational database directly!

Even if what you need is a document store (and again, in most cases it isn't), there are many better options available than MongoDB. Here is a list of document store databases. Note that that list is ranked by popularity, and says nothing about the quality of a database.

Never use a database because 'everybody else does', do your own research as to the advantages and drawbacks of a particular database. Popularity is largely subject to hype, and with the right marketing team, it's not hard to popularize an inferior solution.

And no, it isn't "good for prototyping" either - you just end up locking yourself into a database that can never reasonably make it into production. If your prototype is considered viable, then you're still going to have to rewrite everything using a different database.

Nearly every development ecosystem has migrations with a rollback mechanism by now, which provide a comparable ease of use for prototyping, and without the drawback of having to rewrite your code for production.

There are no valid usecases for MongoDB. It is technically inferior to other options, does not offer exclusive features that actually work, and the developers are failing to ensure data integrity and security - arguably two of the most important aspects of a database.