MySQL 8.0 End of Life: Migrate Your Shop Database

With MySQL 8.0.46, the final version of the 8.0 series shipped in April 2026. Oracle states it plainly in the official release notes: with 8.0.46, MySQL 8.0 reaches End of Life, and users are encouraged to move to MySQL 8.4 LTS or a current Innovation release (Oracle MySQL 8.0 Release Notes). Since 2026-04-21 the version has been covered only by Oracle Sustaining Support (Oracle MySQL Product Support EOL Announcements) - which, for the freely available Community Edition, simply means: no more security patches. For shop operators this is not a sysadmin footnote. Underneath Shopware, WooCommerce or any other shop system sits exactly this database - holding every order, customer account, payment reference and invoice record. A database without security updates is therefore first a compliance and audit problem, and only after that a technical one. This article treats the move to 8.4 LTS as an operational task with a deadline: breaking changes, compatibility checks, MariaDB as an alternative path, and a migration sequence with dump-restore testing, query regression and a rollback window. Hosting models are covered in the article on managed hosting for online shops, caching layers in Redis caching for Shopware - here we deal exclusively with the relational database and its lifecycle.

What the end of support for MySQL 8.0 actually means

Since its release in April 2018, MySQL 8.0 was the default database of the PHP shop stack for roughly eight years. That era ends with 8.0.46, released on 2026-04-21 - according to Oracle the final version of the series (Oracle MySQL 8.0 Release Notes). After that, Sustaining Support applies: Oracle customers with a support contract keep access to already published patches and documentation, but no new security fixes and no bug fixes are produced. Anyone running the Community Edition - the clear majority in shop practice - gets nothing at all. An Extended Support option that could still be purchased for a while, as with MySQL 5.7, is not available for the Community Edition. The deadline is therefore hard, and it has already passed.

Why an EOL database is a compliance and audit problem

The most interesting part of the end of support is not technical but regulatory. PCI DSS requirement 6.3.3 requires critical and high-severity security patches to be installed within one month of release, and all other applicable patches within an appropriate self-defined time frame (PCI Security Standards Council, PCI DSS v4.0). With an EOL component this requirement is not merely hard to meet - it is structurally unmeetable, because the patch simply does not exist. Requirement 12.3.4 addresses exactly this case in addition: technologies in use must be reviewed at least annually to confirm they are still supported by the vendor, and components approaching end of life need a documented plan (PCI Security Standards Council, PCI DSS v4.0). Anyone accepting card payments answers these questions to their acquirer or payment service provider - depending on merchant level, either in the Self-Assessment Questionnaire or as part of an assessment.

Then there is the data protection angle. Article 32 GDPR requires technical and organisational measures reflecting the state of the art - a database that the vendor officially lists as End of Life and for which no security updates are published is hard to defend as such in the event of an incident. For manufacturers of digital products, the Cyber Resilience Act and its obligations add binding rules for vulnerability handling across the support period. How real the patch stream is that an 8.0 installation now misses becomes clear from the numbers: the Critical Patch Update of April 2026 alone contained 34 new security patches for Oracle MySQL, 3 of which were remotely exploitable without authentication; the most severe issue, CVE-2025-15467 with a CVSS score of 9.8, affected the MySQL Enterprise Backup component and could lead to remote code execution (Oracle Critical Patch Update April 2026 / Qualys).

The following questions typically appear in assessments, supplier reviews and cyber insurance questionnaires - and they cannot be answered cleanly with an EOL database:

• Which database version runs in production, and is it still supported by the vendor? The answer fits in one line - and decides the rest of the conversation.
• How do you ensure critical patches are applied within 30 days? Without available patches, no process can deliver this.
• When did you last check whether components in use are reaching end of life? PCI DSS 12.3.4 expects this review at least annually (PCI Security Standards Council).
• Is there a documented migration plan with a target date, and which compensating controls run until then? Network segmentation and restrictive grants reduce the risk - they do not remove the finding.

An end-of-life database is rarely the cause of an incident - but regularly the point at which the question of due diligence gets asked afterwards.

XICTRON development team

Breaking changes when moving from 8.0 to 8.4

The good news first: the upgrade path is direct. Oracle explicitly lists the step from an LTS or bugfix series to the next LTS series as supported, giving 8.0.37 to 8.4.x LTS as the example - via in-place upgrade, logical dump and load, or replication (Oracle MySQL 8.4 Reference Manual, Upgrade Paths). No intermediate step is required; the rule that a series cannot be skipped applies from 5.7 upwards. The bad news: 8.4 is not a pure maintenance update. Several Innovation releases sit between 8.0 and 8.4, and their cleanup work lands here all at once. The most common stumbling block is not application code but the configuration file: removed server variables raise an error at startup - the server simply refuses to start (Oracle MySQL 8.4 Reference Manual).

