One deployment per customer
does not scale with you

The instinct when data must not leak between customers is to give each one their own everything. It is the easiest thing to explain and the hardest thing to keep running.

What per-tenant deployments cost

Every customer becomes a deployment to upgrade, monitor, back up and debug. A schema change is not one migration, it is as many migrations as you have customers, run in a sequence somebody has to track.

The cost does not show up in the first year, which is why the decision looks fine when it is made. It shows up when a security patch needs applying everywhere in a week.

The middle option

Shared infrastructure, shared pipelines, shared definitions, with tenant boundaries enforced by the platform on every read rather than by having separate copies.

The isolation guarantee then rests on one mechanism that is tested once and applies everywhere, instead of on the fact that two databases happen to be different databases.

What has to be true for this to be safe

The boundary must be enforced below the application, so that no query path can bypass it. It must apply to exports and APIs, not just to the interface. And it must be observable, so you can demonstrate to a customer's security review exactly what stops their data appearing elsewhere.

If any of those three is missing, the shared model is a risk rather than an efficiency.

When separate really is correct

Some customers contractually require their data in their own environment, and some regulators effectively require it. That is a legitimate reason and no amount of architecture argues with it.

The mistake is applying that model to every customer because a few need it. Run the exceptions as exceptions.