
Does everyone hate MongoDB? - dmytton
http://blog.serverdensity.com/does-everyone-hate-mongodb/
======
jandrewrogers
I think a lot of the "hating" is a side effect of MongoDB being consistently
oversold in terms of its capabilities and architecture. Many people who are
not experts on databases discover this the hard way later. If the claims about
it were qualified a little better and the limitations acknowledged more openly
by its proponents it would help to mitigate this outcome.

I am indifferent to MongoDB but I do caution people that the internals and
implementation are quite primitive for a database engine. It is the sort of
database engine that a programmer that knows little about database engines
would build. Over the years that has repeatedly manifested as problems no one
should ever expect a database engine to have if properly designed. There is a
reasonable point where you should not have to read the documentation to see if
your database has a basic design flaw; there is an assumption of competent
architecture for its nominal use cases.

MongoDB has improved in this regard over time and many other popular NoSQL
(and SQL) databases have similar problems. Users are being asked to cut the
database some slack for less than competent engineering choices but users just
want a database to work. Being "simple" isn't enough.

~~~
diego
I like the concept of MongoDB. My main problem (which perhaps is not totally
clear from my post, linked in the article) is that there are certain
historical conventions about what a database should be. In particular, a
database will not have the following default behavior:

\- return from a write call silently, when the data wasn't written and will
not be.

If you are going to break conventions on a multi-decade tradition, there
should be warnings everywhere. Not just the Downloads page, but during
installation (which is harder to ignore, as the Download page is not seen by
people like me who use package managers).

The 32-bit issue is worse. There's no excuse for not warning people that the
server they just started is a crippled data store limited to 2GB.

Again, I like MongoDB. Given my experience with software development, those
issues are telltale signs of a product in its infancy. Hence the "10 years"
title of my post, which of course is hyperbole. But it will take time for
Mongo to be user-friendly enough.

By the way, those who say that a piece of software has no need to be as user-
friendly as possible, and you should thoroughly read the manual before even
experimenting with it simply live in a different world. The more of a head
start the software can give you, the better. The fewer the gotchas, the
better. That was the philosophy of IndexTank, and it worked.

~~~
pooriaazimi
I haven't got a 32 bit version of Mongo, but people pointed out in the other
thread that 32-bit version of mongod displays a little warning every time you
start it saying it can handle only 2GB of data.

Can you confirm this ( _because I don't have the 32-bit version installed_ )?
It still stinks, especially because it "silently failed after hitting the
threshold", but I personally would feel better about 10gen if this little
story is true (i.e. they warn you about it not only in downloads page, but
every time you run mongod).

~~~
jeremyjh
Yes that is true for me, at least using the 10g binaries for Linux (not the
Ubuntu package). You get this warning everytime you start the engine. You'd
probably have to look at your logs to see it. It is also referenced in the
installation documentation.

Look guys, MongoDB uses a memory-mapped file. How can it be larger than 2GB on
a 32-bit system? There should not need to be "warnings everywhere".

~~~
Saavedro
I think expecting end-users to know or care about the implementation detail of
a memory-mapped file is even sillier than all the other silly expectations
floating around this thread.

~~~
jeremyjh
You are right I would not expect end-users to know this. I would expect
someone who writes articles about DBMS to know this though.

------
Zak
My problems were to do with data-loss and unrecoverable corruption. I didn't
write a blog-rant, but maybe I should have.

I have since learned that I could have changed some configuration options to
make MongoDB less likely to corrupt and/or lose data. I'm still wary though -
the fact that the default configuration was prone to unrecoverable data loss
suggests that any time I use MongoDB, I must carefully research the feature
I'm using to make sure I don't do it in a way that causes data loss.

I believe dangerous configurations should never be the default, and dangerous
features should be clearly labeled. The default method for writing data should
not fail silently, for example. The fast, fire-and-forget write should be
called something like "unchecked_write".

~~~
pjungwir
It's not just that the defaults are dangerous, but that if you change the
default, you give up much of the performance benefit of choosing Mongo in the
first place.

~~~
taligent
Sorry but NOBODY is choosing MongoDB purely based on speed.

If they were they would go with something like MemSQL, Redis etc.

~~~
rdtsc
They did it more when it first came around. Redis wasn't in the same category.
It was usually compared to CouchDB, another one I don't remember, and then
traditional SQL DBs. Couch for example looked much worse in benchmarks because
it tried a bit harder to take care of users' data and didn't just fling it
over the fence. But it mostly lost out because OMG benchmarks!

------
calinet6
This is a nice summary of many of the problems with MongoDB, and a good set of
fumbled excuses as to why they might not actually be problems. Most of the
answers boil down to "Well, yeah, but if you know how to [long complicated
solution here], then it's not a problem," while simultaneously admitting that
the problem is present and that the solution (if it exists) is extremely
difficult and requires specialized knowledge.

