Multi-tenancy

Tenant isolation is a schema-level decision made once and lived with. Enforcing it in application logic alone eventually fails.

For AI SaaS, per-tenant cost metering matters as much as isolation, without it, margin is invisible until the invoice arrives.

Row-level security in the database is the pattern we reach for by default, because it enforces isolation at the layer closest to the data rather than in application code that a future feature might forget to apply. It is more work to set up and considerably less work to trust.

Noisy-neighbour behaviour is the operational counterpart to data isolation. One tenant running an unusually heavy workload should not degrade everyone else, which means per-tenant rate limits and quotas belong in the design from the start rather than being added after the first incident.

Onboarding and offboarding are the parts that get retrofitted painfully. Creating a tenant should be a single transaction that provisions everything the tenant needs; removing one should reliably delete every trace, which is both a contractual obligation in most enterprise agreements and a data-protection requirement under the DPDP Act. Systems that grew organically usually discover tenant data scattered across a dozen tables and three storage buckets at exactly the moment a customer asks to leave.