See this is the sort of crazy things I used to see people do and wonder why they had problems. MongoDB is a document database. You can't just take relational database tables, move them across and expect it to behave the same. And frankly I don't feel sympathy for bad engineering practice. You don't do system migrations without fully testing and understanding all of the systems.
But for those of us that had document orientated data models it allowed for performance that was orders of magnitude faster than any SQL database.
If you never tracked what happened in production, it may have worked most of the time well enough that you never saw how bad it was.
But read https://aphyr.com/posts/284-call-me-maybe-mongodb and https://aphyr.com/posts/284-call-me-maybe-mongodb for an idea of how the promises in MongoDB documentation compared to the reality of the software under stress. And it wasn't just hypothetical either - there are plenty of horror stories floating around from people who ran into those problems in production for uses cases that were supposed to be a fit for MongoDB.
And the performance argument didn't hold water either. As benchmarks like https://www.enterprisedb.com/node/3441 showed, decent relational databases consistently beat MongoDB on the same hardware. Yes, lots of people rewrote bad relational models and saw performance improve. But apples to apples, writing an application against a relational databases in the same way you would against MongoDB resulted in a win for the relational database.
So yes, there were lots of people saying exactly what you are saying now. But the ones who actually tested their systems and ran performance tests came to a very, very different conclusion.
Again. I have been personally involved the deployment and support of MongoDB clusters for very large datasets at very large companies. It does work if you use it for the right task i.e. highly nestable data not relational data. And let's be clear that if MongoDB was unusable then the company wouldn't still be here as successful as they are.
That EnterpriseDB link is completely ridiculous. Firstly, it predates WiredTiger which replaced the entire storage layer. Secondly, doing one for one comparisons with relational systems doesn't make sense. MongoDB is a document database. Compare it with other document databases.
From your link, go to https://newbiedba.wordpress.com/2017/11/27/thoughts-on-postg... for the followup after he wrote those benchmarks. When he ran his benchmarks, he indeed got better throughput on MongoDB. But the 99% performance was massively worse - in fact slow enough to be unacceptable. To an extent that he concluded that you'd be better off using PostgreSQL.
And he's right. As pages like http://latencytipoftheday.blogspot.com/2014/06/latencytipoft... make clear, we have a lot of calls back to the application happening. Users will notice the occasional slow load surprisingly quickly, and it is worth a lot to get rid of them.
So even your chosen source agrees. A relational database is not orders of magnitude slower. In fact, a relational database is probably a better fit.
See this is the sort of crazy things I used to see people do and wonder why they had problems.
Financial time series data is exactly one of the use cases Mongo claimed to be for. Seems you’re the one who can’t tell good engineering practice from bad. And yes, they also pitched themselves as a direct replacement for Oracle. That was highly disingenuous.
But for those of us that had document orientated data models it allowed for performance that was orders of magnitude faster than any SQL database.