The Reddit version of this story was simple enough to travel: Linux 7.0 landed, PostgreSQL throughput got cut in half, and a kernel change broke one of the most widely deployed databases on the planet.

That is not quite false. It is just much sloppier than the underlying facts deserve.

A real benchmark did show a huge regression after Linux 7.0 removed PREEMPT_NONE on modern architectures. But the most useful lesson is not "kernel upgrades are dangerous." It is that a very specific PostgreSQL setup, a very large shared memory footprint, and missing huge pages can turn a scheduler change into a loud performance disaster. The headline went viral because it sounded general. The evidence looks much narrower.

What is actually verified

A Reddit-hot r/programming post linked to an explainer about a Linux 7.0 / PostgreSQL performance drop and quickly pulled in the usual mix of curiosity, skepticism, and headline correction.

The kernel-side change itself is easy to verify. Peter Zijlstra's Linux commit 7dadeaa6e851 is titled sched: Further restrict the preemption modes. Its commit message says up-to-date architectures such as arm64, x86, powerpc, riscv, s390, and loongarch are left with only two preemption models, full and lazy. In other words, PREEMPT_NONE is gone on the architectures most server operators care about.

The benchmark that made this controversial is also clearly documented in Christophe Pettus's writeup on the build. He cites an AWS benchmark on a 96-vCPU Graviton4 system running PostgreSQL 17 with 1,024 clients, 96 threads, and a very large shared memory footprint. In that setup, the Linux 7.0 path produced about 50,751 transactions per second, while reverting the preemption-mode change brought it to about 98,565. perf showed more than half the CPU time tied up around StrategyGetBuffer() and s_lock, which is exactly the kind of ugly spinlock symptom that gets attention fast.

Those numbers are real. So is the regression.

What matters is the rest of the setup. Both Pettus and a later, more DBA-focused analysis from My DBA Notebook point to the same critical detail: the benchmark had huge_pages=off. The follow-up analysis says the worst behavior appeared during buffer-pool warmup on a 100GB+ shared buffer pool using ordinary 4KB pages. It also says that when huge pages or Transparent Huge Pages entered the picture, the dramatic regression did not reproduce in the same way.

That is the point many viral summaries skipped. The benchmark was not just "Linux 7.0 versus PostgreSQL." It was Linux 7.0 plus a very specific memory configuration that amplified contention in a place PostgreSQL is already sensitive.

Why this matters more than the headline

If you stop at "Linux 7.0 broke PostgreSQL," you learn the wrong lesson.

The deeper story is about what happens when a database and a kernel have been quietly leaning on an old scheduling assumption for years. PostgreSQL has long used short critical sections and userspace spinlocks in hot paths where the old tradeoff made sense: the lock holder would usually run to completion quickly, and the waiters would spin only briefly.

Once PREEMPT_NONE disappears, that assumption gets weaker. A thread holding a spinlock can now be interrupted under PREEMPT_LAZY. If that same workload is also paying page-fault and translation overhead because huge pages are off, one short critical section can turn into a much nastier pileup.

That does not mean the kernel team was wrong to simplify preemption modes. The official commit message makes the direction of travel clear: newer architectures are being pushed toward a more uniformly preemptible model. It does mean downstream software that depended on older behavior gets less free protection from the scheduler.

That is why this story matters outside PostgreSQL circles. It is a reminder that "works on Linux" often hides a stack of assumptions about page size, scheduling, host ownership, and whether the machine is really tuned like a database box instead of a generic cloud petri dish.

The real developer consequence is not the benchmark chart

The practical problem here is less about one scary chart and more about where modern infrastructure makes the right fix awkward.

If you run PostgreSQL on a machine you actually control, the advice coming out of the follow-up analysis is boring and old for a reason: use huge pages properly. Pettus goes further and says huge_pages = on, not try, because silent fallback is how teams drift into slow configurations without noticing.

If you run PostgreSQL inside containers or on managed platforms, the story gets worse. Huge pages and Transparent Huge Pages are host-level concerns. That means the clean fix can be easy on bare metal and annoyingly indirect in container-heavy setups where the database team does not control the host kernel, the node image, or the memory reservation policy.

That is why this topic hit so hard on Reddit and Hacker News. Developers were not only reacting to a Linux scheduler detail. They were reacting to a bigger operational fear: a lot of "modern" infrastructure is still shaky around the old, unglamorous parts of systems performance.

The public reaction was more useful than the headline

The best Reddit comments immediately pushed back on the title. One commenter summed it up bluntly: PostgreSQL was not broken, a kernel change degraded performance, and some configuration changes could restore it. The original poster even conceded in-thread that the title was "a bit sensationalist" and that the article was really about a significant impact on a specific benchmark.

Hacker News showed the same split. The story had enough momentum to hit the front page, but the more technical comments treated it as a special-case regression, not evidence that Linux 7.0 is broadly unsafe for PostgreSQL. The interesting discussion was around the workload shape, lock behavior, and whether this was exposing an old deployment mistake rather than a new universal bug.

That reaction is worth taking seriously. Crowd discussion is noisy, but in this case the noise converged on a sane conclusion: the regression is real, the generalization is weak.

What remains uncertain

A few details still need restraint.

First, the kernel commit is primary and easy to verify. The exact benchmark interpretation is messier. The original mailing-list discussion is referenced consistently by the follow-up writeups, but parts of that thread were not cleanly retrievable from this headless environment, so some benchmark details here are corroborated through those analyses rather than quoted line-by-line from LKML.

Second, the strongest public writeups agree on the broad shape of the problem: PREEMPT_NONE disappeared, the benchmark was large and highly parallel, huge pages were off, and the dramatic result became much less dramatic once memory-page behavior was addressed. But the farther you get from those concrete facts, the more you are in expert interpretation territory.

Third, none of this proves that typical production PostgreSQL deployments will lose half their throughput when they move to Linux 7.0. The verified evidence supports a narrower claim: a specific, reproducible benchmark showed a major regression under a configuration that many experienced PostgreSQL people would already consider questionable on such a large machine.

The useful takeaway

This was never just a Linux story.

It was a trust-boundary story between applications, kernels, and infrastructure defaults. For years, PREEMPT_NONE quietly masked some ugly cases where PostgreSQL's lock behavior and poor memory-page choices could interact badly. Linux 7.0 removed part of that cushion. The benchmark made the failure mode visible. That is uncomfortable, but it is also useful.

If you run serious PostgreSQL, the lesson is not to freeze kernel upgrades in panic. It is to check whether your stack depends on old scheduling assumptions, whether huge pages are actually configured instead of merely hoped for, and whether your container platform makes the right performance fix harder than it should be.

The viral headline was "Linux 7.0 broke PostgreSQL." The more honest version is sharper: Linux 7.0 exposed how easy it still is to benchmark a database in a way that confuses infrastructure debt for a universal kernel failure.

Sources