

Ask HN: Should we all start using MongoDB for new projects? - wesleyzhao

I'm seeing more and more articles on HN with projects that are choosing MongoDB and other NoSQL data structures over MySQL. Is this what the future is going to be, so we might as well start adopting now? What are it's disadvantages if any?
======
aphyr
I can't see using MongoDB for any production project. It combines a limited
replication/sharding model with a poor single-server durability, lack of
tunable CAP constraints, and some surprising performance bottlenecks.

If you want integrity and SQL, use PostGres. If you want volatile speed, use
Redis or Membase. If you want a rich data model and excellent durability with
limited but highly configurable replication, experiment with Couch. If you
want federation, predictable horizontal scaling, and HA, perhaps look at
Voldemort, Cassandra, HBase, or Riak. There are a lot of good datastores out
there, and chances are one of them fits your needs better.

Edit: I think
[http://www.paperplanes.de/2011/1/10/mongodb_and_data_durabil...](http://www.paperplanes.de/2011/1/10/mongodb_and_data_durability.html)
basically sums it up. When the Mongo folks started telling me that kill -9
should never happen to any database, I stopped taking them seriously.

~~~
wesleyzhao
I have just been reading that MongoDB is much more scalable and faster and I
looked into it and saw that its queries were very similar to SQL. There are a
lot of DB choices out there, and just trying to find one that I should either
stick to or learn based of trends, benefits, and level of user-support out on
the web.

~~~
aphyr
_its queries were very similar to SQL_

You may want to learn more SQL.

If you're interested in picking up a more complex document database, I would
recommend Couch. For a simple k/v store that will get you thinking about
concurrency, perhaps Riak.

------
clojurerocks
Its very difficult to explain why you would use MongoDB and why its becoming
so popular. The best way to learn it though is to do a project with it. Im
actually working on a few right now, mostly games, and would be open to having
you involved. If youre not into that then just read the mongodb books and
understand what it is. Also learn what couchdb, riak, and membase are and why
they are different since they are all "nosql" datastores but are very
different from each other. Also a good way to learn it which is how i learned
it is to learn jquery/ajax and specifically developing the json api that it
will call and use. Once you understand json and key value pairs then why
mongodb is so great will become apparent.

------
sim0n
We use MongoDB on ww.interstateapp.com but only really because Interstate
started out as a small fun project and not something we expected to take that
seriously (so it didn't matter too much if MongoDB was a perfect fit or not -
it turns out that it suits the app quite well). If your app is the type of
application that would benefit from the advantages of having a NoSQL style
setup (not all do) then go for it but I can't see MySQL being phased out (in
terms of usage by devs, etc) anytime soon...

Also, if you don't know whether your app could benefit from using MongoDB it's
kind of a general rule of thumb (from what I've seen) to just go with a
traditional MySQL setup for now.

------
acangiano
You shouldn't start using something just because others do. NoSQL databases
are tools, and it makes sense to employ them when they actually are the right
tool for the job. Does MySQL and relational databases in general satisfy your
requirements for a given project? If yes, you don't need NoSQL.

Some projects will require NoSQL. Others will require both NoSQL and
relational databases (a great combo). It's all about what problem you are
trying to solve.

