Drupal 11.4 cut database queries in half and almost nobody wrote about it

I wrote about Drupal 12's removal list because it's the kind of thing you need to plan around. But going back to check what Drupal 11.4 actually shipped on 1 July 2026 — five months before that — turned up numbers I hadn't seen discussed nearly as much, and they're the more immediately useful story for anyone running Drupal in production today.

The actual numbers

Per Drupal's own 11.4.0 announcement: the same requests now use roughly a third of the database and cache lookups that 11.0 or 10.6 needed, and on a cold cache, just over a third of those lookups. Against 11.3 specifically — the version most people reading this are probably still running — database queries are cut roughly in half across a wide range of request types. That's not a marginal optimization pass; that's architecture-level work in the render, caching, or entity-loading layers actually paying off at the query-count level, which is the number that tends to matter most once a site is under real load.

The smaller changes that add up

• Brotli compression for aggregated CSS/JS, alongside the existing gzip support — 15-25% better compression ratios per Drupal's own figures, gated behind the ext-brotli PHP extension being available.
• Translation-update checks 87% faster than 11.3, measured on a test site with 66 projects across 38 languages — a number that only matters if you're running a multilingual site with a lot of contrib, but a dramatic one if you are.
• Recipe-based installs roughly 2x faster, both for full site installs and for applying individual recipes — relevant if you're using recipes for anything beyond a one-time setup.
• A new experimental CLI at ./vendor/bin/dr, built with involvement from Drush's own maintainers, explicitly intended to gradually replace Drush over a transition period. I haven't moved any workflow off Drush onto it yet — it's explicitly experimental — but the fact that it's built by the people who maintain Drush, not a competing effort, makes me treat the eventual migration as a "when" rather than an "if."
• Configurable password hashing, with a new argon2id option that's stronger than the existing bcrypt default. Drupal 12 will default to argon2id, and existing passwords rehash automatically at next login once the setting changes — no forced reset, no stored-hash migration script needed.

Why I think this got less attention than the removal list

A removal list is something you have to read, because it tells you what will break. A 50% reduction in query count is something you'd only go looking for if you were already profiling your own site, and most of us aren't doing that unless something's visibly slow. That's a reasonable way for attention to get allocated, but it means a release with real performance engineering behind it reads, from the outside, like a quieter release than Drupal 12's beta — when the actual architecture work here is arguably the bigger deal for anyone running Drupal 11 today rather than planning a 12 upgrade.

What I'm checking next

I haven't benchmarked this blog's own stack against these claims yet — it's a small site, and the gains Drupal describes are clearest under real load with a warm-but-not-fully-cached cache, which a low-traffic blog doesn't reliably exercise. But Drupal 12 shipping alongside 11.5 LTS the week of 7 December 2026 means 11.4's architecture is what everyone upgrading from 11.3 is about to inherit regardless, so it's worth understanding now rather than discovering it as an unexplained speedup after the next upgrade.