Laravel 13.38 stops you reading your own stale database writes
A new PreventStaleDatabaseReads middleware and a usingWritePdo method fix the classic read-replica-lag bug where a user saves something and then does not see it.
Laravel 13.38 shipped on 21 October with a fix for a bug most apps with read replicas eventually hit: a user saves a change, reloads, and sees the old version because the replica has not caught up yet.
The new PreventStaleDatabaseReads middleware is opt-in. After a request writes to the default connection, it stores a timestamp in the session, and for the next two seconds that user’s reads are routed to the write connection instead of a replica. You can add it to the web middleware group, or scope it to specific routes with a longer window. It only covers the default connection and only protects the user who did the write, so other users can still read stale data from a replica in that window.
The release also adds DB::usingWritePdo(), which sends every read inside its callback to the write connection and restores the previous setting afterwards, even if the callback throws. That is a fix on onWriteConnection(), which only routed the first query, leaving relationship loads inside the same callback free to hit a replica anyway.
Route::middleware(['web', PreventStaleDatabaseReads::class])->group(function () {
// routes here read from the write connection for 2s after a write
});
Why it matters: if you run read replicas and have ever had a support ticket about “I saved it but it didn’t stick”, this is exactly that bug, with a built-in fix instead of a bespoke sticky-session hack.
The caveat: it needs sessions and only tracks the default connection, so multi-connection setups still need their own handling.