Today in 2017, there is no real reason to use MongoDB other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed document store.
I did a startup in 2011/2012 where we bought into the hype and used MongoDB & Node + Mongoose. It was horrific.
Your app is relational, full stop. You would know if it wasn't. Do you have users? Do those users need to log in? Well, you now have access tokens related to users. Do those users need to create anything at all? You've now related those owned objects back to the user. We're talking the very basics of any application, and Mongo's support for it is basically nil.
We went down the road of embedding relations inside the model (e.g. an "user" has multiple "tickets" to "events"), and then we'd just filter through the "events" table to find the related one. But what if the admin running the event wants a list of all the tickets for his event? We're talking webapp 101 stuff, but we had to write some really gnarly application logic and duplicate a bunch of data to make it fast.
It was a complete waste of time.
At the crux of this is a fallacy that easier is always better. It's not. There is a reason SQL databases are a little complicated to use - they have evolved over many decades to fit the needs of real applications. MongoDB is only barely removed from writing raw JSON arrays to disk, which is probably the simplest "database" imaginable.
When you so callously discard the common wisdom on how to store data, you rediscover why it exists, the slow, hard way.
10gen made a business - and a fortune - out of misleading new developers.
Aren't those tokens supposed to be stored client side anyway? Aren't those tokens supposed to contain encoded information about the user that you decode server side? Why would you store the users token to begin with?
Point being you can say just about the same thing about any other database. They are all flawed for one reason or another. I happen to like Mongo quite a lot, but I rarely use it. You need to understand what situations it works best in and it's unfair to both it and yourself to generalize and wish it dead.
PostgreSQL is eating Oracle's customers little by little.
RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typical mistake).
I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.
To add to that - you know when you need one. If you don't know you need a document store, you don't need it.
When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.
If you actually tried using it as one you would realise how ignorant your comment is. Both the Solr and ElasticSearch have gone on record before stating that it should never be used as the source of truth.
I'm working on overhauling (rewriting, from scratch) a project right now where the previous developer decided in his infinite wisdom that using ES as a database was a good idea.
I have tried repeatedly to explain to him, and the product owner, why using a search engine as a storage database is a horrific idea. Owner gets it, dev doesn't. I asked that dev if he could overhaul the project, what would he do, and he said "not use SQL at all, and use ES 100%". <_<
I think this is the problem with Mongo too... you have people misusing it, and then want to throw the baby out with the bath water and act like Mongo is the problem, when really, the problem is how they are using it.
There's no need for the vitriol.
I always hear this, but with no "such as" examples given. Could you please provide some?
Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me.
I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in RDBMS that I can also do in it.
I sometimes build OLAP logical models at work for clients, and most of what I touch at work is SQL, but sometimes when I start a project I use Mongo instead of SQL.
It's only one use-case, but I hope it is something.
In a standard RDBMS I would probably have a custom datatype for LatLon (or MGRS):
create custom type LatLon(...)
create table Person(id as int, name as string, location as LatLon)
create table Shop(id as int, name as string, location as LatLon)
Find everyone 10k around Macy's:
select p.* from Person p inner join Shop s where s.name="Macy's" and with_distance(p.location, s.location, 10km)
If it fails, then I can quit having the same discussions repeatedly as try to talk my co-workers out of using it.