Modern web applications have a real problem: they're so fast that they can outrun database replication. When you write data to the primary database and it returns success, your frontend immediately tries to read it back. But that data hasn't reached the replica yet—it's still in transit or waiting to be replayed. So the user sees their change vanish, then reappear seconds later. The issue got worse with real-time collaborative apps, where every change invalidates cache across multiple devices simultaneously. Teams have been hacking around this with crude workarounds like pinning reads to the primary (defeating the whole point of replicas), adding arbitrary sleep delays, or using Redis flags to guess replication lag. The real problem is that the application has no way to know where the replica actually stands. PostgreSQL 19 adds a direct solution: `WAIT FOR LSN`. After writing to the primary, you grab the commit position (LSN), then on the replica you run `WAIT FOR LSN '0/554D1B78'` and it blocks until that exact position has been replayed. The standby already knows where it is; this just lets your code ask. The measurements are brutal. Reading immediately from a replica after a write misses 992 out of 1,000 times. Sleeping 50ms before reading fixes staleness but costs 54ms per request. `WAIT FOR` serves all 1,000 reads correctly and adds only 2.8ms at p50—two extra round trips, one to learn the LSN and one for the wait itself. It's faster than synchronous replication tricks like `synchronous_standby_names`, which can still serve stale data because it only waits for flush, not replay. The real architecture decision sits in the `TIMEOUT` parameter. Set it to 500ms and reads wait on the replica; set it to 5ms and they fall back to the primary when lag exceeds that window. This isn't about correctness—stale reads never happen—it's about where you're willing to accept latency versus load. The catch: during a cluster-wide lag event, all those timeouts expire at once and hammer the primary with the exact traffic it was built to avoid. You've solved the staleness problem but created a new failure mode.