The OS and stack round — six axes, one reportable result

The OS and stack round — six axes, one reportable result

We swapped the operating system, PHP, MariaDB, nginx, Redis and the kernel under the same 6amMart, on the same hardware, with the same real shop's data, and measured each one. Not one version swap produced a speed difference worth reporting. The single axis that decided anything decided it on compatibility, not speed — so the recommendation that came out of this round is about how long each release keeps receiving security updates.

That is a negative result, and it is published here as prominently as a positive one would be. A round that finds nothing has told you something: once the configuration is right, which recent version of each component you run does not matter for this application.

The short answer

Three releases are supported by the native runtime, and each takes every serving component from its own distribution archive:

Node.js is the one exception on all three — a single declared version, 26.8.1, installed from an official tarball against a checksum rather than from a package repository.

If you want the decision rather than the evidence, which operating system is the shorter page. This one is the round.

The six axes, and what each returned

Same box wherever a component could be swapped live, so the hardware cancels. Same dataset, same tuning, same index set on every arm.

Five of the six say "nothing to choose". Where nothing separates the versions, the deciding question becomes which one stays patched with nobody doing anything — and that is the distribution's own archive by definition, because the automatic-update mechanism matches on the origin strings in each repository's own metadata and covers o=Ubuntu and origin=Debian and none of the third-party origins.

The noise floor, which limits every other number on this page

This is the most important figure in the round, and it is a figure about the measurement rather than the software.

Two servers from the same provider, with the same processor model, the same kernel, the same release, the same database build, the same buffer pool, the same worker count, the same cache settings and the same data, measured at the same time, came out 11.6 % apart — and did so on every single row, in the same direction. That was checked for the obvious explanations and none of them held: a processor benchmark that touches neither PHP nor the database matched within 1 % across all three machines, hypervisor steal time read 0.00 % and 0.02 % at idle, and the database files were identically fragmented.

So an effect smaller than about 19 % cannot be attributed to software when the two arms sit on different machines. That single fact is why this round was redesigned to swap components inside one box wherever physically possible, and why several earlier conclusions were withdrawn rather than defended.

Where each component comes from, and why that is the whole decision

A native install takes the web server, PHP, the database and the cache from the release's own archive. Nothing is compiled, and no third-party repository sits in the serving path, so a security fix arrives the way the rest of the operating system's fixes arrive.

That sounds like housekeeping. It is the entire recommendation, because five of six axes measured no reason to prefer anything else.

Node.js is deliberately the exception. The panel ships as compiled V8 bytecode, and V8 accepts bytecode only from the exact version that produced it, so a server drifting off the pinned version would leave a panel that cannot start. It moves on a release rather than on an update.

One detail the version numbers hide

Ubuntu splits its archive into main, which Canonical supports for the full five years, and universe, which is community-maintained and gets Canonical security coverage only under a Pro subscription. Debian makes no such split — its security team covers all of main.

Read from each package's actual pool path rather than from a suite label:

This is the strongest honest argument for Debian 13 over Ubuntu 26.04, and it is invisible in a table of version numbers. It does not overturn the recommendation — 26.04 keeps the longest support runway of the three and needs no third-party repository either — but it belongs in the decision, and 26.04 moving the database from universe to main is a real improvement over 24.04 rather than a version bump.

Ubuntu Pro is free for personal use on up to five machines, so a hobby server is covered either way. A commercial fleet is not.

The one OS comparison that survived attribution

Ubuntu 26.04 against Ubuntu 24.04 was the only cross-machine axis in the round, and the first attempt at it was thrown away.

The honest version moved the 24.04 arm onto the other arm's exact components on the same machine — the same PHP binary, the database upgraded in place to the same series, the same tuning, the same 601 indexes, the same caches, the same data. That makes it release-against-release with the software equalised:

And the control that keeps it honest: the two reference machines were both 26.04, on identical hardware with identical tuning, and one measured 18.9 % slower than the other on those same rows.

So the defensible statement is the only one we make: 26.04 is not slower than 24.04, and in every arrangement tried it is level to modestly ahead. There is no performance reason to prefer 24.04, and none to migrate a working 24.04 server. The +34.6 % figure must not be quoted, and neither should the +12 % without the sentence that follows it — the release effect and the hardware lottery are the same size.

What that comparison contains, honestly: a whole stack, not one variable. 26.04 brings kernel 7.0 against 6.8, glibc 2.43 against 2.39, nginx 1.28 against 1.24 and MariaDB 11.8 against 10.11, all at once. Which of those earned the lead is not answered — attribution was attempted and mostly failed to separate. "Build new servers on 26.04" is supported. "26.04's kernel is worth N %" is not.

Redis — the axis that decided something, and not on speed

The native runtime does not write its own service definition for Redis; it uses the distribution's own template, which waits for the server to report itself ready before the service counts as started.

The server itself is fine in the failing case — the process runs and would answer queries. The service never reaches "started". So the package install appears to hang on the same wait, and anything that checks whether Redis is up reports a permanently-starting service on a machine whose Redis works perfectly.