All I can do is laugh and keep on using Postgres...

~~~
einhverfr
Interestingly I just wrote an article on dzone (published in their NoSQL zone
;-) ) about building encapsulated data models on PostgreSQL. I discuss a bunch
of ways of doing this. I totally agree with the idea that one should
encapsulate data in application, but that's what an RDBMS is for if you know
how to use it.

My approaches to db interfaces have been greatly inspired by REST and SOAP.
The thing is giving up on the RDBMS is usually the _wrong_ choice. If using
NoSQL, usually it is best as an adjunct to the traditional RDBMS (particularly
for pre- and post- processing).

------
colinhowe
We've been using MongoDB in production for our main content store at
Conversocial for over a year now. We've gone from 1.8 to 2.0 to 2.2 and we're
happy. We have ~400gb of data, 220 million documents all on Amazon's SSD
instances.

We have definitely had our moments where we've screamed that we hate Mongo and
are going to rip it out. That's normally where we've overlooked a detail of
how it works... and we've had this same experience with every database
technology we use - including MySQL and Redis.

The day after, when we've cleared our heads... we're happy again. The same as
the other technologies.

I think that with all technologies you're going to get bitten by some detail
you didn't know about or had forgotten. The trick is to mitigate these
disasters by thinking about your failure cases.

~~~
23david
At our company we have a much bigger MongoDB dataset in production. I can
relate well to your comments, since it is the same stuff that I hear from our
developers as they defend Mongo after yet another horrific situation. They
have a tough time admitting that Mongo is the problem, and instead always find
ways to say that it was their fault.

This is such a strange thing for me to observe, but I think that it has to do
with the fact that MongoDB works so smoothly initially with a default install
that it hooks you in, and then later when you have a large dataset and it
stops working well, it's hard to understand how what was such an amazing
technology can now fail so badly.

It's also a huge problem that once you run MongoDB at scale, you desperately
need experts to fix things, but it's so hard to find any so-called experts who
can help. 10gen did a great job of marketing to developers, but unfortunately
they seemed to spit in the face of DBAs and Ops people a long time ago by
proclaiming them to be unnecessary and archaic. Running any significant
MongoDB database in production requires as much expertise as someone running a
big MySQL instance, but there isn't a community of database lovers around
MongoDB who you can hire.

The DBAs and operations people I know dislike or even hate MongoDB, often for
valid reasons that 10gen should address such as the as-yet-unfixed 'write
lock' issue, code instability and inaccurate/misleading documentation. 10gen
has done a great job at evangelizing to developers and making features that
developers love. Now that 10gen has so much money, I hope that they can now
afford to start making MongoDB a database that Ops people and DBAs can love.

As a final note, this ServerDensity guy is clearly looking at the world
through mongo-colored glasses. It makes sense I suppose since he is all-in
with MongoDB for his company. But we were using his service up until three
months ago, and had a lot of problems with intermittent performance issues
that seemed to be database-related since the site was still working and only
certain pages would take 30 seconds or so to load. It's possible that the
problems were temporary and no longer exist, but it brings home my point. If
MongoDB experts can't make their own services 100% reliable, what hope does a
regular startup have of getting MongoDB to work well at scale.