• Removed authentication plugins: authentication_fido and authentication_fido_client were removed in 8.4.0, replaced by authentication_webauthn (Oracle MySQL 8.4 Reference Manual).
• mysql_native_password is no longer the default: from 8.4.0 the plugin is no longer enabled by default and must be switched on with mysql_native_password=ON if required. In MySQL 9.0 it is removed entirely (Oracle MySQL 8.4 Reference Manual).
• default_authentication_plugin removed: replaced by authentication_policy - a line present in many older shop configurations (Oracle MySQL 8.4 Reference Manual).
• expire_logs_days removed: only binlog_expire_logs_seconds remains valid - this affects practically every configuration with binary logging enabled (Oracle MySQL 8.4 Reference Manual).
• Replication statements removed, not deprecated: CHANGE MASTER TO, START SLAVE, STOP SLAVE, SHOW SLAVE STATUS, RESET SLAVE, RESET MASTER and SHOW MASTER STATUS no longer exist - they produce syntax errors. Their replacements are CHANGE REPLICATION SOURCE TO, START REPLICA, STOP REPLICA, SHOW REPLICA STATUS, RESET REPLICA, RESET BINARY LOGS AND GTIDS and SHOW BINARY LOG STATUS. The MASTER_ options likewise give way to their SOURCE_ equivalents (Oracle MySQL 8.4 Reference Manual).
• Further removed replication variables: relay_log_info_repository, master_info_repository, log_bin_use_v1_events, transaction_write_set_extraction and slave_rows_search_algorithms - the latter is now fixed at HASH_SCAN,INDEX_SCAN (Oracle MySQL 8.4 Reference Manual).
• Removed keyring plugins: keyring_file and keyring_encrypted_file give way to the component_keyring_file and component_keyring_encrypted_file components - relevant with encrypted tablespaces (Oracle MySQL 8.4 Reference Manual).
• Removed server options: --ssl (now --tls-version), --skip-host-cache (now --host-cache-size=0) as well as --innodb and --skip-innodb, since InnoDB is always enabled (Oracle MySQL 8.4 Reference Manual).
• Non-standard foreign keys and grant wildcards: foreign keys on non-unique or partial keys are deprecated and require restrict_fk_on_non_standard_key=OFF; % and _ in database grants are to be treated as literals in future releases. Both affect grown schemas (Oracle MySQL 8.4 Reference Manual).

In practice the list condenses into two work packages. First, the configuration: scan my.cnf, Docker Compose command lines, Ansible roles and provisioning scripts for removed variables. Second, the scripts around the database: backup jobs, monitoring checks, replication setups and deployment automation typically contain exactly the statements that now raise syntax errors. The application code of Shopware and WooCommerce itself is rarely the problem - these systems speak ordinary SQL and are tested by their vendors against current MySQL versions. The critical parts are custom reports, grown reporting queries and bespoke extensions, which we typically review as part of development work.

# ---------- MySQL 8.0: commonly grown configuration ----------
[mysqld]
# expire_logs_days = 7 # REMOVED in 8.4 -> server will not start
# default_authentication_plugin = mysql_native_password # REMOVED in 8.4
# master_info_repository = TABLE # REMOVED in 8.4
# relay_log_info_repository = TABLE # REMOVED in 8.4
# transaction_write_set_extraction = XXHASH64 # REMOVED in 8.4
# log_bin_use_v1_events = OFF # REMOVED in 8.4
# skip-host-cache # REMOVED in 8.4

# ---------- MySQL 8.4: valid equivalents ----------
[mysqld]
binlog_expire_logs_seconds = 604800 # instead of expire_logs_days = 7
authentication_policy = caching_sha2_password # instead of default_authentication_plugin
host_cache_size = 0 # instead of skip-host-cache

# Only set if legacy clients strictly require it (gone entirely in 9.0):
# mysql_native_password = ON

# Shopware requirement: max_allowed_packet >= 32M (Shopware hosting guide)
max_allowed_packet = 64M

# Defaults that 8.4 changes - deliberately pinned to 8.0 behaviour here
# until measured on your own hardware:
innodb_io_capacity = 200 # 8.4 default would be 10000
innodb_adaptive_hash_index = ON # 8.4 default would be OFF