There is no speed number for this axis and none is needed. An arm that cannot be started cannot be measured, and it would be disqualified regardless of how fast it was.

A shortcut that looked like a diagnosis, and is retired

On Ubuntu, counting readiness-signalling strings inside the binary gave 5 for the working build and 0 for the failing one — which looked like a clean way to predict the problem without starting anything. Read across all four releases:

Three working builds report zero. A property that is identical on a build that works and a build that does not cannot tell them apart, so the count is now printed as a hint and the decision comes from starting the real service and requiring its own verdict. The conclusion — take the distribution's Redis — did not change. The stated reason for it did.

nginx and the kernel — two washes, in full

nginx. The two builds differ in more than version: the archive build carries the regex JIT and nginx.org's does not, and this configuration is regex-heavy, so the newer version could plausibly lose more to the missing JIT than it gains. Seven alternating pairs per box, with the version that served each pass read back off the running binary:

Three readings say wash rather than one: the whole-application difference has opposite signs on the two boxes, the sign inverts between concurrencies on both, and on Debian 12 the control rows — served from nginx's own cache without touching PHP or the database — move seven times further than the effect, in the opposite direction. The missing regex JIT costs nothing measurable here, which is worth saying because it was the reason to suspect the newer build might lose. It does not win either.

The kernel. A kernel cannot be swapped inside one boot, so this ran as A, B, A across three reboots, with the third leg as the control.

On Debian 12 the effect is two orders of magnitude smaller than its own control's drift, the sign inverts between concurrencies, and the same kernel measured twice scores differently from itself. On Debian 13 the control failed outright: the shipped kernel did not reproduce its own number, coming back 6.7 % slower — four times the size of the effect being measured — with control rows moving 14.5 %, and winning zero of 14 rows on its second outing. That is the machine drifting over the 90 minutes of the run. If the kernel were responsible, leg C would have returned to leg A.

What actually made the application faster

Nothing on this page is where the speed came from. Three configuration changes were worth more than every version swap in the round put together:

Version selection is a sub-2 % game beside those. The database-client one is worth reading in full on the database page, because the same mechanism silently invalidated that round's first set of database numbers — every one of which was discarded.

Claims from this round that were withdrawn

Each of these was written down as a finding before it was checked properly. They are recorded rather than deleted, because the wrong reading was the easy one to reach in every case.

Debian 12, and why the native runtime refuses it by name

Debian 12 was the fourth release in this round and its measurements are all still on record — a dropped release does not make its numbers false. It is no longer installable natively, and the reason is not speed.

Its normal security support ended in July 2026 — verified from the machine itself, whose own package suite label had already moved from "stable" to "oldstable" — and the only PHP its archive carries is 8.2, whose upstream security support ends 31 December 2026. Running a supported PHP there means adding a third-party repository whose origin the automatic-update mechanism does not cover, so those patches never arrive on their own. For the component with the largest attack surface in the stack, on a release that has already left full support.

The container runtime still installs on Debian 12, because a container brings its own PHP and database. You should still not start a new shop there: the kernel, the C library, the container engine itself and the SSH server all come from that host archive, and that is the part no longer getting fixes.

The support runway, which is what the recommendation actually rests on

And the components, which move on their own schedules:

Two things worth knowing from that table: 11.4 outlives 11.8, because MariaDB cut LTS binary support from five years to three after 11.4; and Redis 8.0's security support ends 1 December 2026, which affects Debian 13's 8.0.2 and Ubuntu 26.04's 8.0.5 — both will need their distribution to move to a supported branch.

A version string cannot answer a security question

Worth stating plainly, because it is the most common mistake made in the other direction. A distribution's older version number is not itself an exposure: the source is frozen and patches stack onto it. Comparing what a binary reports against upstream's release table produces false positives in both directions, and right now it produces them in both directions at once.

The clearest demonstration: Debian backported the 2025 Redis remote-code-execution set into its 7.0.15 packaging with no version bump at all. That package is upstream end-of-life and patched anyway, so asking the binary its version would tell you the opposite of the truth. Meanwhile two 2026 nginx advisories are fixed on both Ubuntus and open on both Debians — which the version numbers, 1.24.0 against 1.26.3, invert.

Check the security tracker row for the package you actually have. Not the number.

What this round does not tell you

Every measurement here is from a 2-core, 3.9 GB server. We have not measured 8 GB or larger, so nothing here predicts them.

It does not separate "which component earned the lead" on the one axis that produced a direction, and it says so above rather than guessing.

And it does not describe your shop. The data behind it is one real production dataset — 66,701 orders, 113,231 order lines, 17,534 customers, 192 tables — which is a genuine shop and is not yours.

Related

MariaDB versions, measured covers the database axis in full, including the measurement floor that invalidated the round's first set of database numbers. PHP versions, measured covers the four PHP pairings and the compatibility work that retired an earlier blocker. How we measure is the method, the traps, and where the raw data lives.

For the decisions rather than the evidence: which operating system and which database engine.