Loading

Shared Database Mode

In shared mode every tenant’s rows live in the same database, separated by the tenant they belong to.

Where to find it

Architect Panel → Configuration:

  • Multitenancy — the tenants themselves
  • Custom Tenant Information Fields — your own fields on a tenant
  • Instance Configuration Fields — settings held per tenant

Architect Panel → Integration & Connections:

  • Database Hosts — where tenant databases live

What it gives you

  • Immediate tenants. Nothing has to be created or copied, so a new customer can use the product straight away.
  • One schema change. Applied once rather than once per tenant.
  • One backup to take and to test.
  • No provisioning pause — nobody waits while a database is duplicated.
  • Cross-tenant reporting is a query rather than an exercise.

For a product with many small tenants, this is almost always the right mode.

What it demands

That every query is scoped correctly, every time, forever. Isolation is enforced by the application rather than by the database, so a query missing its tenant condition returns other customers’ data.

That is the entire risk of shared mode, and it is why the platform’s scoping should be used rather than worked around.

Custom code is where it goes wrong

Not the platform’s own queries. A custom query view, a report, a bespoke page written by somebody thinking about the data rather than the tenancy — that is where an unscoped query appears.

Review anything custom that reads data with tenancy specifically in mind.

Test isolation like a feature

Create two test tenants with recognisable data, and go looking. Every list, every report, every search, every export. Repeat it after changes.

This is the single most valuable test on a shared-mode installation and it takes an hour.

Deletion is harder

Removing a tenant means deleting their rows from shared tables rather than dropping a database. Know how that is done, and be able to demonstrate it — customers ask, and so do regulators.

Noisy neighbours are real

One tenant running heavy operations affects everyone on the same database. Monitor for it, and know what you would do about a customer whose usage is disproportionate.

Some customers will object

"Our data is in the same database as your other customers" is a question that comes up in procurement. Have a clear, honest answer about how isolation is enforced and what you test.

Worked example

A platform with sixty small tenants runs shared mode, tests isolation with two seeded test tenants after every release, and reviews every custom query view for tenant scoping. Its answer to procurement questions is a written description of the isolation model and its testing.

Recommendations

  • Review custom queries for tenant scoping specifically.
  • Seed two test tenants and test isolation each release.
  • Know how you delete a tenant before being asked.
  • Have a written answer for procurement.