Latency expectations
Design targets for cold start, edge reads, and replication lag — clearly labeled as goals, not benchmarks.
This page sets honest expectations about latency. Everything here is a design target — a goal the architecture is built to reach — not a benchmarked guarantee. Silos has not published measured latency numbers, and you should not treat the figures below as an SLA.
The numbers on this page are design targets, not measured benchmarks. Real-world latency depends on region, network, database size, and workload. Don't size a production system against these figures as if they were guaranteed.
What affects latency
- Cold start. An idle database (or a region's first read) must materialize before it serves a query: load the snapshot, replay recent WAL. This adds one-time cost to the first request. See Scale to zero and Replica materialization.
- Read distance. A read served by a local replica avoids the round-trip to the primary's region; a read that must hit the primary pays it.
- Consistency choice. Stronger consistency can mean waiting for a replica to catch up, or routing to the primary — both can add latency. See Consistency levels.
- Write distance. Writes always forward to the primary, so a distant writer pays the round-trip on writes regardless of local replicas.
Design targets
| Dimension | Design target | Status |
|---|---|---|
| Cold start (wake an idle database) | Sub-100 ms | Target — not yet benchmarked |
| Local edge read (warm replica) | Single-digit ms / sub-ms in-process | Target — depends on region & workload |
| Global replication lag | ~50–200 ms | Target — global streaming is rolling out |
A warm, in-process read from a co-located replica can be very fast — the in-browser PGLite engine reads in-process, for example. But "fast in one setup" is not a platform SLA. Until benchmarks are published, treat the table above as engineering goals.
Designing around cold starts
If first-query latency matters for a hot path:
- Keep the database warm with light periodic traffic so it doesn't scale to zero.
- Accept the first-query cost for paths where occasional latency is fine (most background and batch work).
- Warm a region before a known traffic spike by sending an early read so a replica materializes ahead of demand.
Why we don't publish hard numbers
Silos is in active development and the global replication path is still rolling out. Publishing a precise latency figure before it's measured end-to-end on deployed infrastructure would be misleading. When benchmarks exist, they'll be published as benchmarks — clearly distinct from the targets here.