Adobe Commerce has established MariaDB as its default and recommended database direction. This practical guide explains what the transition means, which Commerce versions are affected and how merchants can migrate without turning a planned infrastructure change into a production incident.
Adobe Commerce is entering a new database chapter. For many years, merchants and implementation partners treated MySQL and MariaDB as two closely related options within the Magento ecosystem. That position has now changed. MariaDB is no longer simply an alternative that happens to appear in the compatibility matrix. It is becoming the database platform around which future Adobe Commerce releases are being planned.
The change was not accompanied by a large product keynote or a major marketing campaign. Adobe communicated the direction through its support guidance and system requirements documentation. That quiet delivery can make the change appear less urgent than it is. In practice, database support affects application upgrades, security planning, hosting architecture, extension compatibility, performance testing and the ability to receive effective vendor support.
Merchants do not need to panic or immediately replace a stable production database. They do need to understand their current position. A business running Adobe Commerce 2.4.6 with MySQL 8.0 has a different level of urgency from a business already operating 2.4.8 with MariaDB 11.4. Migration decisions should therefore begin with accurate discovery, not assumptions.
Know your Adobe Commerce version, confirm the real database engine running underneath it and place MariaDB migration on the roadmap before support limitations force the decision during an incident.
Adobe's support guidance establishes a clear end point for MySQL within the Adobe Commerce product line.
Adobe Commerce 2.4.8 and 2.4.9 are identified as the final Commerce versions that support MySQL. Within those versions, MySQL 8.4 is the final MySQL release Adobe plans to certify. Versions released after MySQL 8.4 are not expected to receive Adobe Commerce certification or support.
For earlier Commerce versions, MySQL 8.0 reached the relevant Adobe support milestone on April 30, 2026. Adobe does not intend to validate a newer MySQL major version for the 2.4.5, 2.4.6 and 2.4.7 release lines. On-premises merchants using those versions are therefore advised to move to a MariaDB version compatible with their exact Commerce release and patch.
This does not mean every store on an older Commerce release became completely unsupported on the same day. Adobe Commerce application lifecycle support and third-party database dependency support are related but separate. A Commerce release may remain within an Adobe support period while its MySQL dependency no longer meets the required supported configuration.
The correct action depends on the exact Commerce release, patch level, deployment model and current database version.
| Commerce environment | Current position | Recommended planning response |
|---|---|---|
| 2.4.5–2.4.7 with MySQL 8.0 | Adobe will not certify a newer MySQL major version for these Commerce release lines. MySQL 8.0 is no longer the long-term supported dependency path. | Identify the MariaDB release supported by the exact Commerce patch, test the application and schedule a controlled migration. |
| 2.4.8 with MySQL 8.4 | The configuration can remain supported, but MySQL 8.4 is the final MySQL destination in the Adobe Commerce roadmap. | Use the available runway to complete discovery, extension testing and MariaDB migration planning before the next major Commerce upgrade. |
| 2.4.8 with MariaDB | The store is already operating in the database direction Adobe is carrying forward. | Confirm the database release against the latest patch matrix, maintain backups and include database upgrades in normal platform lifecycle planning. |
| 2.4.9 on premises | MySQL 8.4 may still appear as a supported option, but MariaDB is the recommended long-term platform. | Prefer MariaDB for new infrastructure and avoid building a new long-term platform around the final MySQL release. |
| 2.4.9 on Cloud | Current Cloud requirements have already moved towards MariaDB without presenting MySQL as the database destination. | Coordinate the required database service version with Adobe Cloud Support and follow the Cloud upgrade procedure. |
Adobe's requirements continue to change as new Commerce patches and database releases become available. At the time of writing, the requirements for Adobe Commerce 2.4.9 recommend a newer MariaDB release than the versions commonly used by 2.4.7 or 2.4.8 environments. This is why a team should never choose a destination database version from a generic MariaDB download page alone.
The authoritative destination is the MariaDB version listed for the exact Commerce version and patch being deployed. Teams should check the matrix during initial planning and check it again immediately before staging and production implementation.
Adobe has documented the technical direction but has not published a detailed commercial explanation covering every reason behind it.
It is reasonable for the community to discuss Oracle ownership, licensing models, enterprise support terms and the independent governance of MariaDB. However, these points should not be presented as Adobe's confirmed motivation unless Adobe explicitly states them.
The observable technical direction is enough to guide planning. Adobe's compatibility tables are moving through newer MariaDB releases, while MySQL certification stops at version 8.4. MariaDB is therefore receiving the forward-looking compatibility attention required by new Commerce releases.
MariaDB also has a practical advantage for this transition: it shares its origins with MySQL. The two products retain important similarities in SQL syntax, network protocol, administration concepts and ecosystem tooling. This makes the transition more manageable than rewriting Adobe Commerce for a completely unrelated database platform.
That shared history should not be confused with complete interchangeability. MySQL and MariaDB have developed independently for years. Their optimisers, authentication methods, JSON implementations, replication features, release strategies and operational behaviour can differ. The migration is within a familiar database family, but it still requires engineering discipline.
MariaDB should now be treated as part of the Adobe Commerce upgrade strategy—not as an optional database experiment to consider after the application upgrade has already been designed.
Mage-OS 3, a community-driven distribution built on the Magento Open Source 2.4.9 foundation, also recommends MariaDB in its published software stack. The installer can recognise both MySQL and MariaDB, but the recommended database listed for the release is MariaDB.
This alignment matters because it shows that the commercial and community-led sides of the Magento ecosystem are not moving towards competing database futures. Both are investing in MariaDB compatibility as part of their modern platform stacks.
A successful import does not prove that an Adobe Commerce installation is fully compatible, stable or production-ready on MariaDB.
Many migrations will use familiar logical backup and restore procedures. The schema may import successfully, the storefront may load and basic admin operations may work. Problems can still emerge later under catalog imports, checkout traffic, scheduled jobs, reporting queries or high-volume order processing.
Third-party extensions are one of the most important review areas. Well-designed modules use Adobe Commerce's database abstraction and resource model. Other modules execute direct SQL, introduce custom tables or assume behaviour specific to a MySQL release. These assumptions may not be visible during a simple code review and can require targeted functional and performance testing.
- SQL modes, strict-mode handling and implicit value conversion
- Character sets, collations, sorting and case-sensitivity behaviour
- JSON storage, functions, comparisons and generated data
- Database users, authentication plugins and permission models
- Index selection, query plans and optimiser decisions
- Temporary tables, memory usage and large import operations
- Replication, failover and high-availability architecture
- Backup, restore, monitoring and database administration tools
- Custom reports and integrations that query Commerce tables directly
- Managed hosting services with restricted database configuration
Teams should also investigate the actual database engine behind the
service name. In some Adobe Commerce Cloud configurations, the service
may still be called mysql in configuration files even
though the underlying database technology is MariaDB. Discovery should
be based on the running database version and server variables, not only
on a service label.
The safest migration separates discovery, compatibility work, rehearsal, production cutover and post-launch monitoring.
Record the Adobe Commerce edition, application version, security patch, PHP version, database engine, database release, hosting model and high-availability setup. Include OpenSearch, message queues, cache services and other dependencies because the database migration may be combined with a broader Commerce upgrade.
Match the target MariaDB version to the exact Adobe Commerce release and patch. Do not automatically choose the latest MariaDB release available from the operating system repository. The newest database version and the correct Commerce-compatible version are not always the same.
Review modules, integrations, reports, import tools and custom scripts for direct SQL. Identify stored routines, custom tables, unsupported triggers, custom indexes and external applications that connect to the Commerce database. Ask extension vendors for written confirmation of support where appropriate.
Restore a recent sanitised copy of production into an environment running the proposed MariaDB version. Match production PHP, OpenSearch, Valkey or Redis, RabbitMQ, Varnish and web-server versions as closely as possible. A small developer database cannot reveal behaviour caused by a large catalog or order history.
Test storefront, admin, API and background-processing workflows. Include customer login, cart operations, checkout, payment authorisation, order creation, invoicing, shipment, refunds, catalog imports, promotions, indexing, cron jobs, queue consumers, ERP synchronisation and marketplace feeds.
Capture baseline response times and slow-query data before the migration. Compare execution plans for expensive queries on the target database. Test with realistic concurrency and data volume. A query can be valid on both platforms while using a very different index or execution strategy.
Create a complete migration runbook and execute it in staging. Measure the backup, transfer, import, validation and reindexing duration. Define clear rollback conditions and confirm that the previous production environment can be restored within the agreed recovery window.
Use an approved maintenance window. Stop processes that can write to the database, take the final consistent backup, complete the migration and run a predefined validation checklist. Reopen the store only after checkout, order placement, admin access, integrations, indexers and background consumers have been confirmed.
Review database errors, slow queries, CPU, memory, disk activity, locks, replication health, cron failures, queue backlogs, checkout errors and integration failures. Keep the rollback path available for the agreed stability period and document any post-migration tuning changes.
Testing should represent the complete Commerce operating model, not only a few visible storefront pages.
- Customer registration and authentication
- Product, category and search navigation
- Configurable and bundled product selection
- Cart, coupons and promotional rules
- Shipping and tax calculations
- Guest and registered-customer checkout
- Payment authorisation and capture
- Product and category management
- Customer and company account management
- Order, invoice and shipment creation
- Credit memos and refunds
- Admin grids, filters and exports
- Catalog and price imports
- Reports and scheduled operations
- Cron execution and queue consumers
- Full and partial indexer runs
- REST and GraphQL integrations
- ERP, CRM and warehouse synchronisation
- Marketplace and feed generation
- Replication and failover behaviour
- Backup and monitoring alerts
Functional success does not automatically mean the migration is ready for production. A query that returns the correct result in 300 milliseconds on MySQL but requires several seconds on MariaDB can become a serious issue during peak traffic. Establish acceptable thresholds for storefront response time, checkout processing, catalog imports, indexer duration and important integration jobs.
Compare slow-query logs and examine queries whose behaviour changes significantly. Some issues may be resolved through an index adjustment, configuration tuning or an extension update. Others may expose direct SQL that should be rewritten to use supported Adobe Commerce data access patterns.
A backup file is not a rollback plan until the team has restored it and confirmed that the application can operate from it. Database size, compression, network transfer, storage throughput and index rebuilding can make the recovery period much longer than expected.
The rehearsal should answer practical questions: How long will the final export take? Can the data be transferred within the maintenance window? How long will import and validation require? Which team member makes the rollback decision? At what point does rollback become safer than continuing to troubleshoot the new environment?
Database discovery should become a standard part of every Adobe Commerce support review, upgrade proposal and infrastructure scope.
- Which Adobe Commerce version and security patch are we running?
- Is the database Oracle MySQL, MariaDB or a managed compatible service?
- What exact database version is running in production?
- Does that version appear in Adobe's current support matrix?
- Are staging and production using the same database engine?
- Which extensions execute direct SQL or create custom tables?
- When was the last full database restore test completed?
- Is MariaDB migration included in the next Commerce upgrade budget?
Agencies should avoid presenting the work as a basic hosting task. Scope should cover environment discovery, supported-version selection, extension compatibility, data migration, regression testing, performance testing, production rehearsal, rollback planning and post-launch monitoring.
When the migration is connected to a Commerce upgrade, the scope should also recognise the interaction with PHP, OpenSearch, message queues, cache services and other platform dependencies. Changing several major services in one release can be efficient, but it also increases the number of variables that must be isolated during testing.
Managed environments may limit direct access to database configuration or require a support request to change the service version. Adobe Commerce on Cloud projects should follow Adobe's documented service upgrade process and allow sufficient time for infrastructure scheduling.
Self-hosted environments have more implementation control but also place more responsibility on the merchant and technical team. Operating-system repositories, security maintenance periods, replication tooling, backup storage and database monitoring all need to support the selected MariaDB version.
Compatibility is strong, but optimiser behaviour, authentication, JSON handling and operational features can differ between modern releases.
The target must match Adobe's tested matrix for the exact Commerce release and patch, not simply the newest available server package.
Database compatibility problems often appear in imports, reports, cron jobs, queue consumers, checkout or third-party integrations.
Small test databases do not expose the same query plans, table growth, locking behaviour or import duration as production data.
Recovery timing and data integrity can only be trusted after the backup has been restored and the application has been validated.
A production outage is the worst time to discover that the current database no longer aligns with Adobe's supported configuration.
Adobe Commerce's MariaDB direction is clear enough for merchants to act, even when an immediate production migration is not required.
Stores operating MySQL 8.0 on affected Commerce versions should treat database alignment as a current support and operational concern. Stores on Commerce 2.4.8 or 2.4.9 with MySQL 8.4 have more time, but that time should be used to prepare—not to assume another supported MySQL destination will appear later.
A well-managed migration does not need to be disruptive. The platform can be assessed, extensions can be reviewed, production data can be rehearsed in staging and performance can be compared before a final decision is made. The important step is to bring database planning into the normal Commerce lifecycle rather than separating it from application upgrades.
The practical path is straightforward: confirm the current version, verify the database engine, select the supported MariaDB destination, test the complete platform, prove the rollback plan and schedule a controlled cutover. Completing those steps early gives the business options. Delaying them until support or infrastructure pressure removes those options.
MariaDB is becoming the platform Adobe Commerce is actively carrying forward. Merchants who understand their current position and begin planning now can make the transition as an organised platform improvement rather than an emergency response.
Hikmadh can assess your Commerce environment, identify database and extension compatibility risks, prepare a migration runbook and validate the platform before production cutover.