In Postgres an UPDATE is an insert, and your page space pays for it

A dev.to walkthrough of PostgreSQL storage lays out the mechanic most application developers have backwards: an UPDATE does not change the old value in place, it writes a new tuple version and leaves the previous one sitting in the page ^[8]. The consequence is that a table with a flat row count can still grow, because heap occupancy tracks how many times you wrote, not how many rows you keep ^[16][17].

The physical layout is worth being precise about. PostgreSQL stores table data in fixed-size pages, usually 8 KB ^[1], and each page holds multiple tuples, which is what Postgres internally calls a row ^[2]. A page is not a stack of rows; it has a header, an array of line pointers, free space, and the tuples themselves ^[3]. Each line pointer records the byte offset and length of one tuple inside that page ^[4]. The `ctid` system column exposes a pair of (block number, item identifier number), where the second number identifies a line pointer rather than a byte offset ^[5]. A B-tree index does not carry the row, only a TID that locates the heap tuple ^[6], so a lookup goes index, then TID, then heap page, then line pointer, then tuple ^[7].

Now run the update. In the source's example the original tuple sits at (0,1) with age 25; after the update the old version stays at (0,1) and a new version appears at (0,2) with age 30 ^[8]. The reason given is that another transaction may still need to see the old value, which is the basis of MVCC ^[9]. Tuple headers carry xmin, the transaction that created the version, and xmax, the transaction that deleted or replaced it ^[10]. With transaction 8 doing the update, the old tuple carries xmin 5 and xmax 8, and the new one carries xmin 8 ^[11]. A SELECT does not simply take the highest ctid; it takes whichever version is visible in its snapshot ^[12], and the real rules involve transaction status and the snapshot's view of committed and in-progress transactions, not a bare comparison of xmin and xmax ^[13]. That is how two concurrent transactions read different versions of what looks like one row ^[14].

Two operational facts fall straight out of that. First, one row updated n times, with nothing reclaimed, means n+1 tuple versions and n+1 line pointers in the heap ^[16]. Second, the new version in the example landed in block 0, the same page as the old one, which only works if that page still had free space; the source does not say what happens when it does not ^[18]. Nor does it say how index entries follow the move, even though the new version has a different TID from the one an existing index entry addresses ^[19].

That gap is the honest limit of this material. The explainer reaches the question of what happens to the old version and is cut off mid-sentence, with no treatment of reclamation, vacuum settings, or fill-factor ^[15]. So take the storage model as established and the cleanup story as unwritten. What to watch is whether the follow-up quantifies the reclamation side, because the sizing question sits entirely there: everything above only explains why dead versions accumulate, not what it costs to get rid of them ^[15][16].