A developer may feel comfortable making the decision to go with MongoDB, but
if they are wrong it won't cost them their job and they won't need to pull
their hair out dealing with Ops issues all the time. If a DBA or Ops guy is
being hired to manage a company's datastores, I don't see MongoDB (even 2.2)
being a contender. At this point there are simply other DBs available that can
perform the same or nearly the same without all the fussiness. Developers may
be unhappy since nothing yet is as easy to develop on, but they'll be happier
in the end when stuff 'just works'.

~~~
taligent
> But unfortunately they seemed to spit in the face of DBAs and Ops people a
> long time ago by proclaiming them to be unnecessary and archaic.

WTF ? I have never heard 10gen say anything remotely like this. And it surely
hasn't come across in their marketing. I mean seriously. Which developer
thinks that in a production environment they are going to be the ones
supporting the database ? Nobody.

> If MongoDB experts can't make their own services 100% reliable, what hope
> does a regular startup have of getting MongoDB to work well at scale.

The fact that you base your impression of MongoDB based on ZERO evidence just
conjecture that the slowness of their site is database related says a lot
about you too. There are many other reasons it could equally be: app server,
network etc.

> If a DBA or Ops guy is being hired to manage a company's datastores, I don't
> see MongoDB (even 2.2) being a contender.

Have you even worked at an enterprise company before ? DBA/Ops aren't the ones
in control. If the development team wants MongoDB installed and have business
justification it gets installed.

> Developers may be unhappy since nothing yet is as easy to develop on, but
> they'll be happier in the end when stuff 'just works'.

But it does 'just work' that's the whole point. Developers aren't stupid and
MongoDB is not the only database around. You just need to (god forbid)
understand how the thing works.

~~~
mun2mun
> But unfortunately they seemed to spit in the face of DBAs and Ops people a
> long time ago by proclaiming them to be unnecessary and archaic.

>>WTF ? I have never heard 10gen say anything remotely like this.

From the "Ease of use" section of their Philosophy page
<http://www.mongodb.org/display/DOCS/Philosophy>,

    
    
       This means that MongoDB works right out of the box, and you can dive right into developing your application, instead of spending a lot of time fine-tuning obscure database configurations.
    

There goes the indirect jab to the RDBMS DBAs wasting their time.

~~~
taligent
How on earth do you equate that statement with "we don't need a DBA when we
get into production" ?

Do you need a DBA to get MySQL running ? No. Oracle ? No. SQL Server ? No.
That's all it means. Normal people understand that there is a difference
between getting something running and deploying it into production.

~~~
mun2mun
Point me a doc(or a tiny little red note link, like in the 32 bit installer
download page) where 10gen says that you will need a dedicated MongoDB DBA to
maintain production server. You see 10gen marketing machine have successfully
created a perception that MongoDB is so much magical that you don't have to
worry about data. New programmers with less knowledge in RDBMS are buying this
argument. And most of the time they start into development just after reading
basic tutorial. This the problem GP is trying to address.

------
benatkin
Does everyone hate MongoDB? - 25 Sept 2012

Headline Problem: Too many people are ranting about MongoDB.

Mistake: Too few data points. Overly defensive of MongoDB.

Comments: You should probably learn more about Riak. The "From MongoDB to
Riak" is light on details but isn't really hand-waving. The author is saying
that having a masterless database results in less fretting.
<http://wiki.basho.com/Riak-Compared-to-MongoDB.html>

Also, why two rage faces? Can't you get your point across without resorting to
silly memes?

~~~
jchrisa
Now that Couchbase Server 2.0 is beta, it's a reliable alternative to MongoDB.
Same JSON goodness, different set of user stories. (hint: less rants). Get the
beta download here: <http://www.couchbase.com/couchbase-server/beta>

~~~
pooriaazimi
If you (like me) don't know what's the difference between CouchDB and
CouchBase, look here: <http://www.couchbase.com/couchdb>

