Hard isolation for every customer, without a server each.
The shared-table model puts every tenant in one store and enforces boundaries with query filters. That is a constant source of risk and a ceiling on what you can offer per customer. Turso gives each tenant its own database: a real boundary, custom schemas, and per-tenant residency, at a cost that scales with you.
import { createClient } from '@tursodatabase/api';
const turso = createClient({
org: process.env.TURSO_ORG,
token: process.env.TURSO_PLATFORM_TOKEN,
});
// Hard isolation between customers, no shared cluster
// Each tenant is assigned to a region-specific group for residency
const tenantDb = await turso.databases.create(`tenant-${tenantId}`, {
group: tenant.dataResidencyGroup, // e.g. 'eu-west', 'us-east'
});
// Compliance and sovereignty as defaults.
Why a database per tenant
Real isolation
A compromised query in one tenant cannot reach another tenant's data, because there is no shared store to reach across.
Custom schemas per tenant
Tenants can diverge without forcing every change through one shared schema.
Residency per tenant
Place each customer's database in the jurisdiction they require, on the same platform.
Onboarding and operations
Onboarding a new customer is a database creation call, so provisioning is instant and scriptable. Branch a tenant's database to test a migration in isolation, restore a single tenant to a point in time without touching the others, and bill predictably from your first thousand customers to your ten-millionth.
