PostgreSQL & InnoDB Internals
The general mechanisms as two real engines implement them: heap tuples, xmin/xmax, shared buffers and VACUUM versus clustered primary keys, redo and undo logs.
PostgreSQL keeps every row version inside the table's own 8 KB heap pages, stamps each one with the transaction ids that created and deleted it, and pays for that simplicity with dead tuples, VACUUM and transaction-id wraparound — this is the general storage, MVCC and durability machinery as one engine actually built it.
In InnoDB the table is a B+ tree ordered by primary key, secondary indexes store primary keys instead of addresses, old row versions live in undo logs rather than in the table, and durability rests on a circular redo log plus a doublewrite buffer — the same general mechanisms as PostgreSQL, with nearly every decision made the other way.
Two ways to put a table on disk — rows in a heap addressed by indexes, or rows inside the primary-key tree addressed by key — and every difference in query cost, write amplification, index size and bulk-load speed between PostgreSQL and InnoDB follows from that one choice.