Lots of good reasons to use NoSQL. All pretty much hang off what sort of data access pattern you need.

If you have an application that retrieves an works on a top level entity then NoSQL fits very nicely. When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort.

> When you have a dataset that is shared and aggregate information is needed not so much and you are likely better of considering a SQL database of some sort.

There are best practices for this. Simply create a microservice per table, and then create a microservice that acts as a client to the other services and aggregates or joins the data from those services.

No, I'm not kidding. This is literally what people do and recommend.

And remember to implement distributed 2 phase commit to guarantee consistency! So much simpler than using old crufty sql

Oh, pish and tosh! That's too much engineering! Instead, handwave about "eventual consistency" and save millions in infrastructure costs! Totally worth it for the benefits of being truly abstracted from your data storage layer. Because, you know, people change their database back ends more often than they change their sheets.

Is this a joke or people seriously do this?

It's industry best practice -- not a joke. What's more, the recommendation is to have a separate database per service -- one table, one service, one database.

Fuethermore, when a join is desired, the best practice is to implement not just a service that joins the data but maintains it in a table/materialized view of its own, along with a message server such as Kafka. The services responsible for the tables to be joined (customers and orders, for instance) put events on this message bus which the joining service subscribes to in order to know when to update its view. See: https://microservices.io/patterns/data/cqrs.html

And don't get me started on how you do transactions that touch multiple tables in this setup: https://microservices.io/patterns/data/saga.html

I have seen these deployed and advocated as the modern way to write business applications in the wild.

I bet these people are running on a single server.

This is a good point. If we ignore obvious key-value examples, I’m curious about how much data really isn’t relational.