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 ^[1]. That is five sequential hops ^[2], 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 ^[3].

The rig is worth reading before the numbers. WordPress 7.1, PHP 8.4.24 and WooCommerce 11.0.1 were held constant ^[4], 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 ^[5]. The dataset was 1,000 posts, 200 WooCommerce products, 5,000 comments, 101 users and 7,798 postmeta rows ^[6], built once on 10.6, dumped, and imported into every version instead of reseeded per environment ^[7]. One server ran at a time to stop two instances fighting for CPU ^[8], 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 ^[9].

Most of it was noise. Half the per-query percentage changes went the wrong way ^[10], and the largest single move, a 31.8 percent drop on WooCommerce product listing, was 0.12ms in absolute terms ^[11], 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 ^[13]. Because that deficit is measured against 10.11, the entire gain is banked at the first hop ^[14]. The finding reproduces the same author's March measurement on a rebuilt rig with different data and a different WordPress ^[15].

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 ^[16]. The widely circulated "40x faster UPDATE" demo uses a subquery matching zero rows, so it measures planning ^[17]; on this rig it came out at 70x ^[18]. 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 ^[19]. Two variants were flat: where the updated table has a usable index, every version picks the same plan and runs at the same speed ^[20].

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 ^[21]. EXPLAIN shows 10.11 walking wp_postmeta in PRIMARY order, 7,761 rows, with a dependent unique_subquery into wp_posts ^[22], 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 ^[23]. Fewer rows examined, more random access, and on this data the sequential scan wins ^[24]. In wall clock the author puts it at 4ms against 9ms ^[25].

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 ^[26].

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 ^[26]. Watch 13.0 too: the author's host already defaults to 12.3.2 with 13.0 sitting there as a release candidate ^[27], and the benchmark separates 10.6 from everything else and nothing else from anything ^[28].