I still can't understand why they decided to use a single database for all their customers. If each customer needs access to its own data, why not a dedicated database for every customer?
The difference between "pets" and "cattle" are that pets have state and need to be taken care of, you can't recreate them from scratch trivially. Cattle are stateless and can be created and destroyed easily.
The whole point of a database is to contain the state - as a pet - so the rest of your application can be stateless - as cattle.
To really get cattle database systems, you need a self-managing cluster architecture that puts things on autopilot like Neon where you've got >=2 copies of each row and can tolerate losing any single box without unavailability.
Multi-tenant design is a huge win in terms of reducing developer toil and expense.
Many customers will have a tiny amount of data. For those customers a dedicated database is huge amount of overhead. There may not be any single customer who it makes sense to allocate dedicated "hardware" for.
Sure you have to deal with a one-time pain to shard your thingy, but you don't need to pay for tens-of-thousands of individual database servers, write interesting tools to keep their schemas in sync, wrangle their backups, etc.
I don't mean one database server for each customer. I say one database for customer. Hundreds or thousands of customer can be on the same database server. When you need more resources, you add another server. If customer grows too much, you move it on another server.
There is a bit of overhead, but not huge by any means.
Being able to update schema one customer at a time is a huge plus in my view, as it gives you a lot of flexibility in rollout. You deploy a new version of the application on a new application server and move the customers on the new servers updating their schema one by one (automatically, obviously)
I've done this before where we ran a schema per customer and it was fabulous. Once the customer was large enough we could justify allocating a separate DB for them. The application was written in such a way that it knew which data store to query based on the user.
Well there's trade-offs with this too, whether needing aggregate data across shards for features, reporting, etc. Shared data between customers, users, etc. API access, etc.
Sure there are trade offs. If a significant part of the value of the app rely on data sharing or transactions between customers this is clearly unfeasible. But if the app mostly deals with a significant amount of private data of the customers that occasionally needs to be shared, I think using separate databases (not servers) is the safest option.