Read & write paths
Reads are served from the nearest replica; writes forward to the primary. How the split works and what it means for your app.
Silos uses a single-primary, many-replica model. Understanding which operations go where is the key to reasoning about latency and freshness.
The split
| Operation | Where it goes |
|---|---|
| Reads | Nearest healthy replica (or the primary if no local replica / strong consistency) |
| Writes | Always the primary |
| Transactions that write | The primary (the whole transaction) |
| DDL / schema changes | The primary |
Read path
A read lands in the region GeoDNS routed the client to. If a local replica exists, it serves the read directly — that's the local-latency win. The consistency level on the query decides whether a possibly-stale local read is acceptable, or whether the router must wait for the replica to catch up or fall back to the primary.
Write path
A write is forwarded to the primary no matter which region the client connected from. The primary commits it to the write-ahead log, and that change then propagates out to replicas. This is why a client far from the primary pays a round-trip on writes even when its reads are local.
Because writes always go to the primary, a steady high-write firehose from a distant region will feel the primary's round-trip on every write. Place the primary near your heaviest writers, and lean on local replicas for the read-heavy majority.
Read-after-write within a session
A common worry with replicas: I just wrote a row — will my next read see it? Silos addresses this with read-your-writes consistency (the default), implemented using LSN tokens. A write returns a log position; a subsequent read can require the replica to have caught up to at least that position, or be routed to the primary. See Read-your-writes for the mechanism.
Practical guidance
- Read-heavy, globally distributed app: let reads hit local replicas; accept eventual or read-your-writes consistency where you can.
- Must always see the freshest data: use
strongconsistency, which reads from the primary. - Write-heavy single-primary workload: this is the model's weak spot — keep writers near the primary and consider whether a conventional single-region Postgres fits better (see Silos vs. Postgres).
Cross-region replica reads depend on the rolling-out global replication path. Until multi-region streaming is production-proven, plan reads against the primary region as the dependable baseline. See the Replication overview.