# Which PHP, database and OS version

> Source: https://www.allsweb.com/sixpreflight/docs/versions
> Markdown for agents: https://www.allsweb.com/sixpreflight/docs/versions.md
> Publisher: AllsWeb (www.allsweb.com)

Part of: SixPreflight documentation

Three PHP versions, five database engines and four operating-system releases, all run against a real 6amMart shop — 66,701 orders, 113,231 order lines, 17,534 customers. Every number here was measured on that data, not copied from a vendor's benchmark page.

## What to install

**Ubuntu 26.04 LTS, and whatever PHP, MariaDB, nginx and Redis that release ships — which is PHP 8.5 and MariaDB 11.8.** Not because it is faster. On identical servers running the same shop, no version swap on any of the three supported releases produced a speed difference big enough to report. What separates them is how long each one keeps getting security updates, and 26.04 is patched until April 2031.

:::checks
- Ubuntu 26.04 LTS — security updates to Apr 2031, against May 2029 for Ubuntu 24.04 and Aug 2028 for Debian 13. That is the whole reason it is first.
- PHP 8.5 — the version 26.04's own archive ships, and it runs 6amMart. Measured on PHP 8.5.4 against both the plain CodeCanyon tree and optimised 6amMart, on 27 August 2026.
- MariaDB 11.8 — also from 26.04's archive, and a wash against 10.11 on this shop's own queries.
- Take every serving component from the chosen release's own archive. Security updates then arrive through the distribution, with no third-party repository anywhere in the serving path.
:::

## Everything, ranked

| Option | Runs 6amMart | Speed | Supported until | Verdict |
|---|---|---|---|---|
| Ubuntu 26.04 LTS | yes | no reportable difference | Apr 2031 | Use this |
| Ubuntu 24.04 LTS | yes | no reportable difference | May 2029 | Supported — the fallback when a provider has no 26.04 image yet |
| Debian 13 (trixie) | yes | no reportable difference | Aug 2028 | Supported, shortest runway of the three |
| Debian 12 (bookworm) | container runtime only | not measured on the final stacks | ended 11 Jul 2026 | Do not start a new shop on it |
| PHP 8.5 | yes | no measurable difference | Dec 2029 | What Ubuntu 26.04's archive ships |
| PHP 8.4 | yes | no measurable difference | Dec 2028 | What Debian 13's archive ships |
| PHP 8.3 | yes | no measurable difference | Dec 2027 | What Ubuntu 24.04's archive ships; upstream bug fixes stopped Dec 2025 |
| MariaDB 11.8 | yes | a wash against 10.11 | Jun 2028 | What Ubuntu 26.04 and Debian 13 ship |
| MariaDB 10.11 | yes | a wash against 11.8 | Feb 2028 | What Ubuntu 24.04 ships |
| MariaDB 12.3 | yes | see the correction below | newest LTS | Not shipped by any supported release; you would be adding a repository for it |
| MySQL 8.4 | no | 18% slower | Apr 2032 | Item search fails on every request |
| MySQL 8.0 | no | 15% slower | already ended | Same breakage, and out of support |

## PHP — 8.3 vs 8.4 vs 8.5

| Measurement | PHP 8.3 | PHP 8.4 | PHP 8.5 |
|---|---|---|---|
| Raw processor work, no database (ms) | 989 | 974 | 978 |
| Time the app spends in PHP per page (ms) | 593 | 576 | 568 |
| Runs 6amMart | yes | yes | yes |

The three versions are within one to three percent of each other — about the same margin as simply re-running the same test twice on the same machine.

A later round settled it properly, on a server with both 8.3 and 8.4 installed, giving the 8.3 pool the **entire** 8.4 tuning first and verifying every setting from the running process rather than from a file. Three alternating pairs: geometric mean 8.3 against 8.4 is **0.9994** — 8.3 ahead on 3 rows of 7, and every difference smaller than at least one arm's own run-to-run spread.

Upgrading PHP will not make your shop faster. Choose on what your release ships and what is still getting security fixes, not on speed.

:::note The native runtime installs a different PHP on each release, and that is deliberate
It takes the PHP the chosen release's own archive carries — **8.5** on Ubuntu 26.04, **8.4** on Debian 13, **8.3** on Ubuntu 24.04 — so security updates arrive through the distribution and no third-party PHP repository sits in the serving path. The distribution maintains those packages for the life of the release, which is a different support line from php.net's own end-of-life dates.

The table above is why that costs nothing measurable: all three run this application at the same speed.

SixPanel Docker is a separate product with a separate answer. Its PHP comes from a container image (`php:8.4-fpm`), so it is **8.4** regardless of what the host release ships. Neither choice is a speed decision.
:::

### Correction — PHP 8.5 is not ruled out

An earlier version of this page said PHP 8.5 could not install 6amMart's components, because the spreadsheet library behind Bulk Import, Bulk Export and every Excel report declares a requirement of PHP below 8.5. That was wrong, and the correction matters because it was the only argument against 8.5.

