2. can be a huge security feature. If your web application only has access to the database of this one customer, you practically can't leak data from other customers by accident.

Slack has cross-workspace connectivity and communication as a product feature. It’s a really cool feature.

My experience mirrors that.

If you have a dynamic set of databases or even tables, be ready to invest into tooling to recreate features you take for granted in a normal database.

> 1. You must be able to scale the database up to your biggest customer and down to the your smallest this can be increasingly difficult to provision.

IIRC, Slack had a lot of scaling issues when they won a deal with IBM. Jumping from medium-size customers to such a behemoth will obviously be a challenge, but a lot of the difficulties they faced was non-technical and more business-related (“What do you mean, you want our product but not our monthly plan charged per seat?”). Anyway, that's a nice problem to have for a start-up ;).

IIRC this is the kind of problem that CockroachDB seems to solve well, given their implementation of range partitioning with automatic rebalancing. This ensures the partitions are evenly distributed even with an uneven customer distribuiton.

I have no affiliation with the product, but I have been comparing alternatives and it seems like that's where it shines.

2 can be a feature too!

This is a good post. Thanks for sharing!

3. By splitting, you can give your customers control on data residency, as mandatory in GDPR,

4. By splitting, you limit the exposure in case of SQL injection.

5. By splitting, you can have good performance for the customer who has 1M records, and good performance for the 100K customers with 10 records.