Silos vs. traditional Postgres
How the serverless WASM model compares to a managed or self-hosted Postgres server.
Silos runs the same PostgreSQL engine you already know — the difference is the operational model around it. This page compares capabilities honestly, without performance numbers we haven't published.
Capability comparison
| Capability | Traditional / managed Postgres | Silos |
|---|---|---|
| SQL engine | PostgreSQL | PostgreSQL (compiled to WASM) |
| Wire protocol | Standard | Standard |
| Always-on compute | Yes — you pay while idle | No — scales to zero |
| Provisioning time | Minutes | Seconds (design goal) |
| Branching | Manual (dumps/restores) | Copy-on-write snapshot forks |
| Edge replicas | Manual multi-region setup | On-demand materialization (rolling out) |
| In-browser engine | No | Yes — PGLite (PostgreSQL 16-based) |
| Billing | Provisioned capacity | Usage-based (compute + storage + transfer) |
This table compares the model, not benchmarked performance. Where a row is a design goal or still rolling out, it says so.
What stays the same
You keep standard PostgreSQL behavior: ACID transactions, MVCC, PL/pgSQL, triggers,
views, CTEs, window functions, JSON/JSONB, full-text search, and the SQL standard.
Your drivers and ORMs connect unchanged — see Connecting.
What's different to keep in mind
- Cold starts. An idle database has to materialize before it serves its first query. For latency-critical paths, keep a database warm or design for the first-query cost. See Scale to zero.
- Consistency is a choice. Reads from edge replicas can be eventual, read-your-writes, bounded-staleness, or strong — per query. See Consistency levels.
- Extensions in WASM. Most pure-SQL and many C extensions work; some heavyweight ones (e.g. TimescaleDB, Citus) are not available in the WASM runtime. See Extensions.
When a traditional server is the better fit
Silos shines for bursty, multi-tenant, branch-heavy, global-read, and agent-driven workloads. A single always-on primary with steady, heavy write throughput and a need for the full extension ecosystem may still be better served by a conventional managed Postgres today. See When to use Silos.