Tenant isolation is one line of config, not a rewrite.

The first architectural decision of any SaaS. There's no universal answer, but there are clear criteria.

Shared database with logical isolation is the right choice in the great majority of B2B cases: it costs less in infrastructure, makes schema updates trivial, and lets you add a customer with a configuration operation. Its one historic weakness is exactly what the declarative model fixes — the risk that some path forgets the filter.

One database per tenant makes sense where explicit contractual or regulatory requirements demand physical separation, where a single customer's volumes need dedicated resources, or where you must be able to hand a customer their data in complete isolation. It has real costs: updates to propagate, heavier onboarding, operational complexity growing linearly with customers.

Because isolation in Pwas is declared rather than hand-written, the choice can be made for business reasons instead of out of fear, and in mixed configurations — most customers shared, the few with special requirements separated — the same domain description serves both scenarios.

That's the normal B2B scenario, and where the difference is felt most. Customer A has three roles, customer B wants five with its own names, customer C wants a particular field visible only to a certain responsibility.

In the traditional model every variant of this is a development request, and after ten customers permission management is the most intricate part of the product — the part nobody wants to touch.

In the declarative model roles and visibilities are configuration data, not code. That enables something SaaS products rarely offer: letting the customer define their own roles, within the limits you set, without requiring intervention from you. Your support stops being the bottleneck for every permission request.

The limit to know: the more flexibility you give, the more your product has to be able to explain to the customer's administrator what they're configuring. The hard part stops being technical and becomes experience design.

It changes for the better, and it's one of the less obvious benefits until you get there.

In the traditional approach, the public interface is a second product: it has its own authorisation layer, its own checks, its own risk surface, and must be kept in sync with the main application. It's also where isolation problems most often show, because it's the part most used by people who don't know internal conventions.

When permissions are declared on the domain, the exposed interface has no authorisation layer of its own: it uses the same one. A customer calling with their own credentials sees exactly what they'd see in the application, no more and no less. Exposing a new entity means declaring that it's exposed, not redesigning the checks.

Everything else a serious public interface needs — rate limiting, versioning, documentation, key management — still has to be designed, but those are real problems that aren't isolation problems.

It depends where it hurts, and the honest answer is often no.

If your product is stable, permissions hardly ever change and you aren't continuously adding entities, the benefit doesn't justify the work. Declared isolation delivers value in proportion to how often the model changes.

It is worth assessing in three recurring situations. When permissions have become the product's brake: every customer request about who sees what turns into development. When you've had an isolation incident, or came close, and you know the current defences are procedural. When you're about to add a channel — a public interface, a portal, an AI agent — and realise that replicating the checks on that channel is a project of its own.

Even then the approach is incremental: one domain at a time moves into the declarative model, without stopping the product. The same logic as application modernisation applies, with the same recommendation to start from a narrow scope.