------
danso
> _Comments: The 32 bit limit is noted (perhaps it should be a warning) on the
> download page but the main problem was the author did not know when writes
> started to fail. MongoDB uses unsafe writes by default in the sense that
> from the driver, you do not know if the write has succeeded without a
> further call to getLastError. This is because one of the often cited use
> cases for MongoDB is fast writes, which is achieved by fire and forget
> queries._

(in reference to I’ll Give MongoDB Another Try. In Ten Years,
[http://diegobasch.com/ill-give-mongodb-another-try-in-ten-
ye...](http://diegobasch.com/ill-give-mongodb-another-try-in-ten-years))

I read the referred article and the HN discussion...but wasn't quite able to
tell how much of the debate was focused on the reasonability of this default
rather than "developers should read the docs, or accept catastrophic failure"
attitude (which is not inherently wrong).

What immediately comes to mind is the Rails ActiveRecord update_attributes
vulnerability...the default was to allow the updating of all specified
attributes with the assumption that no competent developer would trust
unsanitized input from the browser. After a good Samaritan performed a
spectacular hack on Github, the Rails team immediately changed the default.

Is that the situation here with the 32-bit silent fail default? That it is a
sensible default, but could be changed if it's shown that competent devs will
nonetheless screw it up?

~~~
bunderbunder
_Is that the situation here with the 32-bit silent fail default? That it is a
sensible default, but could be changed if it's shown that competent devs will
nonetheless screw it up?_

It's kind of sad that we'd need an example to show that it really could happen
in every single specific case. It should be common knowledge by now that
competent devs screw things up all the time.

For example, I'm sure the MongoDB devs are extremely competent. But all the
same, having a database management system default to letting writes fail
silently is a pretty spectacular screw-up. I can't really blame other
competent devs for taking it for granted that a DBMS wouldn't do something
like that.

------
linuxhansl
Let's not conflate "hating" (which is always pointless) with pointing out
flaws in a design.

"Mongo sucks f*cking balls" is hating it. "Mongo silently does not store data
in some situations" is pointing out a flaw.

It is easy to dismiss valid criticism as hate. It is also unfortunately true
that some topics degenerate to flamewars on HN. Why Mongo is such catalyst is
a phenomenon in itself. One that I find fascinating.

------
jeffdavis
"Getting your working set in memory is one of the most difficult things to
calculate and plan for with MongoDB."

I am a little bothered when I see a working set described as though it was a
property of the user or workload.

A large part of database research has gone into allowing the user or the
system to make the working set smaller. An obvious example is an index, which
makes the working set smaller if you don't mind a random I/O or two per lookup
(of course, that only works for indexable queries).

There are also many operations in a database which try to work within a
limited amount of memory, and therefore must have a small working set
regardless of the data size. Sort and HashJoin are two examples. HashJoin
doesn't tell _you_ what the working set of your data is, _you tell it_ and it
works as efficiently as it can in that amount of memory.

And you can design your data layout to have a smaller working set (again, so
long as you allow a few disk accesses outside the working set). Normalization
and vertical partitioning (i.e. splitting a table up into several tables with
fewer columns each) can help here.

So, the "working set" isn't some passive constant that can't be managed.

~~~
marshray
Isn't one of the defining characteristics of Mongo-like systems that they tend
to aggressively favor using RAM to achieve performance? I.e., their strategy
is to complete each query as quickly as possible rather than attempt to
optimize for fairness of long-running transactions.

~~~
jeffdavis
I wasn't referring only to long running transactions. Indexes are clearly a
way of reducing the working set (at least in a practical sense) but also vital
for workloads with many short transactions.

I was not criticizing mongo per se, I was criticizing this post and other
misguided statements about the working set as it relates to database software.

~~~
marshray
OK, it just seemed to me that the stated goal of Mongo-like servers was to
take some of our accepted notions of the "working set as it relates to
database software" and put them up for fresh discussion.

------
Lazare
MongoDB is really easy to get started with. It's easy to install on a VM, and
it's easy to try it out on Heroku. There's drivers for a bunch of languages,
and its API works in a way that fits well with the way programmers already
think. It dispenses with pretty much everything that makes getting started
with a new database hard (schemas, new syntax, unfamiliar concepts, needing to
edit server configs).

MongoDB "just works" out of the box for testing and development. It's
practically the perfect database for any testing and development work. And
their marketing documentation tells you that it'll just work in production and
will scale really well. That makes a _lot_ of people try MongoDB, and they're
mostly very happy with it.

...the problems arise later. Because while MongoDB lives up to the hype for
testing and development, it doesn't completely live up to the hype for
production uses. It doesn't always scale that well. It isn't always as durable
as you might hope. Performance isn't always very good. For some use cases, the
default settings aren't appropriate; for other use cases the database design
itself isn't appropriate. Backups and replication aren't quite as easy as
you'd hope.

In short, the problem comes because MongoDB is as good or better than, say,
Postgres or Riak during development in basically every way, but it's only
better than Postgres or Riak in a few specialized ways during production.

Example: Riak basically won't work at all in a multi-tenant setup. Two
competing services will provide you with a free development MongoDB instance
on Heroku, but nothing of the kind exists for Riak; you basically need to roll
your own cluster. That makes MongoDB really easy for someone thinking "hey, I
wonder if Mongo would work for this proof of concept I'm working on" (hint: it
will). Of course, MongoDB replication and scaling is honestly mediocre, while
Riak's is basically magic. This makes Riak a better choice for someone who
needs to scale a cluster of database servers - but you only find out that sort
of thing first-hand during production. At which point, you make an angry blog
post that hits Hacker News. And while plenty of people never run into MongoDBs
weak areas, they never post anything that hits the Hacker News frontpage. :)

