The one thing to understand first
Because of MVCC, every UPDATE writes a new tuple version. Naively, that new version needs a new entry in every index on the table — even indexes on columns that did not change. On a wide, heavily-indexed, update-heavy table, that index maintenance dominates write cost and generates index bloat. HOT (Heap-Only Tuple) updates exist to avoid it.
If an update touches no indexed column and the new version fits on the same page, Postgres skips all index writes — so HOT eligibility is the single biggest lever on write cost for hot tables. Everything in this lesson is about engineering your schema so updates stay HOT-eligible.
The key insight
If an update changes no indexed column, then every index entry would point to a row whose indexed values are unchanged. So PostgreSQL can skip creating new index entries entirely — provided it can still find the new version starting from the old index pointers. HOT achieves this by keeping the update within a single heap page and chaining versions with line pointers.