The number the demo does not print is the write count. Session A's DELETE has to visit every one of the million rows to stamp `xmax` on the live version, and it removes none of them [1][5]. The table Session B scans therefore still holds a million versions after the delete, each now carrying a death certificate [1]. "No locks, no blocking, no errors" [2] describes the relationship between the reader and the writer. It does not describe the writer's bill.
Run the same experiment as an UPDATE and the arithmetic doubles. An update here is a delete and an insert stapled together, so the million old versions stay and a million new ones are appended [6][2]. That is also the cheapest way to confirm a real Postgres is doing this rather than mutating in place: `SELECT ctid` before and after an UPDATE, and the row's physical address has moved [6].
The model being displaced is the table as a big mutable array, where UPDATE overwrites a slot and DELETE frees one [13]. Under that model the demo is impossible, because Session B has nothing left to read [13], and the only way to make in-place mutation safe was locks: readers waiting on writers, writers waiting on readers, and one long report capable of freezing every write to the table [3].
The two stamps alone still are not enough, and the post is honest about where they break. Take the naive rule that a version is visible when `xmax` is null. Session A stamps `xmax = 2` across the table and has not committed, so Session B sees nothing; then A issues ROLLBACK, and B has read a state of the world that never existed [8]. So `xmax = 2` has to mean either "gone" or "never happened" depending on the fate of transaction 2, and nothing stored on the version says which [3]. Visibility is a property of the reader plus the writer's status, not of the row.
That is precisely where the text I was given stops, mid-sentence, at "The fix: a stamp on" [9]. What the post promises past that point is about 100 lines of TypeScript pointed at real Postgres, with the columns matching one to one [11]. I can report the promise; I cannot report the result.
What survives from the part that exists is a small vocabulary. A transaction is a number from an incrementing counter, so txids double as timestamps and ordering comes free: smaller means earlier [7]. Versions are appended, never overwritten, and a row is the whole history in order [5]. The post's claim is that this same accounting is how Postgres, MySQL/InnoDB, Oracle and SQLite in WAL mode keep readers and writers out of each other's way [10]. If that holds, the hundred lines are worth more than the psql session that motivated them, because the psql session only shows you the outcome.
