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.

From what that sounds like, I agree. This is a complex problem description with a pointer where the database provides solutions.

> I found that many companies have incredibly bad, not use-case driven reasons to pick their DB.

As in "Our lead dev always wanted to try X, because he likes the name".

Given that, I really need to build an app using project-he-who-may-not-be-named.