https://mcfunley.com/why-mongodb-never-worked-out-at-etsy
Which was compiled here:
IMO this would be a case where if you're dealing with a relational domain and the engineers really don't know SQL you should either (a) rethink your hiring policy or (b) spend one of your innovation tokens in having everyone learn SQL.
(I have to add the inevitable disclaimer that I actually love JS and do not want my words to be misinterpreted as a cheap dig at it)
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.
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.
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.
It was a hot time for NoSQL and document DBs. Having investigated using Mongo myself to little avail, I asked why they didn't just use Postgres. If I recall correctly, a couple years later they published a Mongo at Etsy postmortem which concluded they should have just stayed with Postgres.