Which PHP, database and OS version

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.

• 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

PHP — 8.3 vs 8.4 vs 8.5

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.

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:

• 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.

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:

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.

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.

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 to run them yourself.