I'm glad you're not crashing anymore, but this article raises many more questions than it answers, and I would strongly advise anyone against taking this alone as "proof" of the superiority of NoSQL databases.

There is no mention of the purpose or nature of the application. "orders were failing" would seem to indicate that it was transactional in nature, but you then mention "Complex JOIN queries", which have no place in a transactional system and which others have also pointed out are often analytical in nature.

There is very little detail about the business entities or the data model that was implemented to manage them and no mention of data volumes.

Writing, testing, and maintaining your own reliable data integrity in a NoSQL database is nontrivial.

PostgreSQL + Redis + Elasticsearch, etc is not an architecture; it's a tech stack. Architecture is about how you use those tools and technologies in your stack.

I could go on and on, but basically I've seen well-designed, performant relational data layers implemented well in SQL databases like Postgres, and I've seen really, really poorly-implemented in Postgres with little to no discernible design at all. Unsurprisingly, the former performed very well even with large loads and volumes, and the latter did not.

Tool selection is usually not the most important factor, but using a NoSSQL document (semi-structured) database like MongoDB for highly structured, entity data storage is a mistake. Period. Because it's not the right tool for the job.

Conversely, correctly choosing a relational SQL database does not guarantee success.