
Never, ever, ever use MongoDB - joepie91_
http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/
======
iagooar
Been there, done that. Spent over a year trying to make Mongo behave like a
decent DB, and it would still fail to do so.

Actually, I wrote a small "goodbye letter" to MongoDB on HN in the past:

"You got your chance, Mongo, and you screwed it up.

I tried getting the most out of you. I treated you like a princess, I indulged
you, your wishes became my wishes and your thoughts were my thoughts. I
stopped listening to all that criticism around you and thought of you as of a
misunderstood child, even as you would refuse to do even the easiest tasks one
could imagine.

I gave you everything there is to give, but you broke my heart. You left me in
the most critical moments. I trusted you, but you would go your own way. Tears
were shed and countless sleepless nights were to follow.

Remember that night you disappeared without leaving a sign? I sent you
messages which got a response only after many hours. You didn't give a damn
about my needs. Once, you told me: "it's not me, it's you". And I believed
you, I truly did.

It's over now. It's been some time without you, and I'm getting better. I have
discovered, that not everyone is like you. Some DBs care, they really do. You
can trust them, they give you their everything.

I'm still struggling falling in love again, but it's getting better. Don't
write me back. Goodbye."

Here's the link:
[https://news.ycombinator.com/item?id=8990754](https://news.ycombinator.com/item?id=8990754)

------
nailer
If you like laptop stickers:

[https://pbs.twimg.com/media/CF9XvchWYAEKzTp.jpg](https://pbs.twimg.com/media/CF9XvchWYAEKzTp.jpg)

Source .sketch file is in:

[https://github.com/mikemaccana/stickers](https://github.com/mikemaccana/stickers)

Joke is Alex Sexton's, I licensed font, designed, and printed them. Apparently
a couple have found their way to Mongo HQ.

------
Animats
If your site has less traffic than Wikipedia, use some relational DB. If your
site has more traffic than Wikipedia, you already have a dev team that
understands big data.

------
karmakaze
Now with PostgreSQL 9.4 there isn't really any reason to use MongoDB (JSONB is
better suited than BSON). For any other use CouchDB.

~~~
threeseed
There are a few. Mongo has excellent integration with Hadoop and is becoming
very popular in the big data analytics space. Likewise it is gaining traction
in the EDW space as a result of their partnerships.

Also it stills remains one of the simplest databases to setup and use making
it still my goto for hacks/spikes.

~~~
joepie91_
> Also it stills remains one of the simplest databases to setup and use making
> it still my goto for hacks/spikes.

It's not hard to make it easy to do a thing in the wrong way - and that's
exactly what MongoDB does. It doesn't make you set up authentication or table
schemas, so it looks 'really easy to set up'.

In reality, though, you're wasting hours to save 10 minutes. Because at a
later point, you're going to have your database broken into (if it can even be
called that, without authentication), or you end up corrupting your data
because two of your applications disagree over what the current object schema
is.

To know how easy something _really_ is, you need to compare how hard it is to
set something up _correctly_. And once you do that, MongoDB falls far behind.

~~~
djacobs
I'm all for using tools that don't make bad things easy, but I think threeseed
is saying that for hacks and spikes, the "later point" you're referring to
might not matter. (I agree that those are the only jobs I'd use Mongo for,
too.)

Of course, if you're at a company where those spikes find a way of turning
into production code, then it's a different story.

~~~
joepie91_
Realistically, though, almost always at least some portion of your hacks makes
it into production. And if you're saving 10 minutes for 5 hours lost, then
even at a going-into-production-rate of 10%, it's still not worth it.

Hacks that remain hacks in 100% of the cases, are rare :)

~~~
derefr
I've always thought it would be a great idea to create an explicit
"prototyping database" that has limitations that actually _prevent_ you from
putting it in production, no matter how small your use-case. Things like
"erases random rows after 24 hours" or "default row limit of 100; can
increment this by 100 once per day by solving a CAPTCHA."

------
toyg
I've used MongoDB recently for the first time, for an internal project. Being
schemaless, I believe it _did_ speed up development time significantly, and
allowed me to add stuff more gradually, but you could say that's just a way to
indulge a certain laziness of design. Now that the project has matured,
stepping back I can see how a relational database would be a better fit, but
if I had used a rdbms from the beginning I might have not "shipped" quite as
quickly. Swapping it out for a real rdbms will mean changing a couple of
classes anyway, nothing dramatic.

So uhm, I don't agree that it's not good for prototyping; if your final code
ends up having a decent abstraction level, it should not matter what you
picked on day 1 anyway.

~~~
joepie91_
> but if I had used a rdbms from the beginning I might have not "shipped"
> quite as quickly.