The `<8.5` bound is a **declaration in a package's metadata, not a measurement**, and nothing in a running 6amMart enforces it — the platform check that would is switched off. So the question was settled by running the code instead of reading the constraint. On **PHP 8.5.4**, on 27 August 2026, against both the plain CodeCanyon tree and optimised 6amMart:

:::checks
- The Excel round-trip is byte-identical to the 8.4 output, including Devanagari text and an em dash
- The CSV export is byte-exact
- Laravel boots
:::

Ubuntu 26.04's own archive PHP **is** 8.5.4, and the native runtime installs it. If you are still on a page or a scan report that calls 8.5 a blocker, that reading predates this round.

## Database — all five engines

Same data, same tables, same settings, one engine running at a time.

| Measurement | MariaDB 10.11 | MariaDB 11.8 | MariaDB 12.3 | MySQL 8.0 | MySQL 8.4 |
|---|---|---|---|---|---|
| Runs 6amMart as shipped | yes | yes | yes | no | no |
| Fourteen busy screens, total (ms) | 1006 | 1056 | 1035 | 1158 | 1192 |
| Requests per second, 6 at once | 56.1 | 53.4 | 52.1 | 45.2 | 45.6 |
| Database & disk score | 125 | 117 | 119 | 82 | 105 |

That round put five engines in five containers on one bench machine, which is how five engines get compared at all. It answers the MariaDB-versus-MySQL question well and the MariaDB-version question badly — see the correction below before quoting the middle three columns at each other.

MySQL's position is the durable finding. On the busiest measure — requests per second — MariaDB handles 23 to 24 percent more traffic than either MySQL on the same hardware, which is the difference between a server that copes with the dinner rush and one that needs to be a size bigger.

MySQL 8.0 is actually fastest on isolated report queries run one at a time — but real 6amMart screens are not like that. One home screen fires 126 separate small queries; a store list fires 25. When the work is many small queries instead of a few big ones, MySQL's per-query overhead dominates and it drops toward the back of the field. Both patterns are real, and the one your customers experience day to day is the second one.

### 10.11 vs 11.8 vs 12.3

**This is the correction.** The earlier reading of the table above — 11.8 five percent behind 10.11, 12.3 three percent behind, blamed on a MariaDB 11 query-planner change — is withdrawn as a whole-application claim. It was re-measured on identical bare servers with the same 66,701-order shop, on the stacks that actually ship, and **11.8 against 10.11 is a wash**.

What produced the appearance of a gap was the measurement itself, and the tell was a query that does no work at all. `SELECT 1` read **12 ms** on one arm against **29 ms and 37 ms** on the other two. A floor that moves three times over cannot be query execution.

The cause: **MariaDB 11.8 negotiates TLS on the unix socket and 10.11 does not.** Neither server was configured to — 11.8 generates a certificate and enables it on its own, and nothing on either box requires encrypted transport. The measurement harness opened a fresh connection per sample through the `mariadb` command-line client, so it was timing a TLS handshake and recording it as database speed. Measured directly, 30 runs of the same counting query: **24 ms per call on 11.8, 6 ms with TLS switched off, and 10 ms on 10.11 either way.**

**Every database row measured before that was found was discarded.** There is no corrected per-version total to publish, and this page will not invent one — what the round establishes is that the comparison was invalid, not that one version won by a smaller margin.

Your shop never pays that cost regardless. PHP's MySQL driver does not negotiate TLS over a unix socket, which is not an assumption here — the live connection reports `Ssl_cipher=NONE`, at 0.12 to 0.21 ms per connect. The admin panel did pay it, because it reaches the database by running the command-line client rather than through the driver, and that is fixed.

One number that used to appear alongside this, a report query "2.7 times slower on 11.x", belonged to MariaDB **11.0** and its cost model. It was never measured on 11.8, and 11.8 is the version Ubuntu 26.04 and Debian 13 ship.

The practical answer is short: take the MariaDB your release carries. 12.3 is not carried by any supported release, so choosing it means adding a repository and owning its updates yourself, for no measured gain.

### MySQL 8.0 and MySQL 8.4

Both MySQL versions are the only options here that do not run 6amMart as shipped. Two separate failures, identical on both versions: 6amMart's item search switches off a MariaDB-only query setting that MySQL rejects outright, so the search endpoint returns a server error on every request. And two of 6amMart's index migrations read the server's own catalogue in a way MariaDB and MySQL disagree on, so the update stops halfway and leaves the schema part-applied with no obvious sign of it.

Both are fixable in code, and neither is fixed today. MySQL 8.0 has reached end of life and receives no further security fixes at all — even setting the code issues aside, installing it today means installing something that will never be patched again. If MySQL is forced on you, use 8.4, not 8.0.

## Operating system — the three supported releases

The native runtime accepts exactly three releases, and takes every serving component from the release's own archive:

