Everything in Posts 2 through 5 - the B+Tree structure, the LSM write path, the compaction effect, the secondary index cost, happens on a single machine. The performance differences are real and they matter. But the moment you add a second node, the binding constraint shifts entirely. Network latency between nodes is measured in milliseconds. The p50 write latency difference between PostgreSQL and Cassandra on a single node is measured in microseconds. The network is 100× slower than the storage engine. It doesn't matter how fast your CommitLog append is if the replication acknowledgment takes 5ms across a data center.
Multi-node also introduces a class of failure that doesn't exist on a single machine: the network partition. Two nodes that can't reach each other, each believing they're the healthy one. When that happens, every database must make a choice. And the choice each one makes reveals its fundamental design philosophy more clearly than any benchmark.
This post covers how each database behaves at the cluster level, then ends with the decision framework the whole series has been building toward.
PostgreSQL Multi-Node
The honest starting point