I doubt that. As mentioned in the article, migrations with rollbacks basically
solve this problem, and let you iterate through schemas quickly.

> Swapping it out for a real rdbms will mean changing a couple of classes
> anyway, nothing dramatic.

In theory, perhaps, but I have yet to see that in practice. I do freelance
code review and tutoring for a living, and in every case I've seen, a
significant amount of work would be needed to move to a different database.

~~~
toyg
_> As mentioned in the article, migrations with rollbacks basically solve this
problem_

Maybe so, but as I said above, they are _another thing to do_ at a time when
things are changing fast and one is more worried about checking whether the
application "makes sense" than proving its correctness, so to speak.

 _> I do freelance code review and tutoring for a living, and in every case
I've seen, a significant amount of work would be needed_

Well, duh: if this weren't the case, you wouldn't have been involved in the
first place :) What company calls consultants to review code they know how to
fix themselves in a few minutes?

------
vhogemann
If you're trying to use MongoDB as a relational database, and don't understand
its limitations and strengths, of course it will be terrible.

MongoDB is good if:

a) Your data model fits into the document model. Usually that means you'll be
querying only one collection at time.

b) The access pattern of your application is a lot of READs and few writes.
MongoDB has a collection lock, so it sucks for concurrent read/write
operations.

c) If you need ACID support, your operations must be restricted to a single
document.

If your problem fits on the restrictions above, you probably won't run into
many problems. We've been using Mongo to store our authentication info, and to
store payment transactions. No major problems so far, but our needs fit nicely
into what MongoDB can provide.

Most of the rants I see are from people that got burned trying to use MongoDB
as a drop-in replacement for a relational database.

------
nailer
Relationships in MongoDB are commonly stored as ObjectID references, and (at
least on node) the default Mongo client (Mongoose) makes you write schemas to
enforce these.

I think Mongo is awful too, and I'm sure there are problems with this approach
- I'd love for someone with more DB knowledge to go into details - but saying
there are 'no relations' seems to be an oversimplification.

~~~
joepie91_
Mongoose is a client-side library. It _emulates_ relations and schemas client-
side, as I also pointed out in the article.This also means that the database
cannot optimize for relations and schemas, as it doesn't even know they
_exist_.

