Going from 150ms to 8ms and 80% CPU reduction does not make any sense perf wise. I stand my point it's missing a lot of details in your post and probably miss usage.
Postgres has a good-enough (if not better) document DB inside it, but it also has a billion other features and widespread adoption. Mongo needs a huge benefit somewhere to justify using it.
Edit: on top of that, very few things that you store in the DB are non-relational. So you will always end up recreating a relational database on top of any NoSQL database. So why bother when you can just go for a RDBMS from the start?
Sure you can implement things to make it better, but it's layers added that balloon the complexity. Most robust systems end up requiring more than one type of database. It is nice to work on projects with a limited scope where RDBMS is good enough.
Lol. No relational database slows to a crawl on `is_deleted=true` or versioning
In general so far not a single claim by NoSQL databases has been shown to be true. Except KV databases, as they have their own uses
There's a large amount of solutions for different kinds of data for a reason.
> ... takes solutions that require engineering teams.
All it took was an understanding of the data. And just one guy (me), not an "engineering team". Mongo knows only one way of sharding data. That one way may work for some use-cases, but for the vast majority of use-cases it's a Bad Idea. Postgres lets me do things in many different ways, and that's without extensions.
If you don't understand your data, and you buy in to the marketing bullshit of a proprietary "solution", and you're too gullible to see through their lies, well, you're doomed to fail.
This fear-mongering that you're trying to pull in favour of the pretending-to-be-a-DB that is Mongo is not going to work anymore. It's not the early 2010s.
I have worked with tables on this scale. It definitely is not a walk in the park with traditional setups. https://www.timescale.com/blog/scaling-postgresql-to-petabyt...
Now data chunked into objects distributed around to be accessed by lots of servers, that's no sweat.
I'd love to see how you handle database maintenance when your active data is over 100TB.
Define "huge". Define "massive".
For modern RDBMS that starts at volumes that can't really fit on one machine (for some definition of "one machine"). I doubt Mongo would be very happy at that scale, too.
On top of that an analysis of the query plan usually shows trivially fixable bottlenecks.
On top of that it also depends on how you store your versioned data (wikipedia stores gzipped diffs, and runs on PHP and MariaDB).
Again, none of the claims you presented have any solid evidence in real world.
I'm getting paid to move a database that size this morning.
I assume since then it's grown at least ten-fold. It's already an amount of data that would cripple most NoSQL solutions on the market.
I honestly feel like talking to functional programming zealots. There's this fictional product that is oh so much better than whatever tool you're talking about. No one has seen it, no one has proven it exists, or works better than the current perfectly adequate and performant tool. But trust us, for some ridiculous vaguely specified constraints it definitely works amazingly well.
This time "RDBMS is bad at soft deletions and versions because 19TBs of revisions on one of the world's most popular websites is tiny"
[1] https://meta.wikimedia.org/wiki/Data_dumps/Dumps_sizes_and_g...
They store revisions in compressed storage mostly read only for archival. https://wikitech.wikimedia.org/wiki/MariaDB#External_storage
They have the layout and backup plans of their servers available.
They've got an efficient layout, and they use caching, and it is by nature very read intensive.
https://wikitech.wikimedia.org/wiki/MariaDB#/media/File:Wiki...
Archival read only servers don't have to worry about any of the maintenance mentioned. Use chatgpt or something to play your devil's advocate, because what you're saying is magical and non existent is quite common.