| | PHP | MariaDB | nginx | Redis | Security updates until |
|---|---|---|---|---|---|
| **Ubuntu 26.04 LTS** (recommended) | 8.5 | 11.8 | 1.28 | 8.0 | **Apr 2031** |
| Ubuntu 24.04 LTS | 8.3 | 10.11 | 1.24 | 7.0 | May 2029 |
| Debian 13 (trixie) | 8.4 | 11.8 | 1.26 | 8.0 | Aug 2028 |

**Speed is not what decides this.** Six axes were measured on identical servers with the same shop — the operating system, PHP, MariaDB, nginx, Redis and the kernel — and only one of the six decided anything at all: Redis, and on compatibility rather than on speed. No version swap produced a reportable difference. The measurement that puts that in proportion: two byte-identical servers, ordered together from the same provider, measured 11.6 percent apart on 20 rows out of 20. The noise between two identical machines is larger than any effect a version change produced, so a recommendation built on a few percent would be a recommendation built on nothing.

What is left to choose on is the support runway, which is why the order in that table is Apr 2031, May 2029, Aug 2028. For a server that takes payments, three extra years of patches is the whole argument.

Ubuntu 24.04 is the sensible fallback when a provider has no 26.04 image yet. Nothing about it is worse to run — it is the same application at the same speed on an older archive with a shorter runway.

:::warning Debian 12 (bookworm)
The native runtime **refuses Debian 12 by name** and stops before installing anything. SixPanel Docker still accepts it, and that is deliberate rather than an oversight — but accepting is not recommending. Debian 12's own security support ended on **11 July 2026**, and a container does not change that: the kernel, glibc, Docker itself and OpenSSH all come from the host's archive no matter what runs inside the containers. It installs, and you should not start a new shop on it.
:::

:::note What became of "you need a container to get MariaDB 10.11"
Ubuntu 26.04 and Debian 13 genuinely do not carry MariaDB 10.11 in their archives, and running the database in a container is genuinely how you get 10.11 on one of those releases — that part still holds.

What no longer follows is the conclusion. The native runtime does not need 10.11: it takes MariaDB 11.8 from the archive on both of those releases, and 11.8 against 10.11 measured a wash on this shop's own queries. So the database version is no longer a reason to keep the native runtime on Ubuntu 24.04, and no longer the reason SixPanel Docker exists. Pick the container runtime when you want the stack pinned to fixed images independently of the host, not because the native one would land on a slower engine.
:::

### Historical — Debian 12 against Ubuntu 24.04

These numbers are real and were measured the same way as everything else on this page, on the stack recommended at the time — PHP 8.4 and MariaDB 10.11. They are kept here as history rather than deleted, and they are no longer a recommendation, because one of the two releases is out of security support and the native runtime now refuses it.

| Measurement | Debian 12 | Ubuntu 24.04 | Winner |
|---|---|---|---|
| Raw processor work (ms) | 1122 | 1156 | Debian by 3% |
| Time the app spends in PHP (ms) | 643 | 598 | Ubuntu by 7% |
| Requests per second, 6 at once | 49.5 | 53.2 | Ubuntu by 8% |
| Time in the database (ms) | 506 | 527 | Debian by 4% |
| Database & disk score | 120 | 117 | Debian by 3% |

On speed the two cancelled out — Ubuntu won the PHP half, Debian won the database half, by similar margins either way. Read against the later finding that two identical servers differ by 11.6 percent, that is the same answer the three-release round gave: the operating system is not where the speed is.

## How this was measured

A real shop's database, not generated data — 410 MB, 133 tables.

The five-engine comparison ran on one bench machine, ten processors, under eight gigabytes of memory, with each engine in its own container. That is a statement about the test rig and not a recommendation about how to run production — see the notes above for when containers are the right answer in production and when they are not.

The later rounds — the three supported stacks, the PHP pairs, the MariaDB pair — ran on separate identical cloud servers instead, with the arms alternated within each pair rather than run in a fixed order. That change is what turned several small apparent wins into washes: a fixed order puts every warm-up on the same arm.

Tables were made identical across every engine first, and the resulting index sets were compared to confirm none were missing. Only one database ran at a time, so nothing measured a neighbour competing for resources.

Application caching was switched off deliberately, so every repetition did the full database work rather than reading a saved result. That is the worst case, and the only way an engine difference shows up at all.

## When to run this again

- When your orders table grows several times larger — a query planner's choices change with table size, so any single measurement is a snapshot of the plans this data happens to produce.
- After any 6amMart upgrade that changes the query code, since every number here belongs to the queries this version happens to run.
- Before you accept a version recommendation from anywhere, including this page. Every claim here that turned out to be wrong was wrong in the same way: it repeated a constraint someone declared instead of running the code.

SixPreflight runs the same benchmarks against your own server and your own data — see [Speed and sizing](https://www.allsweb.com/sixpreflight/docs/speed-and-sizing) to run them yourself.