Mongoose is also very much not the default MongoDB client in Node.js - it's a
third-party client library by Automattic. The official client according to the
MongoDB documentation is `mongodb`
([https://www.npmjs.com/package/mongodb](https://www.npmjs.com/package/mongodb)),
which does not feature relations.

~~~
nailer
I have used and am aware of node-mongodb-native (I wrote
[http://stackoverflow.com/questions/19546561/node-mongodb-
err...](http://stackoverflow.com/questions/19546561/node-mongodb-error-
connection-closed-due-to-parseerror/19546605#19546605) where we discovered it
wrapped and threw away all exceptions in callbacks in the stable production
version ), but Mongo (the company) have recommended Mongoose. The language now
is vaguer than it was 'you can use it natively if you want, or use Mongoose'
[http://docs.mongodb.org/ecosystem/drivers/node-
js/](http://docs.mongodb.org/ecosystem/drivers/node-js/)

Thanks for your excellent explanation and totally understood re: not being
able to optimise for relationships on the server.

~~~
joepie91_
I actually didn't even notice Mongoose being mentioned on that page, to be
honest, given that the instructions were for `mongodb`. I'd imagine that
neither would a developer skimming the page :)

------
dogweather
MongoDB is awful for development.

I once started consulting on a Rails app project which used MongoDB. But I was
never able to get productive: I had my development environment all set up, but
then the code wouldn't work with the development database. I pinged the other
dev:

"Oh, I made changes to the data model. I'll zip up and email you a new copy of
the dev database."

This continued for a couple of iterations and I had to quit the project
because I could never continuously get work done.

~~~
CmonDev
I thought it cannot get worse than dynamic languages, but then they invented
document databases.

------
_pdp_
I, well, one my companies, have been using mongo for a while without any
problems. I cannot comment about is reliability but as a business tool, in the
niche area we operate, it served us well. I've got nothing against relation
databases but there are not a solution to every single problem. Heck, why not
decide first if you can use flat files? Do you really need to query and join.
Not all problems require that sort of thing.

~~~
joepie91_
> I, well, one my companies, have been using mongo for a while without any
> problems. I cannot comment about is reliability but as a business tool, in
> the niche area we operate, it served us well.

The issues I listed provably exist. That you haven't run into them _yet_
doesn't change that - and quite likely, you might not even _know_ whether
you've run into it.

Losing data or having your database open to the wide internet, for example,
are two scenarios that you will likely not be aware of unless you explicitly
test for them.

> I've got nothing against relation databases but there are not a solution to
> every single problem.

And if you'd read my post carefully, you would've seen that I make no such
claim. They _do_ solve many problems, however.

> Heck, why not decide first if you can use flat files?

Flat files are rarely the correct solution. Race conditions ahoy!

> Do you really need to query and join. Not all problems require that sort of
> thing.

Many do. And even if they don't, MongoDB is _still_ not the right choice.

~~~
facetube
Postgres 9.4 even has `jsonb` and GIN indexes, which in a lot of ways provides
nicer schemaless storage than some of the NoSQL databases provide. You're also
free to mix in traditional relational tables (since `jsonb` is a data type
like any other), or even efficiently join two tables based on a JSON
containment operator. I haven't looked in to it _too_deeply, but what I've
seen so far looks really neat.

------
PebblesHD
As a smaller setup that requires far less traffic than a large scale real-time
application, what are the draw backs of just using a basic MySQL installation?
We've hit over 20k views per day on our internal wiki with no signs of even
coming close to any limits with either our hardware or the SQL stack.

~~~
rwallace
MySQL is okay. I still think Postgres is better, but the more severe of the
problems MySQL had in its early days have been fixed, and honestly it's good
enough for most sites. Certainly it's far better than MongoDb.

------
lemevi
How would one use Meteor.js without MongoDB though? Are you saying not to use
Meteor.js too? I was thinking about maybe toying with the idea of making a
fully reactive RethinkDB package for Meteor.js.

~~~
EugeneOZ
There is a wrapper for Postgre: [https://github.com/austinrivas/meteor-
postgresql](https://github.com/austinrivas/meteor-postgresql)

~~~
pm24601
yeap... but you have to give up many of the reasons for using meteor. (the
dynamic refresh, etc.)

The package is really just a simple wrapper around an npm library.

Because meteor is node-based any db that node has libraries for can be "used"
.... at the expense of giving up on most meteor features.

~~~
swsieber
IFRC, postres can notify clients of changes, so you should be able to
implement the missing features - that is to say the limitations are artificial
at this point

~~~
pm24601
"you should be able to implement the missing features" \-- me ?? not hardly -
I don't work at Meteor.

Take it up with the Meteor.com people.

------
TheHippo
Or: You could just RTFM and avoid all these issues.

For example: The message warning you that 32bit builds are not safe for
storing more than 2GB of data is larger than the download button itself. If
don't see this, you should probably be not in charge of storing any data
anyways.

Many other issues have been resolved with the 3.0 release or are documented
very clearly.

~~~
joepie91_
1\. There was no such warning for a long, long time.

2\. It's a dumb limitation, and an architectural issue as far as I'm
concerned.

3\. It still doesn't justify silently throwing away data for years.

4\. Many of the points on my list remain unaddressed, and likely never will be
addressed.

EDIT: Additionally, the typical system administrator doesn't install MongoDB
from the 'Downloads' page, but uses a package manager, and thus never sees the
warning even if it's there.

Warnings like this belong in all the relevant spots in the documentation, not
just on a download page.

~~~
cheald
That 32bit startup warning has been in place since 2009. It was in the README
in 2008 (IIRC, pre-1.0).

[https://github.com/mongodb/mongo/commit/b3322b86a014683018ac...](https://github.com/mongodb/mongo/commit/b3322b86a014683018ac81c30df0b0823bf03272)

There's plenty in Mongo to complain about, but grousing about the 32-bit
limitation just makes you look like you're bad at reading introductory
documentation.

~~~
joepie91_
This doesn't explain the data loss consequences (remember the client
default!), nor was it clearly visible on the download page - you'd have to
explicitly look for it.

This was the case until as late as 2014:
[https://web.archive.org/web/20140704182658/http://www.mongod...](https://web.archive.org/web/20140704182658/http://www.mongodb.org/downloads)

And again, the 'download' page or README is not sufficient for such a warning,
nor is a startup message a reliable place to put it (because of initscripts
and such). It should have been in all the relevant places in the
documentation, instead.

~~~
cheald
Unacknowleged writes were a bad default. I think everyone with a shred of
honesty will happily admit to that.

It was certainly in the documentation, in the blog posts, in the startup logs,
and in the README for quite a long time. If you missed it, it's probably
because you weren't paying attention. Again, there are plenty of good reasons
to dislike MongoDB, but this isn't one of them, and harping on it
substantially degrades your credibility.

~~~
joepie91_
> It was certainly in the documentation, [...] in the startup logs, and in the
> README for quite a long time.

All the wrong places, as already stated. These are not the places where
developers actually _look_. I provided some better example locations here:
[https://twitter.com/joepie91/status/622920351731843072](https://twitter.com/joepie91/status/622920351731843072)

> [...] in the blog posts [...]

Certainly not there. Go look around for MongoDB tutorials from the timespan
where unacknowledged writes were the default, and almost none of them remark
on the 32-bits limitation.

> If you missed it, it's probably because you weren't paying attention.

Nonsense. It simply wasn't in the locations where people actually look. You
can easily verify that using the Wayback Machine (and in fact, this is still
mostly the case today).

> Again, there are plenty of good reasons to dislike MongoDB, but this isn't
> one of them, and harping on it substantially degrades your credibility.

If pointing out extremely dangerous past negligence from the MongoDB
developers "degrades my credibility" in your view, then you have some very
strange ways to determine credibility.

~~~
cheald
> All the wrong places, as already stated. These are not the places where
> developers actually look.

If you're not reading READMEs, installation notes, and server logs and instead
depend on marketing splash pages to highlight the limitations of the
technologies you use, you're a bad developer. Sorry.

> Certainly not [in blog posts]

[http://blog.mongodb.org/post/137788967/32-bit-
limitations](http://blog.mongodb.org/post/137788967/32-bit-limitations)

> It simply wasn't in the locations where people actually look. You can easily
> verify that using the Wayback Machine (and in fact, this is still mostly the
> case today).

I first started using Mongo in 2010 according to my gitlogs (after it having
been on my radar for some time before that), and I very distinctly remember
reading about the 32-bit limitation well before I'd ever installed it, because
we were also using Varnish at the time, which has similar issues on 32-bit
systems because it too uses (or at least, at that time used) memory-mapped
files.

The claim that the limitation was not documented well, or was hidden, or was
generally unknown at that time is just simply false.

~~~
facetube
The word 'loss' does not appear on that page. There's a world of difference
IMO between a rejected operation (which is what I would assume from that
description – that the address space exhaustion would be detected and the
database would stop accepting writes) and irreversible data loss.

~~~
cheald
That's a consequence of their unacknowledged writes default - any write which
failed for any reason wouldn't result in a rejection as far as the client is
concerned (because the default was to shove the write request into the pipe
and then continue without waiting for acknowledgement). As I mentioned
earlier, most everyone acknowledges (heh) that as a bad default.

If you were checking getLastError on your writes, you would see the write fail
when you ran out of address space.

~~~
facetube
I guess any substantially-advanced failure mode is bound to be multi-
factorial. Makes sense; thanks for the reply.

------
sweetiewill
I actually started learning NoSQL on MongoDB but later switched over to
CouchDB and never looked back since.

Seems like a lot of other companies are too (Eg. Viber) Here's a video from
their tech team explaining the reasons behind the switch:
[https://www.youtube.com/watch?v=R5JpRrMJVIA](https://www.youtube.com/watch?v=R5JpRrMJVIA)

------
jqm
I did the MongoDB class they offer but was always scared to use in production
(after reading so many bad experiences). And it's really too bad. I find JSON
is just so much more pleasant to deal with than SQL.

~~~
bsg75
Apples and oranges. JSON is a format (Object Notation), SQL is a query
language. Some databases support queries of JSON structured data using SQL.

~~~
jqm
Sure. But I'm just stating which I'd rather deal with. Not claiming
equivalency....

Does MongoDB allow SQL queries? I didn't know that, but then again, I guess I
don't care either. I haven't looked at Mongo in a couple of years after
deciding not to use it. I do recall liking the query syntax from the class
though.

I haven't messed with JSON features in PostgreSQL yet and have no idea how
they work. That's next.

------
svisser
Not even a hackathon?

~~~
arthurcolle
If your data really doesnt matter you might as well just use ElasticSearch as
a document store, its a lot easier anyways

~~~
lemevi
I doubt ElasticSearch is easier to set up and get started with than MongoDB,
especially if you're coming from limited knowledge about either.

~~~
fiatjaf
Use Redis, then.

~~~
EugeneOZ
Actually Redis is as safe as PostgreSQL. Read the documentation please :)

------
tonymillion
This entire article in one tweet:
[https://twitter.com/tonymillion/status/417213069572714496](https://twitter.com/tonymillion/status/417213069572714496)

------
fiatjaf
I think people only use it because it stores JSON and let's you query it
arbitrarily on demand. It appears to be as good as CouchDB, but with on-demand
queries, as good as Postgres, but with JSON (!). It appears to be quick and
easy and the tool for the job.

Also, when people say NoSQL they actually mean MongoDB.

~~~
giaour
Cassandra, Couch, Redis, Riak, Dynamo...

~~~
fiatjaf
Right, I know that, but thank you for listing.

~~~
giaour
Those are the databases that most people mean when they say NoSQL.

~~~
fiatjaf
You're not authorized to speak in the name of "most people".

