Isolation
Per-tenant compute and storage isolation — each database runs in its own sandboxed WASM runtime with storage scoped to that tenant.
Isolation is the foundation of the Silos security model. Two databases — whether they belong to the same account or to different customers — never share a runtime and never share storage.
Compute isolation
Each Silos database is served by its own sandboxed WebAssembly runtime. The PostgreSQL engine runs inside that sandbox, which means the sandbox boundary applies to everything the database does, including any code an extension or a query might run.
One runtime per database
A database gets a dedicated, isolated runtime instance — it is not multiplexed with another tenant's workload.
Sandboxed execution
The WASM sandbox restricts the runtime to an explicit set of capabilities. It cannot reach the host or other runtimes.
Ephemeral by design
When a database scales to zero, its runtime is torn down. Durable state lives in storage, not in a long-lived shared process.
Because runtimes are isolated and short-lived, a compromised or misbehaving query in one database cannot affect another database's compute.
Storage isolation
A database's durable state — its snapshots and WAL segments — lives in object storage, scoped to that database. The storage layer enforces tenant boundaries so that a runtime can only read and write the data belonging to its own database.
This scoping is independent of the compute sandbox: even if you reason only about the storage layer, one tenant cannot address another tenant's objects.
In-database isolation
Inside a single database, you isolate further using standard PostgreSQL mechanisms — because the engine is genuinely Postgres:
- Roles and privileges to separate application access from administrative access.
- Row-level security (RLS) to enforce per-tenant row visibility when multiple tenants share one database. See Authentication.
- Schemas to namespace objects by tenant or by concern.
Isolation patterns for multi-tenancy
Silos's fast provisioning makes a few isolation strategies practical:
| Pattern | Isolation boundary | When it fits |
|---|---|---|
| Database per tenant | Separate runtime + separate storage | Strong isolation, per-tenant scale-to-zero and billing |
| Branch per tenant | Copy-on-write fork of a base database | Many similar tenants from a shared schema |
| Shared database + RLS | Row-level security within one database | Many small tenants, simplest operations |
A database per tenant gives you the strongest isolation Silos offers, and because each database scales to zero independently, you only pay for the tenants that are actually active. See Agent-native usage and Branches.