Hate to say so, but many are switching to MongoDB because it's the current new kid on the block.
I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. Not that MongoDB is a bad database, but it has it's fair share of issues. Granted, this is the case for every database, but if you pick any database without being aware of those, you end up in a world of pain.
(Context: I consult for backend systems in general)
That was my only experience with MongoDB - "let's try this, for this experimental project, to see what it's like", without taking into account its characteristics.
After that the project grew, I was brought in and needed to do some reports, which were a huge pain in the ass without proper SQL and joins.
I don't intend to have anything to do with people using MongoDB unless they have a really, really good reason for doing so, and it's used alongside other databases.
A friend of mine came up with the perfect use-case for MongoDB.
His company installs and monitors sensors in civic infrastructure: roads, train tracks, bridges, ... These sensors provide constant data streams which need to be stored somewhere before processing. Any raw data older than 2 weeks is worthless, and if 2-3% of data is lost before written it's not much of a problem. More data is coming in all the time any way.
For them MongoDB is the perfect transient cache. Sensor data is processed and the results stored elsewhere. Easy to expand. Flipping between installations is just a matter of toggling load balancer, an once an offline cache has been processed, it can be nuked and put back as a fresh system.
So, for a setup where easy size expansion, fast mostly-reliable writes and ease of use are the primary design constraints, mongo fits in suprisingly well. It's a fascinating use-case.
I maintain an environment that has both pg and mongodb. While pg was simple to install and to debug, mongo has given me just pains. I agree that MongoDBs developer experience is nice - download, run, develop, but from the OPS side, that looks totally different. PG is a bit the other way round.
The sad state of affairs however is that often developers choose which DB they'd like to work with and (Dev)OPS doesn't get a say in that.
> People are switching to MongoDB because the developer and deployment experience is so good.
WAT? can you tell us more about your experience? according to mine ,developers are moving away "en masse" from Mongodb,because the experience was so bad.
Well, you won't find one. That's a property of the way the system works. It can be either good or bad, but you won't find an example on how to store and query whole documents with a map/reduce implementation on an SQL database. Both can be either a good fit or a bad fit to your needs - I've seen project that leveraged CouchDB to basically return all data for any given view with a single query from a pre-calculated view, something which would have impossible with an SQL database. That's a good fit. Using a document store as drop-in-replacement for an SQL dabase is most of the time a very very bad fit.
The general issue that I often see is that people don't choose their databases by "is this a good fit or a bad fit for our use case" but rather by "that looks cool" or "we need that to attract talent" or "we did that project with X, so X is also fine for that new, totally different thing". And then they also try and stick with it at all costs, instead of acknowledging that the choice was a bad fit. And then they call you and say "we have an X database in flames, can you come in and rescue our data? Best would be yesterday?"
This is not restricted to document databases. I've seen apps run on mysql on a cluster with 10 Sun XFires where after a man-month of index-optimization 3 would have been sufficient. That was like shooting dead fish in a dry barrel. A lot of developers don't want to bother with stuff like "how does that complicated piece of machinery actually behave if I push it."
> I've seen project that leveraged CouchDB to basically return all data for any given view with a single query from a pre-calculated view, something which would have impossible with an SQL database.
This sounds interesting. I've been looking for a good example where NoSQL db is better than relation db. Could you provide more details.
I didn't mean "view" in the sense of "database view" but rather in the sense of "page view". All data displayed on a page with multiple types of documents was returned in a single query. That's certainly doable in pg, but requires a lot of hacks and it's not efficient. Or you can use hstore and basically use pg as a nosql db.
Ah, that makes sense, though couldn't you solve this by something like creating a table called 'pages' and storing the materialized JSON (the same that mongo would generate) in the table?
Sure, you could. But CouchDB just makes that very easy to do while it is very hard and hacky in PG. On the flip side, the use case did not require the guarantees that PG has to offer, so why go through the pain for no gain :)