Changed defaults: what measurably shifts in operation

Beyond the removed variables, 8.4 shifts a whole set of InnoDB default values (Oracle MySQL 8.4 Reference Manual). This is the underrated part of the migration: the server starts, the application works, and the load behaviour is nevertheless different. Oracle aligned the new defaults with modern hardware - many cores, NVMe storage, generously sized RAM. That assumption does not always hold for typical shop hosting, particularly in virtualised environments with network storage or shared IOPS quotas.

The most striking value is innodb_io_capacity, jumping from 200 to 10000 (Oracle MySQL 8.4 Reference Manual) - a factor of 50. On local NVMe storage that is sensible. On a virtualised server with network storage or capped IOPS, the same setting can mean background flushing consumes exactly the IO capacity the shop needs for selling. innodb_adaptive_hash_index is similarly nuanced as it moves from ON to OFF: Oracle changed the default because the index can itself become a bottleneck under high concurrency - yet with very many repeated point lookups, switching it off may also increase latency. Neither value should be adopted blindly; both should be measured. How load peaks can be modelled cleanly is covered in the article on auto-scaling for traffic peaks.

Checking compatibility: Shopware and WooCommerce requirements

Before a target version is fixed, it has to be reconciled with the shop system's requirements. Shopware 6 names MySQL from 8.0.22 as the minimum and MySQL 8.4 as the recommendation in its hosting guide, alternatively MariaDB from 10.11.6 as the minimum with MariaDB 11.4 recommended (Shopware Developer Documentation, Hosting). The recommendation therefore matches the obvious migration target exactly. Also documented: max_allowed_packet of at least 32M as well as PHP from 8.2 with PHP 8.4 recommended. Particularly important for version planning is one sentence from the same source: Innovation releases are not supported (Shopware Developer Documentation, Hosting). Jumping to the newest available MySQL generation is explicitly not the goal.

WooCommerce phrases its requirements more broadly: MySQL 8.0 or greater respectively MariaDB 10.6 or greater are recommended, alongside PHP 8.3 or greater and WordPress 6.9 or greater (WooCommerce Server Requirements). Formally, WooCommerce still runs on MySQL from 5.6 or MariaDB from 10.4 - although the documentation itself notes that these versions have reached their official end of life and may expose the site to security vulnerabilities (WooCommerce Server Requirements). For WooCommerce projects this means: the requirements are more lenient, the security argument stays identical. Anyone wanting to run a WooCommerce environment properly follows the recommendation, not the minimum.

One point often lost in planning: database and PHP migrations are two separate projects that tend to get merged - and then fail together. If response times rise after the maintenance window, a combined migration makes it impossible to attribute the cause to the database defaults or the new PHP version. We therefore usually separate the two steps; how the PHP side plays out is described in the article on PHP 8.5 migration from an agency view. Anyone facing a larger technology change anyway will find the broader frame in the article on CMS migration from legacy to a modern system.

MariaDB as an alternative path

Since Shopware and WooCommerce support both databases, MariaDB is a legitimate target - though for different reasons than commonly assumed. The lifecycle looks like this: MariaDB 11.4 LTS is maintained until May 2029, MariaDB 11.8 LTS until June 2028 (MariaDB Foundation). The seemingly paradoxical finding - the older LTS runs longer than the newer one - is explained by a change to the maintenance policy: LTS versions are released yearly and now receive bug and security fixes for three instead of five years; the five-year rule applied up to 11.4 (MariaDB Foundation). For version selection this means: do not automatically take the highest number, compare the end date. That is precisely why Shopware currently recommends 11.4 and not 11.8 (Shopware Developer Documentation, Hosting).

The decisive half of the truth is the second one: MariaDB has long ceased to be a drop-in replacement for MySQL 8.0. An in-place switch is out; the path necessarily runs through dump and restore. The differences concern storage formats, not just syntax. JSON in MariaDB is an alias for LONGTEXT with a CHECK constraint, whereas MySQL 8.0 and 8.4 use a native binary format - when replicating from MySQL to MariaDB, JSON columns must therefore be converted to TEXT beforehand, or statement-based replication must be used (MariaDB Documentation, Incompatibilities and Feature Differences). The GTIDs are mutually incompatible as well, so hybrid setups during a migration require position-based replication; MariaDB additionally documents requirements such as binlog-row-value-options set to an empty value and binlog_transaction_compression set to 0 (MariaDB Documentation, Replication Compatibility Between MariaDB and MySQL).

