The alternative: a shared table with a tenant_id column
Most multi-tenant SaaS products store every customer’s rows in the same tables, distinguished only by a tenant_id column. Every query must correctly filter by that column. A single missing filter — in a report, a background job, an ad hoc admin query — can leak one tenant’s data into another tenant’s view.
Schema-per-tenant: isolation at the database level
Under schema-per-tenant multi-tenancy, each tenant gets its own database schema (in Voz360’s case, a dedicated relational-database schema named after the tenant). The database itself enforces the boundary; there is no cross-tenant table to accidentally query without a filter.
How Voz360 implements it
Voz360 generates every tenant schema from a single factory definition, so every tenant’s schema is structurally identical — no drift between tenants. Application code sets the tenant’s schema as the active search path for the duration of a request, so a bug that forgets a filter simply has no other tenant’s tables to reach.
What this does and does not guarantee
Schema-per-tenant isolation reduces the blast radius of application-layer bugs and makes tenant data easier to reason about, back up, and delete independently. It does not, by itself, encrypt data at rest — that is a separate control (see DEK-per-tenant encryption) — and it does not replace access-control review.
Can the vendor tell you — in one sentence — which of their AI capabilities are rule-based, which are generative, and which are still roadmap?