It's easier to manage 1 database instead of 1000s

It's more expensive to screw up one all-important database than one of a thousand.

Same logic allies to compute boxes, see "pets vs cattle" from 15-20 years ago.

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.

This is fair.

But restoring a small DB from a fresh backup, if things go really wrong, is faster, and does not affect other customers.

I completely agree wrt having a hot spare / cluster with transparent failover and management.

SQLite requires near zero management.

Probably the same reason they used postgres instead of MySQL.

Could you please elaborate?

> why not a dedicated database for every customer

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.

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)

Backups are routinely automated anyway.

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.