Which database engine
Unlike the operating system choice, this one has a hard answer — but it is about which engine, not which version. 6amMart is a MariaDB application in practice, and on MySQL it is a tree that does not work correctly.
The short answer
MariaDB. Not MySQL. Which MariaDB matters much less than it used to: 10.11 and 11.8 measured a wash on this application, so take whatever the runtime gives you. A native SixPanel install takes it from the release's own archive — 11.8 on Ubuntu 26.04 and Debian 13, 10.11 on Ubuntu 24.04. SixPanel Docker runs mariadb:10.11 as a container image on any host it supports.
Why not MySQL
This is the part people are surprised by, because MySQL and MariaDB are usually described as interchangeable. For this codebase they are not, and it is not a matter of preference — two concrete things break:
A query-optimiser setting the code depends on. Some of 6amMart's heavier listing queries rely on a MariaDB session flag to keep a subquery from being re-evaluated per row. Without it, searches that return in a fraction of a second take seconds instead.
Case handling in the system catalogue. Parts of the tree read table and column metadata from the database's own catalogue, and MySQL returns it with different casing. Code that matches on those names stops matching.
So MySQL is not "slightly slower here". It is a tree that does not work correctly. If your host only offers MySQL, that is worth knowing before you buy the hosting rather than after.
The version pin, and why it is gone
This page used to say 10.11, and not the newest MariaDB, on the strength of one figure: an admin report measured roughly 2.7× slower on 11.x. That claim is withdrawn as a claim about 11.8, and it is worth saying exactly why rather than quietly dropping it.
The 2.7× came from one report query on MariaDB 11.0's cost model. It was real on 11.0 and it does not describe 11.8. When 11.8 and 10.11 were put on identical servers with the same shop's data — 66,701 real orders — the whole-application result was a wash.
The appearance of a gap came from the measurement, and the tell was a statement 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 moving three times over, which cannot be query execution.
The cause: 11.8 negotiates encryption on the unix socket and 10.11 does not. Neither server was configured to; 11.8 generates a certificate and enables it by itself, and nothing on either box requires encrypted transport. The probe opened a fresh connection per sample through the command-line client, so it was timing a 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 encryption off, 10 ms on 10.11 either way.
Every database row measured before that was found was discarded, so there is no corrected per-version total to quote — the honest result is that the comparison was invalid, not that the margin was smaller than it looked. Re-measured properly, the versions come out level.
Your shop never pays that cost anyway, because the PHP driver does not negotiate encryption over a socket — measured at 0.12 to 0.21 ms per connect, with Ssl_cipher=NONE. The admin panel did pay it, because it reaches the database by running the command-line client, and that is fixed.
The general point survives the number
Newer is not automatically faster for a fixed application. A planner change that helps most workloads can hurt one particular set of queries, which is exactly what 11.0 did to one report — and the only way to know is to measure your own. What changed is that we measured again on 11.8 and the effect was not there.
Where the database comes from
From the operating system's own archive, on all three supported releases. A native SixPanel install takes MariaDB from the distribution — 11.8 on Ubuntu 26.04 and Debian 13, 10.11 on Ubuntu 24.04 — so security fixes arrive through the distribution and no third-party repository sits in the serving path.
That also settles a question this page used to spend a section on. MariaDB's own installer script refuses to put 10.11 on Ubuntu 26.04 or Debian 13, and a native install used to depend on that script, which is why it recommended Ubuntu 24.04. It no longer uses the script at all, so the refusal never reaches it and every supported release is available to both runtimes. Which operating system covers what is left to choose on.
SixPanel Docker is still a product, and its reason to exist is now a narrower one: it is the container runtime, for people who want the whole stack isolated in containers, and for MariaDB 10.11 specifically on a release whose archive does not carry 10.11. Its database is a container image rather than an archive package — mariadb:10.11, with PHP 8.4 alongside it — so the host's own package list is irrelevant to it and always was. That is what lets it offer 10.11 anywhere. If you have no reason to want either of those, the native runtime is the one being developed.
What "tested against" actually means
10.11 is the version the optimised codebase was measured on, the version its query plans were checked against, and the version its automated tests ran on. Every performance figure on the measured results page was taken on it.
That used to be the argument for pinning it. What the identical-server round added is the other half: 11.8 was put through the same shop and the same queries and did not behave differently, so knowing what the queries do on 10.11 no longer means having to stay there.
Memory matters more than version
On a 4 GB server with a real shop's data — a 410 MB dump, 515 MB once loaded, roughly 66,700 orders — a 1 GB buffer pool held effectively the entire working set: 99.99 % of reads were answered from memory rather than disk.
That single fact does more for a shop's speed than any version choice on this page. A database that never waits on storage during normal operation is the goal, and the way to reach it is to give it enough memory to hold the data it uses.
There is a limit to that argument, and the three-panel comparison walked straight into it. On the aaPanel box the buffer pool was raised from 256 MB to 1152 MB — four and a half times larger — and the database battery did not move at all. The internals genuinely improved: cache hit rate 99.856 % to 99.930 %, temporary tables spilling to disk 47.3 % down to 22.1 %. The response times did not follow, because those reports are processor-bound work over rows that were already in memory.
So the honest shape of it is a threshold, not a dial. Memory buys you everything up to the point where the working set fits, and close to nothing after that.
The other limit is worth stating plainly: those numbers come from a 4 GB / 2-core box. We have not measured larger servers, so nothing here predicts what 8 GB would do.
PHP, while we are here
8.3, 8.4 or 8.5 — whichever your release supplies. All three run this application.
8.5 used to be ruled out on this page, and the reason was specific: the spreadsheet library behind Bulk Import, Bulk Export and every Excel report declares that it needs PHP below 8.5, and a failure there is the worst kind — the APIs and the storefront keep looking healthy while nobody can download a report.
So it was tested rather than trusted. That < 8.5.0 bound is a declaration in the library's metadata, not a measurement, and nothing enforces it at runtime because the platform check is switched off. On PHP 8.5.4 the xlsx round-trip came back byte-identical and the framework boots — verified on both the plain CodeCanyon tree and the optimised fork. Ubuntu 26.04's archive PHP is 8.5.4, and a native SixPanel install on that release installs it.
Between 8.3 and 8.4 there is nothing to choose on speed either, and that was measured rather than assumed. The aaPanel box in the three-panel comparison had both installed, so it could answer cleanly: the 8.3 pool was first given the entire 8.4 tuning, and every setting was verified from the running process. Geometric mean 8.3 against 8.4: 0.9994, with 8.3 ahead on 3 rows of 7 and every difference smaller than at least one arm's own spread.
What is left is where PHP comes from, and the answer is the same as the database: the release's own archive. A native SixPanel install takes 8.5 on Ubuntu 26.04, 8.4 on Debian 13 and 8.3 on Ubuntu 24.04, so security updates arrive through the distribution. SixPanel Docker carries PHP 8.4 in its container image on every host. If your PHP instead comes from a third-party repository — which is how most panels and most hand-built servers get a version newer than the distribution's — do not stay on 8.3: upstream bug-fix support for it ended in December 2025, and outside a distribution that backports its own fixes, that matters.
How to check what you have
SixPreflight reads the database's version, its buffer-pool size, its character set and the settings above, and tells you which are wrong for this application. It is free and it only reads. Running it before you commit to a host is cheaper than migrating afterwards.
Related
Which operating system · SixPanel vs SixPanel Docker vs aaPanel · SixPanel vs a plain server · SixPanel vs aaPanel