TL;DR: A lot of people hate MongoDB because it's amazingly easy to get started
with, but harder later on, and they then feel betrayed. Other databases have
smoother learning curves.

------
davidw
I had to use it a few years back, for some data reporting that had been added
to a project after the fact, and... I found it to be awful, because the task
was very much a join-heavy operation. Something that would have been a breeze
with Postgres, or even Mysql got turned into this big, ugly, heavy, slow
process. I was not impressed, especially since the quantity of data in the DB
was also something that could have very, very easily been handled by a very
conventional relational DB running on a VPS, to say nothing of dedicated
hardware.

Basically, they had chosen MongoDB due to the 'cool/new' factor, and it came
back to bite them on the ass.

~~~
einhverfr
>" I found it to be awful, because the task was very much a join-heavy
operation. Something that would have been a breeze with Postgres, or even
Mysql got turned into this big, ugly, heavy, slow process. "

If you can't be assured of structure of data input, you can't reliably and
gracefully transform that data on output. That's a pretty fundamental tradeoff
between SQL and NoSQL (and historically between PostgreSQL and MySQL too).

------
netvarun
You beat me into writing this =) Great article, btw!

It seems to me that there are three camps of people when it comes to dbs - (1)
The "I hate anything new" camp, (2) The "I hate anything old" camp, and
finally (3) The "I will pick the best tool suited to my needs"

Those from camp (1) are the ones who hate anything that IS NOT relational or
sql. The mongodb bashers would fall in this camp.

Those from camp (2) are those who hate that IS relational or sql. The "web-
scale" people would flal in this camp.

Those from camp (3) are the silent majority who do their independent research,
pick the right type of DB for their job, and live life happily.

For my startup (Semantics3), we deal primarily with JSON strings (which have
no fixed structure). We use MongoDB because a really good use case for it is
to just store JSON documents with a unique id. We only run simple queries on
it - basically existential (does an id exist) or count.

We are aware that it's query performance is not as fast as that of a
relational db. So we then index that data to ElasticSearch and run our
advanced queries through that. We are really happy with our current system and
it has been working great.

If we had some sort of "relational" data with a fixed structure I sure has
hell would have picked MySQL or PostgreSQL and used Sphinx on it for indexing.

