well I dunno, we've only tested this architecture for 60 years and a few million companies...
in all seriousness, putting the data in one place also makes it a lot easier to optimize and to amortize the optimization efforts.
in all seriousness, putting the data in one place also makes it a lot easier to optimize and to amortize the optimization efforts.
There were challenges like the difficulty of working with a few huge tables that existed since the company's inception and were practically infeasible to do any schema changes on, but that's more a modeling issue. It was also a single point of failure service. If the db goes down so to does everything but constant sense of impending doom it was less of a problem than I thought with ndb.
There are so many crazy tricks out there. You would be amazed at how much abuse an old school RDBMS engine can take on modern hardware. In-memory OLTP on servers that can host terabytes of RAM completely changes the game. Disaggregated compute & storage provides seamless OLAP capabilities on the same SQL connection instance for the most modern providers.
Really, as it pertains to this, it is a question of "where do I want to move the complexity to?", not "can I eliminate it?"
But yeah.
Those things were completely different from what you get in a modern database. Your example is closer to AWS than to Postgres.