Add this to your agent's context
Give your AI agent the context it needs to work with Xata multi-tenant databases.
Every multi-tenant SaaS product eventually faces the same architectural question: how do you isolate tenant data without paying for a full database per customer? Shared schemas leak data, row-level security is fragile, and separate databases scale linearly in cost. Xata's copy-on-write branching changes the equation — every tenant gets a real, isolated Postgres instance, but without the linear cost of provisioning each one from scratch.
The multi-tenancy tradeoff
Every approach to multi-tenancy forces a compromise. Shared databases are cheap but fragile. Separate databases are robust but expensive. Until now, there was no option that delivered isolation at shared-database cost.
| Shared DB | DB-per-tenant | |
|---|---|---|
| Tenant isolation | Fragile (RLS) | Full |
| Cost at scale | Flat | Linear (1,000×) |
| Provisioning | Fast | Minutes |
| Idle compute | Always on | Always on |
| Noisy neighbors | High risk | None |
Shared databases compromise isolation
Row-level security works until it doesn't. One misconfigured policy exposes one tenant's data to another. Noisy neighbors affect query performance for everyone on the same instance. The operational burden of maintaining correct isolation across every query, every migration, and every new table is substantial — and the consequences of a mistake are severe.
Database-per-tenant doesn't scale economically
TA dedicated Postgres instance per tenant provides isolation, but cost scales linearly with your tenants. 1,000 tenants means 1,000 full Postgres instances, each with storage, compute, and management overhead. At agent-scale, the cost increases are unreasonably high.
Most tenant databases sit idle
The economic problem compounds when you account for utilization. At any given moment, 80–90% of tenant databases in a typical SaaS product are completely inactive. With a traditional database-per-tenant model, you are paying for always-on compute when you don’t need to be.
How copy-on-write changes the economics
Xata branches use copy-on-write semantics: a new tenant database branches from a template and shares the base storage until it writes something tenant-specific. Provisioning is near-instant regardless of how large the template is. 1,000 tenants share the same base storage — only the differences are stored separately.
| Shared DB | DB-per-tenant | Xata CoW | |
|---|---|---|---|
| Tenant isolation | Fragile (RLS) | Full | Full |
| Cost at scale | Flat | Linear (1,000×) | Near-flat |
| Provisioning | Fast | Minutes | < 1 second |
| Idle compute | Always on | Always on | Scale to zero |
| Noisy neighbors | High risk | None | None |
True database isolation
Every tenant gets a real Postgres instance. No shared schemas, no row-level security workarounds, no risk of one tenant's query affecting another's performance. Isolation is enforced at the storage layer, not the application layer.
Copy-on-write storage
New tenant databases branch from a template and share its base storage. Only tenant-specific writes are stored separately. This means 1,000 tenants does not mean 1,000x storage. A growing tenant base adds cost only proportional to the actual data each tenant writes — not the size of the shared schema or seed data.
Scale-to-zero compute
Inactive tenant branches suspend automatically and reduce compute to zero. When a tenant returns, their branch reactivates within ~200ms. For a typical SaaS product where ~80% of tenants are idle at any moment, scale-to-zero can reduce your compute costs by 50% or more compared to always-on.
Sub-second provisioning
A new customer signs up and their database is ready in under a second. No provisioning queues, no Terraform runs, no waiting for a snapshot restore to complete. The branch is created from the template via the Xata API instantly, and the tenant can connect immediately.
Pricing at scale
Xata's pricing for multi-tenant use cases scales with actual usage rather than tenant count. In today’s AI landscape, it’s all about having capacity when you need it and efficiency when you don’t. As scale increases, capacity- and volume-based pricing keep per-tenant costs predicable and manageable.
Cost vs. tenant count
Traditional provisioning vs. copy-on-write branching
At 1,000 tenants — ~73% cost reduction vs. traditional provisioning
- Startup SaaS (100–500 tenants) — Template branch with seed data, scale-to-zero keeps costs flat as you grow. Pay-as-you-go plans that won’t even raise an eyebrow in accounting.
- Growth Platform (1,000–10,000 tenants) — Capacity-based pricing at $0.50/branch. BYOC deployment available for data residency requirements.
- Enterprise Platform (10,000–100,000+ tenants) — Volume pricing at $0.20/branch or lower. Multi-region deployment, custom SLAs.