Peace.

~~~
netvarun
Hmm, why the downvotes?

------
rdtsc
Does everyone hate infomercial salesmen that sell crap at 4am in the morning
on TV? I don't know. Some do some don't.

Those that see through the lies are probably laughing at them, those that
already bought the product and found out it is useless and doesn't live up to
touted capabilities probably hate them.

Now don't get me wrong. In a practical way (disregarding ethical
consideration) they took a risk. They quickly gained a lot of customers
because their benchmarks looked very good.

So in a certain way people probably already forgot about the competitors at
that time, because those competitors never made it so far. Now MongoDB is here
years later and stories of hidden data corruption (and this is one of worst
thing that could happen to a database) have started to emerge. Yes, by this
time Mongo has the mind-share but now it is time to also pay the price for
their design choice. They are probably still ahead.

------
bcoates
This article isn't exactly inspring me to give MongoDB a shot. I wasn't even
aware Map-Reduce in MongoDB was single-threaded, doesn't that defeat the
entire purpose? Isn't Map-Reduce an embarrassingly parallel algorithm?

If they're using a single-thread JS engine, can't they just multiprocess? No
shared state, after all...

------
ericcholis
While I haven't gone full production with MongoDB yet, it has been a struggle
to hear the signal through the noise.

I'm glad that there are proponents of MongoDB like ServerDensity, it's nice to
hear the other side of things from people who understand the issues.

Out of all the issues mentioned, I'm particularly interested in a fix for
uncompressed field names.

~~~
josegonzalez
That is very trivial to do in your ORM if you so choose - and something like
the Li3 PHP framework (lithium) would handle this quite nicely.

To be honest, I'd rather have on-the-fly compression of data fields. At the
moment I need to do this on my end, but it would be nice to be able to mark
fields as compressible. Ah well.

~~~
ericcholis
Agreed, lithium user here :-)

------
thedz
heh, I thought the domain sounded familiar:

[http://blog.serverdensity.com/removing-memcached-because-
its...](http://blog.serverdensity.com/removing-memcached-because-its-too-
slow/)

------
jeffdavis
It's not about "hating", or at least I hope it's not.

NoSQL, in many ways with MongoDB leading the charge, came on to the scene very
quickly with a lot of support on HN. When action outpaces education, then it's
natural to expect education to play catch-up for a while, which is what's
happening now.

Some of it is education by 10gen, some by users who made mistakes (the leading
cause of education), and some by traditional database people who want to
highlight the lessons learned that might have been missed by 10gen or mongo
users.

Generalizing all of this as "hate" is not productive.

------
illumen
You mean the mug, the tshirt or the database? The mug, and tshirt have been
quite good. Haven't tried the db.

~~~
benatkin
You raise a valid point. If this essay by pg holds true, you might be better
off sticking to PostgreSQL (the other pg):
<http://paulgraham.com/javacover.html>

~~~
z92
Just finished reading it for first time. Clearly pg was wrong. It now reads
like one of those classic wrong predictions.

------
jeffdavis
"Many suggest this default is a good way to get favourable benchmarks but
there are no official ones so I don’t think that’s relevant."

Sure it is. People download MongoDB, run some simple workload against it, and
see how fast it is. It's not an official benchmark, but it's still a strong
part of the marketing message.

So, if those people don't understand the significance of sync/async, they may
be getting a false impression of the speed.

------
spartango
I really appreciated this post for its thoughtful quality. It provided a bunch
of "in our experience" analysis of situations that others presented, noting
both the mistakes of users and Mongo itself, without playing the blame game.

The presentation of mitigation strategies for both sources of issues was
actually constructive for potential and current users of Mongo. As with any
tool, Mongo is useful in some scenarios but not without its drawbacks. It's
nice to have a point-by-point assessment of pain points.

Falling into the potential user category, I've opted not to use MongoDB for my
current project because the particular benefits don't align nicely with my
problem, but it was useful to see this and know a bit of what to expect with
Mongo, good and bad.

