(from the article)

What did NoSQL throw out? Again, that varies from database to database, but it was approximately these things:

    Explicit schema
    Transactions
    Strong consistency
    Joins, secondary indexes, unique keys, etc.
    The SQL language itself

Looking through the lens of scalability, let's consider the effect of these. Which were the dirty bathwater, and which the baby?

Back in the early 2010s, NoSQL hype was at an all-time high. One of the things that I never understood was how did organizations that chose to use a NoSQL as the primary business database deal with analytics?

You know, analyzing sales, user data, etc. With MySQL or Postgres, business analysts can just write SQL and get the data they need. But what about with MongoDB? Do you expect business analysts to write Javascript? Or that every data request needs to go through a product engineer? Or maybe you need to create data pipelines from MongoDB to MySQL just for analysts?

Dealing with analytics was the primary reason I never chose a NoSQL database as my main data store.

I did not find a reliable way to query MongoDB with SQL: https://github.com/ClickHouse/ClickBench/blob/main/mongodb/q...

It looks like it's only available in the Atlas service. Please correct me if I'm wrong.

Writing analytic queries in JS is painful.

Problem with mongo is if you start using more SQL like things like pipelines and aggregations your perf goes out the window

you really have to think about how you structure your data in mongo for it to work with lots of queries since joins are untenable (even if aggregations support them)

So it's no longer a NoSQL database. ;)