Postgres is half as fast in Linux 7.0, and we always knew why

An Amazon engineer discovered a 50% performance regression in Postgres running on the upcoming Linux kernel 7.0. The root cause is a Linux default change from 'preempt none' to 'preempt lazy' for kernel code. This means kernel operations like page faults can now be preemptively scheduled out. When a Postgres process holds a spinlock on shared memory and then triggers a page fault, it can now be preempted while holding that lock, causing all other waiting processes to spin uselessly. The workaround is enabling huge pages, which drastically reduces page fault frequency. But the fundamental design tension remains: Postgres uses a process-per-connection model, so every new backend inherits an empty page table. Under high connection counts, this generates massive, continuous page fault overhead that the new kernel default amplifies. The discussion is not about a bug but about how a legitimate kernel improvement for fairness interacts poorly with a decades-old database architecture choice. This is a case study in how infrastructure defaults can silently reshape application performance profiles, and why architectural assumptions must be re-evaluated as the layers beneath them evolve. The immediate fix is operational (enable huge pages). The deeper signal is the growing cost of process-based concurrency on modern Linux, and whether teams running Postgres at scale need to start planning for or advocating a thread-based architecture.