------
firefox
They don't all hate MongoDB, they're just singling themselves out as people we
shouldn't work with. Ranting about a product without knowing much about it or
even reading the documentation simply points out what type of engineer you
wouldn't want to deal with.

------
antonpug
Bottom line...I DO NOT like the OO approach Mongo takes. I am in love with POS
(Plain Old SQL)

------
pbharrin
YES!!!! We stopped using it in production and moved to Solr.

I don't hate MongoDB but I think it is overhyped. The fact that 10gen raised
42m is crazy. I would be surprised if those investors got any return greater
than the money they invested.

------
LarryMade
I think it looks promising - it's not a panacea, there are things SQL works
better for and there are things I can see Mongodb would really rock with.

With anything there are gotchas so you have to live and learn with em.

When I was researching Mongodb before going into it I saw forums talking about
the 2gb limit on 32 bit systems; I would say the author of that article didn't
see the posting - which could either be a case of not due diligence on the ins
and out of the system or lack of diligence on the reference material he had
originally been using to build his system.

------
kaiwen1
I'm not sure I "hate" it. But every project I've used MongoDB on that grew the
least bit of data complexity left me wishing for (and often converting to)
Postgres. I'll still like MongoDB if I'm doing something _very_ simple or
rapid prototyping, etc. But for real work, forget it.

------
tmo9d
I wouldn't say I hate it, but I took MongoDB into production two years ago
only to have it be a consistent source of problems for me. We integrated it to
offload some activity from MySQL, it did a great job for a while, but it's a
constant chore to maintain.

------
mathnode
MongoDB powers my latex doc database, and the CMS my team and I use. It's
awesome.

I have an event logger, that logs "interesting" MySQL server events to a tab
separated file and then out to a central mongodb database. So I can query
several servers results at once.

------
chaostheory
> The way MongoDB yielded was improved in 2.0 in a very significant way and
> this was taken further in 2.2 with the complete removal of the global lock
> as a step towards more granular concurrency.

Yes with 2.2, write locks have improved drastically. However, I'm still
waiting until you can get to the point of not having to lock down whole
collections (the near equivalent to a table - with caveats) as opposed to a
document within the collection (the closest thing that you can call a record
in db terms - with tons of caveats).

This being said, Mongodb does have really really awesome documentation and it
is the right way to go for many applications and developers.

------
oracuk
I've used mongodb for a recent prototype. It was brilliant, I iterated through
the data model as I coded.

However, I am now very aware that I have an implicit schema in my code that
will be harder to understand in 6 months than a database schema.

I traded fantastic flexibility in initial development against easily
maintained longevity.

I suspect I will move to something more relational but have also taken on the
need to really understand the trade-offs I'm making. I've started reading
Seven Databases in Seven Weeks to fill in some of my gaps.

~~~
einhverfr
_I traded fantastic flexibility in initial development against easily
maintained longevity._

Great quote, btw, and spot on.

------
mark_l_watson
I am a huge fan of MongoDB and have been using it for years. That said, my
default data store is PostgreSQL. I have to have a good reason for choosing to
not use PostgreSQL.

I especially like MongoDB for data analytics: really handy for storing data
and then doing experimental data mining. Putting a read replica on each server
that does analytics/data mining works especially well (very good performance
when MongoDB's indices fit in memory and the read mongo is on localhost to
programs doing analytics).

------
manishsharan
I love that MongoDb allows me to get stuff done without much fuss even when I
have not figured out the final data requirements. I have been using RDBMS +
ORM ( Hibernate) for a very long time; however I found this to be very "rigid"
in a start up environment where the requirements are far from frozen. MongoDB
is much more flexible and forgiving than traditional RDBMS in that respect.

~~~
freework
If you haven't figured out the final data requirements, then you have work to
do. Its a corollary of the "give me your data structures and I'll understand
your program, give me just your code and I'll still be clueless" mantra. The
Database should have a strict schema before code is written. Having a
schemaless datastore is only flexible in the sense that it lets ou shoot
yourself int eh foot easily.

