The web-scale meme came from them actually trying to position themselves like that, and it partially worked given that it is not only still around, but the prevalence of the MEAN/MERN stack, at least in (tech) pop culture and social media.
To this day my opinion is that Mongo is a snake oil PR firm with a "database" and I have not yet seen anything that has convinced me otherwise.
During which, data is naturally hierarchical and schema-less (ie., not defined, changing).
Mongo makes it easy just to "save your dictionary"
It's really just an "sqlite for hashmaps", and should have remained this.
https://docs.mongodb.com/manual/core/storage-engines/
Wired Tiger, the default storage engine is LSM Trees with BTrees for indexes.
Additionally, Junior developers do not care about data integrity (the customer's problem), or operational complexity (the SRE's problem).
Finally, Junior developers consider software to be much like bread. Older software is bad (such as SQL relational databases), and newer software is good (NoSQL).
Combine all three of these flawed systems of thinking, and you have MongoDB adaption.
... also before Kafka, the defacto queue broker was ActiveMQ, which was a pain to deploy, so many people used Mongo as a queue.
Their aggregation pipelines are pretty pleasant to use. You basically get a bunch of data transformation code that you can avoid writing and you can work with your data without it going out on the wire.
I would probably be able to do most of that in SQL and I’m sure someone who really knows SQL can do everything it can do but I suspect the query involved will be significantly gnarlier. :)
Not sure about how the two would compare performance wise but I do know that you can’t use “$lookup” (Mongo equivalent of joins) with sharding which strikes be as quite unfortunate for scalability.
There are a few instances where I've really preferred using a document database. Things like logs are often really useful to have in a document database like MongoDB. In one collection I can stick all kinds of logs. The schema of all the different fields in the document are really relevant to what kind of things I'm logging. If I were to have a column for every field I might have in the log message, each row would have a ton of null columns. If I wanted to add a new field to easily search on, I might have to add a new column. A "schemaless" design can then be very useful. Of course this is true of pretty much any document database and not necessarily only MongoDB, and these days some relational databases have decent JSON document database functionality as well. There are always certain kinds of tradeoffs to be made when choosing one database technology over another.
Another thing I've found useful with MongoDB in particular is GridFS, that has been pretty neat to use. These days there are other systems of handling binary blob storage, but as mentioned earlier there are always tradeoffs with choosing any particular technology.
https://www.defmacro.org/2017/01/18/why-rethinkdb-failed.htm...
It had a flexible data model as there is no predefined schema. The selling point was rapid protoyping.
The JSON-based documents meant developers could work in objects without an ORM. If I remember Mongo called this "fixing the data impedence mismatch." Sigh.
It had decent performance as long as your working set fit in RAM as it was basically a mmap()'d file.
It was easy to get up and running.
It was in the right place at the right time during the original NOSQL hype cycle.
MongoDB has automatic sharding, which is very important for horizontal scaling of writes. For MySQL you have to do manual sharding which is extremely hard.
And finally, document oriented databases are schemaless, which means there is no downtime when you add/remove fields.
Schemaless / document databases have a place and a purpose, but nine times out of ten the data we're dealing with day to day has a known and rigid structure that changes infrequently.
And you still need to do joins to enrich data from different collections.
I want Postgres back. :(
https://docs.mongodb.com/manual/core/schema-validation/#rest...
That's true. The strictness of SQL lets you use SQL as the integration point. Without it you'd have to write a service on top as the integration layer.
Exactly. There is always a schema, there has to be. It's just a question of whether it can easily be seen or if it is buried in a thousand places in the code.
Please define internet scale. Joining 10s of billions of rows using clickhouse here.
Vitess [1] and PlanetScale [2] ?
That is not something specific to document databases that is an approach taken by NOSQL datastores. It's known as denormalization which has its own share of issues that then need to be addressed.
Like NodeJS and many web technologies, almost everything I read about it years ago turned out to be hype and not based on facts (eg, nodejs being faster for large numbers of requests than traditional backends is not true, but it was widely repeated on the first 10 pages of google search results)
edit: very well said, thanks for all the replies!