Replica materialization
How an on-demand edge replica is created near your users, hydrated from object storage, and kept current via the WAL.
An edge replica in Silos is lazy and on-demand: it doesn't exist until a region needs it, and it's built from the same durable state that backs the primary — compressed snapshots plus WAL segments in object storage.
Replica materialization and the global WAL streaming that keeps replicas current are rolling out. The hydration and streaming code is implemented, but the end-to-end path is not yet proven in multi-region production. Treat this page as the intended design and current direction, not a production guarantee.
Lifecycle of a replica
A region needs a local copy
When reads arrive from a region that has no local replica, the platform can decide to materialize one there rather than send every read back to the primary's region.
Hydrate from storage
The new replica loads the latest snapshot for the database from object storage and replays any newer WAL segments to reconstruct current state. This is the replica's own cold start — conceptually the same hydration that wakes an idle primary.
Follow the WAL
Once hydrated, the replica stays current by following the database's write-ahead log. In the target design, WAL records stream out from the primary so replicas apply changes shortly after they're committed.
Serve local reads
The replica answers reads for its region, subject to the consistency level the query asks for. Writes are never served here — they forward to the primary (see Read & write paths).
Scale away when idle
Because a replica is on-demand, it can be torn down when its region goes quiet, freeing compute. The durable state always remains in object storage, so the replica can be re-materialized later from the same snapshots and WAL.
Why lazy materialization
Pre-provisioning a replica in every region for every database would be expensive and mostly idle. Materializing only where and when there's demand keeps the cost model aligned with Silos's scale-to-zero philosophy: you don't pay to keep copies warm in regions nobody is reading from.
What this means for you
- The first read in a fresh region pays a hydration cost while the replica materializes. Subsequent reads in that region are local.
- A newly materialized replica may briefly lag the primary until it catches up on the
WAL. If a read must see your latest write, use
read-your-writes or
strongconsistency, which can route to the primary or wait for the replica to catch up.