Migration sequence: dump-restore test, query regression and rollback window

The sequence that has proven itself for shop databases separates learning on the clone from execution in production consistently. Everything that can be found out on a clone gets found out there - the maintenance window is for executing, not for learning. The following eight steps describe the approach we typically run in hosting and maintenance:

1. Take inventory: document the exact version (SELECT VERSION()), size per table, storage engines and collations. Also capture the effective configuration via SHOW GLOBAL VARIABLES - not just my.cnf, otherwise values set at runtime get lost.
2. Upgrade checker on the clone: run MySQL Shell's util.checkForServerUpgrade() against a copy. The report lists removed variables, obsolete data types and problematic objects - that is the work list for everything that follows.
3. Clean up the configuration: replace removed variables, migrate expire_logs_days to binlog_expire_logs_seconds, move default_authentication_plugin to authentication_policy. Pin the diverging 8.4 defaults to their 8.0 values for the time being.
4. Adjust surrounding scripts: a grep for SHOW SLAVE STATUS, CHANGE MASTER TO and RESET MASTER across all repositories and cron directories typically finds more than those involved expect.
5. Dump-restore test on the clone: take a full dump, load it into a fresh 8.4 instance, run mysqlcheck --check-upgrade - and measure the duration. That number is the basis for the length of the maintenance window.
6. Run a query regression: compare top queries from the slow query log and Performance Schema against 8.0 and 8.4 - EXPLAIN plans, runtimes, rows read. In focus: category listing, filters, cart and checkout. How search load is offloaded is covered in the article on search relevance and OpenSearch tuning.
7. Functional acceptance: walk through the ordering path, payment methods, invoice generation and returns on the clone. Price presentation and discount logic too - legal requirements for strikethrough prices and discount advertising rest on the same records.
8. Execute the maintenance window: shop into maintenance mode, final dump as the rollback anchor, note the binlog position, perform the upgrade, smoke tests, release. Then 48 to 72 hours of heightened attention on the slow query log and response times.

Planning the rollback and maintenance window realistically

This is where database migrations differ fundamentally from PHP migrations: the way back is not symmetric. A PHP version can be rolled back within seconds via an image tag or a second FPM pool, because PHP is stateless. A database is not. An in-place downgrade from 8.4 back to 8.0 is not a supported path - once the data directories are upgraded, the way back runs through the dump taken beforehand. And that dump is outdated from the moment of release: every order, every registration, every payment callback arriving after the dump does not exist in it.

Two consequences follow. First, the maintenance window needs a genuine write stop - the shop belongs in maintenance mode for the duration of dump and upgrade, otherwise the rollback anchor is incomplete. Second, anyone who has to keep the window short notes the binlog position of the dump - --source-data=2 writes it in as a comment - and can replay transactions accumulated afterwards with mysqlbinlog in a rollback scenario. Without that step, a rollback means losing every order since the dump - damage that regularly exceeds the original reason for the migration.

Running the database version as an operational task with a date

The end of support for MySQL 8.0 is not a special case but the normal state of every software component - only with a date that has now passed. Anyone moving to 8.4 LTS now has Premier Support until April 2029 and Extended Support until April 2032 (Oracle Lifetime Support Policy for Technology Products), a planning horizon of several years. The next LTS generation is already available as MySQL 9.7, released on 2026-04-21 with Premier Support until April 2034 - yet it is not a target for shop operators today as long as the shop system in use does not explicitly clear it. Shopware, for instance, excludes Innovation releases explicitly and recommends 8.4 (Shopware Developer Documentation, Hosting). The rule is therefore not as new as possible but as current as the vendor has cleared.

So the same situation does not catch anyone off guard again in three years, the lifecycle belongs in the maintenance contract rather than in individual heads. Concretely: version and EOL date of every core component - database, PHP, search service, cache, operating system - live in the asset inventory, and once a year somebody checks the list against vendor announcements. That review is due anyway, since PCI DSS 12.3.4 requires it at least annually (PCI Security Standards Council) - and it costs hours, whereas a migration under time pressure costs weeks.

XICTRON checks the database version in existing shops, tests the migration on a clone of the production data and performs it in an agreed maintenance window - including configuration cleanup, query regression and a defined rollback path. Whether 8.4 LTS or MariaDB is the right target is something we clarify upfront based on your shop system and hosting environment, rather than giving a standard answer. Get in touch via our contact page or have the inventory taken as part of a consulting engagement - the first step remains the same line: which version is actually running in production?

Frequently asked questions about the MySQL 8.0 end of support