A healthy PostgreSQL replica may still be too old for the next read

A read immediately after a write carries an expectation that an ordinary read may not: it should include the change just acknowledged. Sending that request to a healthy replica does not establish the expectation. The application needs a replay-position condition tied to the write, or it needs to read from the primary. Availability and freshness answer different questions.

That distinction belongs in the request's contract. If a user saves an edit and the next screen can legitimately show older data, the product should define that behavior. If the next screen promises to show the edit, routing needs enough information to honor the promise. A generic policy of distributing reads cannot infer which writes a particular request depends on.

The beta made the condition visible

The PostgreSQL 19 Beta 1 announcement of 4 June 2026 previews WAIT FOR LSN for read-your-writes patterns. Its purpose is to wait for replay through a specified log position before a query. The announcement is beta evidence, explicitly discouraging production use of beta releases, rather than a recommendation to deploy that version.

The enduring design idea is useful independently of that release: a dependent read needs evidence that its chosen server has applied the relevant change. A server can be reachable and able to answer queries while still being behind that point. A health check may establish service availability without establishing that this read's prerequisite has been met.

An illustrative document edit makes the consequence concrete. The primary acknowledges a saved title. The following request opens the document through another connection and reaches a replica that has not yet replayed the commit. A successful query can return the old title. Transport success and query success do not, on their own, prove the promised read-after-write behavior.

Use replay as the relevant condition

A freshness contract needs a position that covers the committed write. It also needs to apply the condition to the server that will serve the dependent read. Waiting on one replica and then routing the query to another would discard the evidence just obtained. The request must preserve the relationship between the prerequisite and the operation it authorizes.

The PostgreSQL 19 WAIT reference accessed on 9 November 2026 is later documentation, with no publication date observed here. Its distinction between replay, write and flush modes helps explain the contract. Receiving or durably storing log records is not the same as applying them so that queries can see their effects. Exact syntax and timeout details from that reference should not be projected back onto the June beta API.

This later reference also requires a suitable position covering the commit for read-your-writes. The application cannot choose an arbitrary earlier log position and assume it includes the transaction. The boundary should carry evidence about the acknowledged write, not merely a recently observed number.

Even a successful wait needs the subsequent read to use a suitable snapshot. A view of data fixed before the relevant change can defeat the intended result. That is another reason to treat the wait and the read as parts of one designed operation rather than independent utilities placed somewhere in the request path.

Waiting needs an unsuccessful outcome

Under replication lag, waiting consumes part of the request's latency budget. A timeout must therefore have a defined meaning for the caller. It cannot be silently interpreted as evidence that replay completed. A product may choose a primary read, a visible retry state or another explicit failure response when the prerequisite is not met.

Those alternatives have different costs. Returning older data may be acceptable for a browse page with a documented freshness tolerance. It is a different contract from confirming the result of the user's own edit. The application should decide which contract applies before choosing how long to wait or where to route the fallback.

The strongest counterargument to replica waiting is that keeping the next read on the primary may be cheaper and simpler. For a limited number of dependent reads, a position token and coordinated wait may add more complexity than they save. Under sustained lag, avoiding the wait can also avoid spending most of a request's budget on a prerequisite that is unlikely to complete in time.

This is not a universal primary-only recommendation. Reads that tolerate older data can still benefit from a different route. The point is to separate those reads from requests whose correctness depends on a particular write. Compare the complexity and latency of the two designs using the workload's actual requirements, rather than assuming a replica is always the more economical destination.

Preview availability did not change the production contract

AWS announced RDS preview availability on 8 June, later than the community beta announcement. The vendor described instances retained for at most 60 days before automatic deletion and snapshots restorable only within the preview environment. Those historical preview limits reinforce the distinction between evaluating a feature and adopting a production dependency.

A managed preview does not establish application correctness or remove the need for an exit plan for evaluation data. It provides a place to evaluate a prerelease under stated restrictions. It says nothing about whether a particular product has chosen a valid replay condition, handled timeouts or preserved the relationship between wait and read.

For custom software development, define the next-read promise alongside the save operation. State which changes must be visible, what evidence permits a replica read, and what happens if that evidence is unavailable. Then decide whether a coordinated wait or a primary read is the simpler way to fulfill that promise.