Ask HN: Does anybody actually use MongoDB anymore?

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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

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

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

I do, because its awesome.