Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock

A benchmark published on dev.to, originally posted on makewpfast.com, ran the same WordPress workload across six MariaDB releases: 10.6.28, 10.11.18, 11.4.12, 11.8.8, 12.3.2 and 13.0.1-RC ^[3]. That is five sequential hops ^[27], and according to the author the reason to take any of them is not speed but that 10.6 hit end of life on July 6, 2026 ^[4].

The rig is worth reading before the numbers. WordPress 7.1, PHP 8.4.24 and WooCommerce 11.0.1 were held constant ^[5], with stock server config and no buffer pool tuning, on the stated grounds that the question was what upgrading gives you rather than what tuning gives you ^[6]. The dataset was 1,000 posts, 200 WooCommerce products, 5,000 comments, 101 users and 7,798 postmeta rows ^[7], built once on 10.6, dumped, and imported into every version instead of reseeded per environment ^[8]. One server ran at a time to stop two instances fighting for CPU ^[9], and the whole suite ran twice with the second pass in reverse version order, so anything that did not appear in both passes was treated as noise ^[10].

Most of it was noise. Half the per-query percentage changes went the wrong way ^[1], and the largest single move, a 31.8 percent drop on WooCommerce product listing, was 0.12ms in absolute terms ^[2], which puts the baseline under 0.4ms ^[12].

The one result the author calls real is homepage throughput: 10.6 served roughly 7 to 13 percent fewer requests per second than 10.11 depending on concurrency, and came last at every concurrency level in both passes ^[11]. Because that deficit is measured against 10.11, the entire gain is banked at the first hop ^[28]. The finding reproduces the same author's March measurement on a rebuilt rig with different data and a different WordPress ^[13].

Two optimizer changes do almost all of the work, per the write-up: semi-join handling for UPDATE and DELETE, so a subquery in a DML statement is planned rather than re-run per row, and sargable date functions, so WHERE YEAR(post_date) = 2025 can use an index instead of scanning ^[14]. The widely circulated "40x faster UPDATE" demo uses a subquery matching zero rows, so it measures planning ^[15]; on this rig it came out at 70x ^[16]. The author then ran the same statement shape against subqueries that do match rows, 15 times each inside a transaction rolled back so every run starts from the same state ^[17]. Two variants were flat: where the updated table has a usable index, every version picks the same plan and runs at the same speed ^[18].

The fourth variant went backwards. 11.4 ran it about twice as slow as 10.11 and stayed twice as slow through 11.8, 12.3 and 13.0, reproduced on two separate rebuilds ^[19]. EXPLAIN shows 10.11 walking wp_postmeta in PRIMARY order, 7,761 rows, with a dependent unique_subquery into wp_posts ^[20], while 11.4 and later flip the driving table, find the 200 products via type_status_date, then perform ref lookups into postmeta at six rows each ^[21]. Fewer rows examined, more random access, and on this data the sequential scan wins ^[22]. In wall clock the author puts it at 4ms against 9ms ^[23].

He also states the limit: 7,798 postmeta rows sit entirely in the buffer pool, and on a table big enough that the scan hits disk the newer plan probably wins, which he has not tested ^[24].

So watch the untested half. Whether the 11.4 plan flip is a regression or a fix depends on postmeta tables large enough to fall out of memory, and nobody in this material has measured that ^[24]. Watch 13.0 too: the author's host already defaults to 12.3.2 with 13.0 sitting there as a release candidate ^[25], and the benchmark separates 10.6 from everything else and nothing else from anything ^[26].