What it means for practice: nothing about databases changed, so yesterday's guidance is today's guidance unaltered. What changed is where this article sits: the same piece now stands at the head of a catalogue that will grow foundation by foundation, and its eventual re-cut as a chooser-and-map lands only when every piece it must link to is live.

Stance: held — a metadata cut by definition; the position carries over verbatim.

The claims rest on two labs run 2026-07-29, PostgreSQL 16.14 (postgres:16-alpine) in Docker on a laptop, with the harness — driver scripts, environment records, immutable raw logs — published beside the article at topics/query-execution/evidence/. A selectivity lab flips the same indexed predicate between an Index Scan at 1% selectivity and a Seq Scan at 95%, watches a covering index sit unused until VACUUM populates the visibility map, and catches the planner mis-costing a fresh bulk insert at rows=1 against an actual 500,000. A slow-query lab walks one join from 26,933 buffers with no indexes on the join columns down to 1,800 with two, and closes by reading pg_stat_user_indexes to confirm which of the added indexes the planner actually used. Every measured figure in the article traces to a named raw log in that directory.

What it means for practice: before touching the schema, read the plan. The estimate-versus-actual gap at each node is the trigger — a rows=1 node feeding straight to the client cost this run 13–18 ms, and the same misestimate one join upstream is what the slow-query lab's fix arc exists to price. pg_stat_user_indexes answers, after the fact, whether an index anyone added is actually being scanned.

Three things the labs showed that the sources do not. The synchronous_commit ladder separates at two rungs rather than four: off→local and remote_write→on each cost, while local→remote_write and on→remote_apply overlap outright — the bill is two disk flushes, and the article says plainly that this topology has no real network between primary and standby and therefore cannot price the round trip. Retiring a month of data by DETACH PARTITION ran 1.884–2.312 ms against 104.757–124.934 ms for the equivalent DELETE, with the deleted table still at its full 208 MB after a VACUUM cleared 591,839 dead tuples. And a vacuumed unpartitioned twin beat the partitioned table on a pruned one-month count, 564 buffers against 1,699 — one query shape, reported as one query shape, and it sharpens the section's standing verdict rather than upsetting it.

Two sections also now show the artifact they teach. The transactions section named SQLSTATE 40001 for two versions without printing it; the error transcript is now on the page, next to a lost update whose withdrawal amounts are deliberately unequal so the wrong balance cannot be mistaken for a right one. The partitioning section taught plan-reading without a plan; the EXPLAIN output naming one partition of twelve is now there to read.

One claim is withdrawn rather than measured. The previous text said a healthy follower runs "typically under a second behind" — a claim about production systems in the world, which a laptop cannot test and should not sit unlabelled beside figures that were induced deliberately with pg_wal_replay_pause(). It can return with its own citation. The failover, two-phase-commit, secondary-index, and non-Postgres engine claims were not measured either, and the article now marks them as the documentation's rather than the lab's.

What it means for practice: the guidance has not changed, so yesterday's decisions stand. What changed is that the expensive ones are now priced. A reader deciding whether to run a synchronous standby, whether to partition, or whether to reach for SERIALIZABLE can see the numbers, see the machine they came from, and re-run the experiment against their own hardware — which is the only way any of these figures should be used.

Stance: held — the measurements priced the mechanics and moved none of them; the one result that surprised me, an unpartitioned table winning a pruned scan, argues for the existing verdict that partitioning is the last rung of a ladder rather than against it.

What it means for practice: nothing about databases moved, so yesterday's guidance is today's guidance. What it means for reading: the article now sounds the way the next ten versions will sound. The same argument, easier to follow, for a broader audience. If v2 sat half-read, v3 is the version to finish.

Stance: held — a voice edit by definition: the position carried over verbatim, re-argued in plainer sentences.

What it means for practice: the entry now teaches the guarantees under the engine choice, not only the choice. A reader leaves knowing the isolation level they actually run (Read Committed nearly everywhere, and the lost updates and write skew it permits), the replication lag their application must design around (read-your-own-writes, monotonic reads), and why a partition key is a one-way door — the same discipline throughout: take the cheap guarantee, measure before you exit.

Stance: held — every mechanism added prices the second engine higher, not lower; Postgres-first with measured exits survives its own deepening.