------
thibaut_barrere
I don't hate MongoDB: I use it on scenarios where it is useful (eg: forms apps
collecting semi-structured data, ETL apps pushing/transforming data to achieve
geo-near queries etc).

For a regular web-app with less exotic needs, my store of choice is PostgreSQL
these days.

And next time I have to handle large scale data, I will probably use Riak.

------
frederico
Outstanding article. Well overdue for the Mongo community. There are always
the haters whom find themselves ignoring documents then complaining about how
things are setup.

Thank you for going back through mongo articles to iterate the key failures to
understanding points.

------
Uchikoma
No I like it if you know it's limits. Schema free supports agile development
much better than e.g. MySQL. Compared to key/value stores it's easier if you
need to query data (and don't have Twitter scale amounts of it)

------
programminggeek
I'll say this. I like MongoDB, but I've never built anything at big scale with
it. For a small project, it's much less hassle to get rolling on than MySQL,
so it's cool for that.

------
aliks
Reasons why i hate Mongodb:

site:jira.mongodb.org/browse/ planned but not scheduled

------
fleitz
MongoDB is kind of like assembler, if you read processor errata sheets for fun
you can make some really fast websites. Get that OS, and everything out of the
way, just you and the network card.

However, if you just want to write a web app that doesn't lose data it's a
really crappy idea and should probably use something creating for solving that
problem, like a compiler and web framework.

------
nwmcsween
No it's a tool, do I dislike a hammer because it can't turn screws?

------
edwardcapriolo
It is easy to criticize the things closest to you.

------
gubatron
hell no, it's been a breath of really fresh air for us, we've been building
all sorts of things, no problems so far. (including logging several millions
of requests per day and performing distributed map reduce for all sorts of
statistical models on a tiny 3 machine "cluster" we run on AWS, I hope I never
have to go back to modifying schemas again, so much simpler to run and build
with this mindset)

~~~
vyrotek
_> I hope I never have to go back to modifying schemas again_

Honest question. Do you actually leverage the schemaless nature of MongoDB?
Not 'worrying' about managing schemas is one thing, but actually leveraging
the fact that your objects can have different fields is another. I have worked
on projects that did need to store objects with different fields together but
it seems to be a rare case.

From what I've seen, most projects actually have pretty standard objects with
specific fields. People just don't like feeling constrained but in the end I
don't think managing a schema is difficult at all. I actually like the safety
and performance you get when you put in the effort.

I think the single most useful thing to see when starting a new dev job
somewhere are the database schemas. If done properly, it will essentially tell
you the story of that company and their data. You can think up questions and
get answers such as _"Is it possible for a Customer to have multiple Orders?
Can a product have more than one Review?"_ (Stupid examples but they
illustrate the kinds of relationships which are asked about all the time).

~~~
dmytton
Flexibility is useful in development. Once you deploy then things will change
less frequently so the real benefit is when you do have to change something,
you're not running a big ALTER statement.

~~~
flatline3
> _Once you deploy then things will change less frequently so the real benefit
> is when you do have to change something, you're not running a big ALTER
> statement._

Instead, you're writing a bunch of code to deal with data that may be in the
old format, or may be in the new format, or may be in the new-new format.

I don't see that as an improvement.

~~~
prodigal_erik
In practice, you're writing code that has to deal with records that were
updated by versions 3, 5, and 7 of your code but not 4 or 6. After a few years
you can be sure somebody got it wrong at some point, and now you have records
in a few out of the 2^n states where not even the developers can anticipate
the system's behavior. The fix is to make ALTER incremental and less painful,
not to stop writing down and checking your schema.

~~~
jeltz
And both MySQL and PostgreSQL have put in work to make ALTER less painful by
reducing the situations where a full table rewrite is necessary. In PostgreSQL
you can both add and remove columns without the table being rewritten as long
as you do not set a default value. You can also increase the lengths of
varchars without any rewrite.

------
Nux
Yes.

