Multi-version engines store prior row images in two broadly different ways: writing every new version as an additional tuple inside the table itself, or keeping the current row in place and chaining prior images in a separate undo/rollback area. Compare the read and write consequences of these two designs.

## The same logical model, two physical realizations Both designs implement identical semantics — versions stamped with creator and expirer, a snapshot deciding which one you see. They differ in *where the old image lives*, and nearly every practical difference between such engines follows from that one choice. ## Design A: every version is a tuple in the table An UPDATE writes a complete new tuple into the table's own storage and marks the previous tuple expired. **What it buys** - **Reads never reconstruct.** Whichever version your snapshot selects, it is a materialized row you read directly. Read cost is independent of how old your snapshot is, which makes long-running readers cheap and predictable. - **Rollback is nearly free.** Undoing means marking a transaction aborted; nothing has to be un-applied. - **No separate undo subsystem** to size, monitor, or exhaust. **What it costs** - **Write amplification.** A new tuple is the full row, even if one small column changed. Updating a wide row with a large text column rewrites all of it. - **Index maintenance.** The new version sits at a new physical location, so index entries must point at it. Naively that means inserting into *every* index on the table on every update, even indexes whose key columns did not change. Real engines mitigate this — a same-page update whose indexed columns are unchanged can be linked to the old tuple and skip index insertion — but the mitigation is fragile: it needs free space on the page, so fill-factor and page density become tuning concerns. - **Table growth and scan cost.** Dead versions occupy pages inside the table, so sequential scans read them and skip them, and the table's physical size reflects churn until cleanup reclaims space. - **Index entries can point at non-visible versions,** so an index-only read must still confirm visibility unless the engine maintains a side structure recording which pages are all-visible. ## Design B: current row in place, prior images in undo An UPDATE modifies the row where it lives and writes the information needed to reverse the change into a separate undo/rollback segment, linking the row to that record with a back-pointer; undo records chain to older undo records. **What it buys** - **The common case is optimal.** Most reads want the current version, and it is exactly where the index or scan lands — no chain walking, no dead tuples interleaved with live data. - **Stable physical layout.** The row's location does not change, so secondary indexes on unchanged columns need no maintenance, and index entries stay valid; clustered-index designs keep rows in key order rather than scattering new versions. - **Table size tracks live data,** not churn. **What it costs** - **Old readers pay per read.** A transaction whose snapshot is N commits behind must walk and apply N undo records for each row it touches. Cost grows with snapshot age and with how hot the row is, so a long analytical query over a churning table degrades non-linearly. - **Rollback is real work.** Aborting means applying undo records to restore rows, so rolling back a huge transaction can take as long as it took to run. - **Undo is a capacity resource.** The engine must retain every undo record any live snapshot might need. One forgotten long-running transaction forces unbounded retention; engines respond either by growing undo storage until it hurts, or by discarding old undo and failing readers with a "snapshot too old"-class error. - **Contention on undo structures** under very high write concurrency. ## How the tradeoff shows up in decisions - **Wide rows with hot narrow updates** (a counter column on a row carrying a large payload) suffer badly in the append design; splitting the volatile column into its own narrow table is a classic remedy. - **Many secondary indexes plus high update rates** amplify the append design's write cost; index count is a first-order tuning lever there. - **Long analytical reads against an OLTP table** are cheap-ish in the append design and dangerous in the undo design — both because of reconstruction cost and because of undo retention. - **Bulk deletes or updates** leave a large space debt in the append design and a large undo burst plus long rollback in the undo design. - **Retention of very old versions** is a hard capacity limit in undo designs and a soft (space and scan-cost) penalty in append designs. ## Answering well Do not present one design as superior. State the axis — *where the old image lives* — then derive each consequence from it: read path, index maintenance, write amplification, rollback cost, growth location, and which resource runs out first under a long-running reader. Naming real engines as exemplars is useful; the point is the mechanism, not the product.