Dissecting PostgreSQL — Why Being Read-Optimized Comes at the Cost of Write Speed

The article explores PostgreSQL internals to explain why it is read-optimized at the expense of write performance. It covers storage layout (8KB pages, heap files), tuple structure with MVCC headers (t_xmin/t_xmax), and the write path—WAL logging followed by random I/O to locate and update data pages—showing how one logical write becomes multiple physical writes by design. The post contrasts this with LSM-tree databases like Cassandra, framing Postgres's write cost not as a flaw but as a deliberate architectural tradeoff.