
Ask HN: Does anybody actually use MongoDB anymore? - giaour
Does anyone still consider MongoDB a viable data storage option for new projects? If so, why?
======
pbbakkum
Here's my theory on MongoDB, having spent a lot of time thinking about it:

There is going to be some huge number of new developers every year for the
foreseeable future, and Mongo is the lowest barrier to entry database
available. These people don't know SQL and don't care that "Postgres is
better". Mongo does a few useful things really well, and everything else (like
sharding) is a moat around that core value proposition, which is why Mongo
gets away with being bad at a lot of stuff.

Mongo is good at:

* Starting up (when you download it, you literally just get a mongod binary).

* Inserting JSON documents.

* Indexing those JSON documents.

* Composing queries programmatically (because they're JSON documents).

* Replication (oddly).

Mongo is bad at:

* Analytical queries. I've literally written a book about Mongo and still can't remember most query syntax.

* Efficient data storage - documents take a huge amount of space.

* Scaling.

* Sharding - this feature has always been half-baked.

* A lot of other stuff.

Your immediate inclination is probably to say something like "but look at
(Couchbase|MySQL|Cassandra|Rethink|Postgres), its so much better written and
it does (document storage|relational querying|scaling|sharding|json documents
now in version 9.4!!!!!) so much better". Again, thats not the point, the
lesson here is that MongoDB is a thing because barrier to entry is a better
feature for many users.

~~~
gaius
You're describing MS Access.

~~~
dragonwriter
> You're describing MS Access.

MS Access is a higher barrier of entry to a developer who knows some other
language but not SQL and just wants to throw on a datastore than MongoDB is.

It _might_ be a lower barrier to entry to learn Access from the beginning than
(programming language) + (MongoDB) -- though I'm somewhat dubious of even
that.

------
angersock
I do, though I don't use it for certain types of things for which it's ill-
suited--it's a document store, it's non-relational, it's not really as fault-
tolerant as I'd like for certain types of applications.

That said, it's got a really nice query API and is quite simple to get up and
running for hackathons or simple home projects. It's got a decent map/reduce
story for simple tasks, and overall I don't really see anything wrong with it.

There's just a lot of backlash because some earlier versions did dumb things
by default (which were fixable if you consulted the docs), because Postgres
can do almost all of the storage things Mongo does and faster (once finally
setup and tuned, and if you don't mind losing that nice API [unless you want
to set things up with Mongres or similar hacks]), and lastly that all of the
cool kids on HN were congratulating each other on how awesome Mongo was and
just in general being annoying.

That's it, really.

EDIT:

To misquote Tyler Durden: "You're not your fucking tech stack." Especially
when you are working on something that is more of a business problem than
anything else.

~~~
notastartup
Tyler Durden: "You're not your fucking tech stack."

That is such an awesome quote, I want to print a picture of brad pitt from
Fight Club and put that as caption.

I think the last time I used MongoDB was when I was fiddling around with
Meteor.js

I recall struggling with CRUD queries using MongoDB and pretty much gave up
after that.

------
gooseus
Can I ask why it would have stopped being considered a viable data storage
option for new projects? Are you asking about document storage as a whole, or
MongoDB specifically?

I've been using MongoDB for many years on most new projects. The advantages I
find are that it is easy to setup and use and lends itself nicely to adapting
product requirements that typically accompany a new project.

It's also nice that there is a large community and talent pool that supports
and is familiar with MongoDB, so if you bring someone on to your project, you
don't have to worry about someone getting up to speed on a less well-known
document store.

In any case, I would consider it a viable option for any generic "new project"
though the devil is in the details and there are certainly project
requirements which could make it less viable.

------
rubbingalcohol
I almost got burned in a bad way by Mongo's aggressive defaults back in the
good old days. The only reason I still use it on some projects is convenience.
Compose.io made Mongo hosting and scaling way too easy.

But really, RethinkDB and Postgres are better in pretty much every way. If I
was running my own stack, I wouldn't ever touch Mongo again.

