i have worked on several not-faang-sized-but-largish b2c startups, all of which were forced to spend a very large amount of money, time and people trying to migrate things off the one central RDBMS when it could no longer be scaled vertically. This is a real problem that you likely will run into well before FAANG size, and it really does hurt, and i think it gets minimized by the "just use one postgres for everything" trope. You should probably think about it at least a little if your planned business trajectory is into the 1 million+ users realm.
Im not saying you have to use nosql or whatever, but some sort of small future proofing (eg introducing different schemas/permissions for your different data domains inside your monolith) can help make future database seperation much easier.
If you're doing a B2B app its a different story, much harder to hit the limits of a big RDS instance.
The real answer, as in most software engineering is "it depends"
How long ago did these startups hit the limits of vertical scaling? Those limits are always increasing. Expensify's famous post from 2018 [1] suggests that it should be feasible for one monster machine to handle millions of concurrent users.
theres one that im still working on today :)
for practical and all the other usual reasons most people are going to rent cloud dbs (like RDS), not run bare metal. Also, theoretical/benchmark performance is a very long way away from the actually achievable performance when you have 100s of developers actively evolving a codebase against the database. Optimal query usage etc in that scenario is an impossible pipe dream, best you can do is "not crazy", unless you grind all development to a halt behind gatekeeping dba-types.
There are many other operational challenges to single very large database instances. Upgrades, backups, migrations, etc all become way more risky and hard when you get into the mega-db range. The number of total outages ive seen caused by migrations gone awry, query plans gone awry... RDBMS are incredibly complicated beasts and at huge sizes can be very unpredictable in a way that many smaller dbs are not.
> The real answer, as in most software engineering is "it depends"
Of course. It's not as if only FAANG has scale issues.
However the set of people who believe they have scale issues is orders of magnitude larger than the set of people who have legitimate scale issues. People should start by assuming they're not in the second category is my point.
Micro-services is about partitioning based on functionality and features -- so I think more often than not, 99% of the microservices use 10% of the storage and 1 microservice use 90% of the storage, and you're back to solving the problem of horizontally scaling your storage regardless of microservice vs monolith.
thats sometimes true, not always. but a good observation. Even if it is true, having that 90% usecase behind its own service often allows a lot more flexibility to scale for that particular storage problem , and not have to use it generically/everywhere. Eg, time-partioning, cold archiving, sharding, whatever is suitable for just that use case.
Im not saying you have to use nosql or whatever, but some sort of small future proofing (eg introducing different schemas/permissions for your different data domains inside your monolith) can help make future database seperation much easier.
If you're doing a B2B app its a different story, much harder to hit the limits of a big RDS instance.
The real answer, as in most software engineering is "it depends"