MongoDB accounted for ~90% of my startup's downtime in its first year of existence. We switched away to MYSQL and suddenly scalability concerns retreated into the future.

For every developer you hear that has problems with Mongo, there are probably 5 that are fine with certain downsides.

You're right. It's easy to compile, configure, and start on a dev VPS. It's easy to fill with data and easy to query.

This is the sweet spot: when MongoDB is on a dev VPS and you're building a small product around it. Most devs don't have to worry about the next step.

Then you push everything live. If you're lucky enough to get any real traffic, everything other than 99% read crumbles. You scramble to shard but realize that sharding just doesn't work well, and is incredibly complicated to set up.

Then you start losing data...because the drivers are programmed to not fucking check if the data you sent was actually written (yes, I know, this is fixed). Ok, you set your driver on your flopping app to validate writes, and BAM there goes 80% of the write performance 10gen promised you.

The solution? Just add more shards!! Ok, so now I have 4 shards, each with 3 repsets + 3 config servers. 4 * 3 + 3 = 15. Fifteen servers to handle what one MySQL server could do in its sleep.

Conclusion: MongoDB is terrific as a write-only, developer friendly database that you will never have to scale, ever.

I wish I could upvote this comment more. I have to run over a hundred instances of MongoDB to equal the performance I could get from ten Postgres boxes, but now we have such massive lock-in on MongoDB we can't easily refactor.

Would it be possible for you to write a wrapper and use the Mongo API against another DB?

The main issue is it being a JSON document store, and our application being designed around that and using the very specific MongoDB queries that involves.

Any wrapper would likely be worse than just keeping MongoDB.

Heh, do you work at my place?

We have the exact same issues with Mongo-specific queries. Even worse, our indexing regime (because we store relational data in Mongo) demands that we stick with Mongo 1.8, so all the comparative goodness of 2.x is lost.

And just this week, it was determined that there won't be any migration from Mongo to something-SQL in the near future, because it'd be too risky to attempt to translate a schema that's half foreign keys, half embedded JSON.

Can't you just jam the data into Postgres JSON columns? :)

Yes http://www.ibm.com/developerworks/data/library/techarticle/d...

Can you point me to an article that explains why you would want JOINs in a NoSQL database to begin with? I thought the entire point was to denormalize your data. I keep seeing this point brought up, but it reads to me like a misguided complaint stemming from misunderstanding how to apply the tech.

The rethinkdb guys think it's important and have joins in their nosql product. Everytime I try nosql first thing I miss is the ability to query as the need arises without a refactor.

I've always just abstracted the DB away with objects and lazy-load any 'subqueries' that I might want to have/use/get (or autoload them if necessary).

Using hierarchical data structures takes care of the most common use case of JOIN (i.e. "SELECT * FROM a, b, c"). This is a win for MongoDB. However there are times when you want to JOIN multiple hierarchical data structures [1]. Or use a different type of JOIN.

[1] http://tebros.com/2011/07/using-mongodb-mapreduce-to-join-2-...

So JOIN in your application. Or use a different DB. MongoDB isn't correct for every use case and they would never claim it is.

Am I just too old for HN now?

I can understand calling something that holds your data and makes it so you don't have to do JOINs a database.

I can understand calling something that holds your data and does JOINs for you a database.

I'm having trouble calling something that holds my data and makes it so I have to "JOIN in my application" anything but a file system.

I don't know, what is the definition of a database? I'd be surprised if it mandated joins.

Actually, if you speak to them, they do claim that. Then they backtrack when you call them on it, but I've heard guys from 10gen as they were known then claim their product was a drop-in replacement for Oracle.

Hearsay and strawman arguments don't make for an intellectual discussion.

The entire point is to go fast; denormalization is a tool, not an end in itself. If, hypothetically (ahem), a database could scale and support joins, why not?

Using partitioning like VoltDB allows you to keep joins. I think Google's Spanner/F1 partitioning/relation scheme also allows joins.

I'm pretty sure their download numbers say otherwise. One or two HN threads complaining about MongoDB every month are not a good indicator for their future success.

Yeah. FWIW, working at $BIGCORP, I'm starting to hear buzz around Mongo from quite a few not-very-technical people. I'm pretty negative on Mongo as a technology, but there's no doubt that it's generated a lot of attention.

In the short term it's probably inversely proportional: more 'complaints' means more people on the platform (or at least experimenting with the platform). In the long term we're all dead anyway.

How does CouchDB compare? What are the latest thoughts on this?

If you're having issues with scaling and performance, you're most likely using MongoDB the wrong way or for the wrong reasons.

Begging the question. If this is true anyone having trouble with mongo for legit reasons can be labelled as "using it for the wrong reasons."

He could also be using it the wrong way. Although MongoDB has faults, most of them are well known and developers are warned. MongoDB is far from being perfect, but the most common reason people hate on MongoDB is because they did things the wrong way or for the wrong reasons.

Aka "no true Scotsman" fallacy

what are the data type problems?

Support for arbitrary-precision decimal. Known as numeric/decimal in Postgres. This can be a problem for financial and scientific applications.

Yep we canned it because of that, plus it was unreliable and our code and architectural review scared the shit out of us.

Well, some of us have been asking for a native high-resolution time type for three years: https://jira.mongodb.org/browse/SERVER-1460

Can't you just store it in a regular 64-bit integer and know it's a datetime from your application's logic?

What do you gain with a native, high-resolution datatime type?

Automatic timezone conversion and the ability to add and subtract dates without first dropping to your 64-bit into. Think DATE_SUB(date time, INTERVAL 1 HOUR) from MySQL for instance.

nobody ever got fired for choosing:

1. Oracle

2. SQL Server

3. MongoDB

Oh but I wish they had