------
jasondc
Despite the sentiment on HN, it's more popular than ever, and may become the
4th most popular database in the world soon: [http://db-
engines.com/en/ranking](http://db-engines.com/en/ranking)

------
chatmasta
Has anyone gotten triggers to work with MongoDB? I know they are not
officially supported, but you can "roll your own" via parsing of the oplog. If
anyone has a good resource for this, I would love to see it.

My dream architecture is MongoDB+REST backend, pushing data changes as events
over RabbitMQ, consumed by business logic C++Qt. Mongo would make this way
easier if I could get triggers working.

~~~
djmashko2
Meteor has an oplog-tailing MongoDB driver, implemented here:
[https://github.com/meteor/meteor/blob/devel/packages/mongo/o...](https://github.com/meteor/meteor/blob/devel/packages/mongo/oplog_observe_driver.js)

You could use Meteor as your server, and talk to it over DDP from your
frontend C++ app.

------
lokeshk
I use it in my ruby app with mongoid gem. My data is not huge, and I only
expose it to my users through a read-only API. I absolutely love the
flexibility that mongodb/mongoid offers. It almost feels like not worrying
about the DB, states, schema, etc. anymore. Please note that mine is an
experimental project, and not a commercial one that I run for business.

------
poink
I recently started a business that uses it. It was a good fit for the data I
needed to store, and the nature of the product is such that even if I'm wildly
successful I probably won't ever need more than one database server.

~~~
giaour
Best of luck with your business, but I believe you've been misled about that
"only needing one database server" bit. MongoDB makes replication easy (though
not necessarily reliable), but its structure all but ensures that you will
need to take advantage of that replication far earlier than you would have had
you gone with a traditional database.

For example, my employer's production stack requires three Mongo servers.
Stack Overflow, which has a much greater volume of data and gets far more
traffic, uses MSSQL and consequently only needs one server.

------
edavis
This past weekend I was looking to add a document database to a side project
and I never considered using MongoDB. Maybe it has improved over the past few
years, but when I last played with it I found it flaky and unreliable. I
eventually found RethinkDB and think I'm going to go with that.

That said, MongoDB is still plenty popular [1]. It's just no longer the "hot
new thing" that gets 5–10 posts a day on HN.

[1]
[http://www.google.com/trends/explore#q=MongoDB](http://www.google.com/trends/explore#q=MongoDB)

------
MalcolmDiggs
I use it often and love it actually. Mongo + Express/Restify is my default for
most of the APIs I build. I usually add in Redis and RabbitMQ (as a caching
layer and queue respectively), and I've never had any problems.

It may be that my projects are particularly well-suited to json docs and
indexing, so perhaps I'm biased. Most of my APIs are consumed by single-page-
applications like Angular, which already structure their data as json
collections. So using a json-store (for me) makes things like 2-way binding a
breeze.

------
markolschesky
Many of our customers do (I work in HIPAA-compliant hosting), so I can tell
you it's an alive and well thing. Many forms of patient data don't really fit
well into relational data structures, so it's not surprising that Mongo (as
the most "popular" non-relational db) is common in healthcare apps now.

Most healthcare apps are not "large" in nature and often have way more writes
than reads, so many of Mongo's weaknesses don't show themselves in those
applications.

------
yoctonaut
It depends on the nature of your project(s) and the data you want to store, as
well as what you want to do with it. If you're storing and retrieving things
that make sense as persistent documents with JSON-like structures, sure. If
you're going to be editing those documents frequently (and changing their
attributes or--most importantly--their size), then you might want to look at
some other database structure, or some blended solution.

------
jvvlimme
In the past I used to but have since moved on the ElasticSearch.

I found the scaling not to be as easy as they led to believe. I also
constantly bounced against the 10mb limit of the aggregation framework.

My biggest gripe, however, was data storage. It uses way more data then it
should and it doesn't free up disk space if you delete data. For my use case
(web analytics) it was a dud.

Supposedly TokuMX fixes many of the problems but I had already migrated to ES
when I found out about it.

------
Diederich
I've been professionally relying on it heavily since 2010. For the right kinds
of problems, and used properly, it's pretty nice.

------
otakucode
Just started my first project using MongoDB a week or so ago. It seemed the
best fit. Just a personal project providing a bit of a metadata layer over a
filesystem. I suppose I'll see whether this was a good choice or not after I
import a few million file records and start creating clients that manipulate
the tags/properties associated with the files.

------
robotpony
MongoDB is a pretty big part of most of my client JS stacks (including MEAN),
and most of my colleges have clients that rely on it as well. It's a
reasonable balance of performance and complexity, though it's not a
replacement for SQL and key/value stores in all cases.

------
doublerebel
For hobby projects and MVPs, it's certainly fast to get running.

Managing replication and scaling can be time-consuming and expensive compared
to other NoSQL stores like Redis and Couch.

So for production on serious projects, I would choose another DB before
migration becomes expensive.

------
laichzeit0
We use it with writeConcern 0 and journaling off. Basically for a best effort
document store. The type of data stored is such that if a few records get lost
every now and then it's not the end of the world, as long as inserts are
generally very fast.

------
zeeshanm
I use it for ad hoc data analysis. When I just want to put data in, get it out
without thinking about the ultimate picture of schema. Probably not a solution
for all needs. For example, I wouldn't use mongodb in apps where atomicity is
critical.

------
lgsilver
We use it for transient data caching and adhoc analysis. In combination with
good indexing it's relatively fast for our queries.

------
rebelidealist
We like to use their mugs. They are great for drinking all sorts of coffee and
tea.

~~~
giaour
[http://decodify.blogspot.com/2012/09/the-reason-ill-never-
us...](http://decodify.blogspot.com/2012/09/the-reason-ill-never-use-mongodb-
again.html)

------
wnevets
It seems more popular now than ever, am I misreading the current state of
things?

------
funvit
I use it. And enjoying of aggregation framework ($unwind helps a lot).

------
torkable
I do, because its awesome.

