If you’re running MariaDB Community Server 10.6, mark your calendar: July 6, 2026 is the official End of Life (EOL) date. After that date, there will no longer be security patches, bug fixes, or updates for this version.

That’s not a distant concern – it’s a few weeks away. And if you haven’t started planning your next move, now is the time.

This post walks you through what EOL actually means, why it matters, and the three most practical paths forward depending on your situation.

What Does “End of Life” Actually Mean?

When a software version reaches End of Life, the organization maintaining it stops providing updates. For MariaDB Community Server 10.6, that means no more security patches and no more bug fixes after July 6, 2026.

Your database won’t suddenly stop working on July 7th. But over time, the risks compound. New vulnerabilities may be discovered and won’t be fixed. 

The bottom line: running an EOL database in production is a risk most teams shouldn’t take on.

Your Three Paths Forward

There’s no single right answer here – the best path depends on how much operational overhead you want to manage, how critical your database is, and whether staying on version 10.6 matters for your workload or organization’s priorities. Let’s look at each option honestly.

Path 1: Stay on 10.6 – But Switch to MariaDB Enterprise Server

Best for: Teams that need the stability of 10.6, have regulatory constraints, or simply can’t afford the risk of a major version upgrade right now.

What This Is

MariaDB Enterprise Server 10.6 is built upon the same core 10.6 codebase your team already knows, but is hardened for mission-critical environments. It is a premium version of Community Server that includes enterprise-grade add-ons, such as advanced auditing and enhanced security plugins, designed to meet regulatory requirements. Unlike the community server version, MariaDB Enterprise Server has a published STIG (Security Technical Implementation Guide), making it the clear choice for government agencies and organizations operating under DoD or federal compliance mandates. By switching, you maintain the same application behavior while extending your support lifecycle to August 23, 2029 – three additional years of coverage beyond the community version’s cutoff.

The Pros

• Zero application risk. You’re staying on 10.6, so there’s no version jump, no query behavior changes, no schema compatibility concerns. Your application works exactly as it does today.
• Enhanced Enterprise Capabilities. Gain access to hardened features designed for mission-critical use, such as advanced auditing, enterprise-grade authentication plugins, and optimized thread handling – all while maintaining the 10.6 familiarity.
• Continued security patches and bug fixes. MariaDB plc actively maintains Enterprise Server and delivers security updates, critical fixes, and enterprise-grade patches.
• Professional support. You get access to MariaDB support engineers – real humans – rather than community forums.
• Minimal operational disruption. The migration from Community Server to Enterprise Server on the same version is straightforward. No data migration required.

What to Plan For

• Innovation Lag. Staying on 10.6 means missing out on the performance breakthroughs and modern features (such as vector search and optimizer improvements) found in version 11.8.
• Cumulative Technical Debt. The longer you stay on 10.6, the larger the architectural leap will be when you finally upgrade.
• Developer Experience. Your team remains restricted to older SQL syntax and capabilities while the industry standard evolves.

How to Do It

The migration from Community Server 10.6 to Enterprise Server 10.6 is essentially a package swap – your data files stay in place. Here’s the high-level process:

1. Get your Customer Download Token. Contact MariaDB to upgrade to a MariaDB Enterprise subscription. Once you have a current subscription, you will need to retrieve your token.
   
2. Follow the official migration guide. For detailed, step-by-step instructions – including backup procedures, repository configuration, and package installation – refer to the official documentation: Upgrade from MariaDB Community Server to MariaDB Enterprise Server 10.6.
   
3. Verify the transition. After completing the migration steps, restart the service and run SELECT VERSION(); to confirm your server is now running the hardened MariaDB Enterprise edition.

Path 2: Upgrade to a Newer Server Version (Self-Managed)

Best for: Teams who are comfortable managing their own infrastructure, want full control over their environment, and are ready to move to a newer, actively supported version of MariaDB.

What This Is

This path is about upgrading from 10.6 to a current, maintained version of MariaDB while keeping it self-managed – meaning you own the infrastructure, the upgrade process, and the ongoing operations. The key decision within this path is which version to land on: MariaDB Enterprise Server or MariaDB Community Server.

Both are legitimate options. But if you’re running production workloads, handling sensitive data, or operate in a regulated industry, Enterprise Server is the stronger choice – even for teams that want to stay self-managed. You get the same hands-on control over your infrastructure, plus guaranteed security patches, a defined support SLA, and access to MariaDB engineering when something goes sideways. Community Server is a solid option for teams with the expertise to rely on community resources and a lower risk tolerance for support gaps.

For Enterprise Server, the recommended upgrade target is MariaDB Enterprise Server 11.8, supported until 2030 plus extended support until 2033. For Community Server, MariaDB 11.8 LTS is the equivalent long-term release.

The Pros

• You stay in control. Your infrastructure, your configuration, your upgrade schedule. No vendor lock-in, no cloud dependency.
• Modern features and performance improvements. Newer versions bring a rewritten query optimizer, improved JSON support, better replication capabilities, vector search support, and more.
• Enterprise Server adds professional support without changing the deployment model. You get a guaranteed SLA, direct access to MariaDB engineers, and security patches – without giving up self-managed infrastructure.
• Extended Support Lifecycle. Version 11.8 offers a robust long-term roadmap. The Community edition provides coverage through June 2028. For organizations requiring maximum longevity, MariaDB Enterprise Server 11.8 extends standard support until October 2030, with an additional three-year extended support window available to keep your systems secure through 2033.
• Zero Application Changes. Transitioning to MariaDB Server 11.8 is designed to be seamless for your development team. Because the wire protocol remains backward compatible, your existing application code requires no modifications. You get the benefits of the latest version without the need for a code rewrite.

What to Plan For

• You own the upgrade process. Testing, rollback planning, and configuration validation require dedicated time and resources – particularly across a major version jump. Factor this into your project timeline before committing to a cutover date.
• Query plan changes. The query optimizer was significantly rewritten in version 11.0. Most queries will perform the same or better, but it’s worth running your workload against a staging environment to catch any execution plan changes before they reach production.
• Configuration audit required. Some variables from 10.6 have been removed or renamed in newer versions. Set aside time to review your my.cnf against the “What’s New” documentation for each version in your upgrade path before starting the server.
• Support model for Community edition. If you choose the Community edition, understand the risks associated with running community unsupported software. Teams without deep in-house MariaDB expertise should weigh this carefully against the Enterprise option.

How to Do It

The upgrade steps are largely the same whether you’re targeting Enterprise or Community Server. The difference is in how you configure your package repository. Here’s an overview targeting 11.8 as the recommended destination:

If upgrading to MariaDB Enterprise Server 11.8 (recommended for production):

1. Get your Customer Download Token. Contact MariaDB to upgrade to a MariaDB Enterprise subscription. Once you have a current subscription, you will need to retrieve your token.
   
2. Follow the official upgrade guide. For detailed, step-by-step instructions – including backup procedures, repository configuration, and package installation – refer to the official documentation: Upgrade to MariaDB Enterprise Server 11.8.

Verify the transition. After completing the migration steps, restart the service and run SELECT VERSION(); to confirm your server is now running the hardened MariaDB Enterprise edition.

If upgrading to MariaDB Community Server 11.8 LTS:

1. Backup and Stop. Perform a full logical or physical backup of your data. Stop the MariaDB service to ensure a consistent state before the binary swap.
   
2. Update your repository. Refer to the MariaDB Package Repository Setup and Usage guide to generate the correct setup for your OS, targeting version 11.8. Install the updated packages via your package manager.

Steps common to both editions:

• Plan your upgrade path. Review the release notes for version 11.8 to understand the architectural improvements and ensure your environment meets the new requirements.
• Audit your configuration. Before starting the server, review your my.cnf file to identify and remove any deprecated or obsolete variables. Revisit the “What’s New” documentation pages for each version jump to confirm which options have been removed.
• Perform the upgrade. Follow the standard upgrade procedure for your operating system, ensuring a full backup is taken before replacing the binaries.
• Run the upgrade tool. Execute mariadb-upgrade to update the system tables and ensure all internal structures are compatible with the 11.8 engine.

A note on staged rollouts: For mission-critical systems, consider a staged approach – set up the new version as a read replica of your existing 10.6 primary, validate behavior, then promote it. This gives you a live rollback path if anything looks wrong.

Path 3: Move to a Fully Managed Version in MariaDB Cloud

Best for: Teams that want to get off the database operations treadmill entirely – no patching, no upgrades, no infrastructure management.

What This Is

MariaDB Cloud is a fully managed database as a service (DBaaS) that runs MariaDB Enterprise Platform on AWS, Azure, or Google Cloud. You get a production-grade MariaDB database – with high availability, automated backups, built-in monitoring, and automatic upgrades – without managing any of the underlying infrastructure yourself. MariaDB handles everything from OS patching to version upgrades.

Pros

• No more upgrade planning. MariaDB manages version currency for you. You stay on supported versions without having to orchestrate the upgrades yourself.
• Enterprise features out of the box. High availability, automatic failover, built-in SSL, role-based access control, and real-time performance monitoring are all included.
• Multicloud flexibility. Deploy on AWS, Azure, or Google Cloud – or span across them.
• Serverless option. MariaDB Cloud offers both provisioned instances (for consistent workloads) and serverless (for variable or dev/test workloads that should scale to zero).
• Optional fractional DBA service. If you want human expertise on call without hiring a full-time DBA, MariaDB offers a managed DBA service.
• Integrated AI capabilities. MariaDB Cloud includes agentic AI features and a no-code AI agent builder, relevant if you’re building applications that interact with your data in natural language.

What to Plan For

• Shared Responsibility Model. Moving to a managed service involves a trade-off: you gain significant automation and reduced administrative burden in exchange for standardized configuration. While this streamlines operations, it means working within the provider’s optimized guardrails for tuning and following a coordinated upgrade schedule rather than maintaining bespoke, manual control over the underlying infrastructure.
• Data Locality and Transfer. The efficiency of a cloud model is highly dependent on where your application lives. If your application remains on-premises while the database moves to the cloud, you must account for data egress and network latency. This path is most effective when the entire application stack is co-located within the same cloud ecosystem to optimize both performance and cost.
• Connectivity Requirements. A cloud-hosted database relies on secure, reliable network paths (such as VPNs, dedicated interconnects, or public endpoints). This shift requires a network architecture capable of maintaining constant external connectivity, which may require a transition period for organizations currently operating in strictly air-gapped or localized on-premises environments.

How to Do It

Migrating to MariaDB Cloud involves exporting your data from your current 10.6 instance and importing it into a new cloud service. Here’s the process:

1. Sign up and provision your service. Go to mariadb.com/cloud-get-started and create an account. Choose your cloud provider (AWS, Azure, or GCP), region, and service tier (provisioned or serverless). For most production workloads starting from 10.6, a provisioned transaction service is the right choice.
2. Follow the steps in our documentation to migrate your database to MariaDB Cloud. Go to mariadb.com/docs/mariadb-cloud/cloud-data-handling/migration-data-loading/data-loading-migration and follow the steps most appropriate to your requirements.

MariaDB Cloud documentation is available at mariadb.com/docs/mariadb-cloud.

Which Path Is Right for You?

Here’s a quick way to think about it:

	Path 1: Enterprise 10.6	Path 2: Upgrade (Self-Managed)	Path 3: MariaDB Cloud
Cost	Commercial license	Enterprise license or free (Community)	Usage-based subscription
Version change	None	Major upgrade	Managed by MariaDB
Operational overhead	Self-managed	Self-managed	Fully managed
Support	SLA-backed	SLA-backed (Enterprise) or best-effort (Community)	SLA-backed
Ideal for	Stability-first teams, regulated industries	Teams wanting control + modern features	Teams that want to offload ops

None of these paths is wrong. The priority is simply to have a plan before July 6, 2026 – because running an unpatched, unsupported database in production is a risk worth taking seriously.

If you need help evaluating which path fits your situation, contact the MariaDB team or visit mariadb.com for more resources.

Frequently Asked Questions

What happens if I do nothing after July 6, 2026?
Your database will continue to run – nothing breaks automatically. However, you’ll stop receiving security patches and bug fixes

What is the exact EOL date for MariaDB Community Server 10.6?
July 6, 2026. After July, the MariaDB community will no longer release updates, security patches, or bug fixes for this version.

How is MariaDB Enterprise Server 10.6 different from Community Server 10.6?
It’s the same underlying 10.6 codebase, hardened and packaged by MariaDB plc with additional enterprise features, security enhancements, and professional support. MariaDB plc also backports some newer features to older releases so customers have access to new innovation in stable releases, without having to upgrade to a new version. The Enterprise version also has an extended EOL of August 23, 2029 – roughly three years beyond the community version.

Can I upgrade directly from 10.6 to 11.8 Community Server?
Yes. MariaDB is designed to support upgrades between major versions. However, skipping multiple major versions means more compatibility changes to account for – particularly around the query optimizer rewrite introduced in 11.0. Thorough testing before promoting to production is strongly recommended.

What is MariaDB Cloud?
MariaDB Cloud is MariaDB’s fully managed database as a service offering. It runs MariaDB Enterprise Platform on AWS, Azure and Google Cloud. Plus, MariaDB Cloud handles all infrastructure management, patching, upgrades, high availability, and backups on your behalf.

Does migrating to MariaDB Enterprise Server require a data migration?
No. Moving from Community Server 10.6 to Enterprise Server 10.6 is a package-level swap – you uninstall the community packages and install the enterprise packages. Your data directory stays in place and requires no conversion.

Which version should I upgrade to for Path 2 (self-managed upgrade)?
For production workloads, MariaDB Enterprise Server 11.8 is the recommended target – it gives you a supported, stable version with a commercial SLA and security patches managed by MariaDB plc. If you’re on the Community track, MariaDB 11.8 LTS is the equivalent long-term release, supported until May 2029. Either way, avoid rolling releases (like 12.0, 12.1, 12.2) for production systems unless you’re prepared to keep upgrading frequently.

Is there a risk my application will break after upgrading to a newer version?
The MariaDB connection protocol is backward compatible, meaning your application’s code and SQL queries will almost always work without changes. The main risk area is the rewritten query optimizer in 11.0+, which can change execution plans for complex queries. Always run your test suite and review the slow query log after upgrading in a staging environment before rolling to production.

How long does a migration to MariaDB Cloud typically take?
For smaller databases (under a few GB), an initial migration can be completed in hours. Larger databases may take longer depending on import speed and your network connection to the cloud provider. Most teams allow a few days to a few weeks for testing and validation before cutting over production traffic.

Where can I get help planning my migration?
Start with the official documentation at mariadb.com/docs. For enterprise options and hands-on assistance, contact MariaDB directly at mariadb.com/contact. For MariaDB Cloud, you can start at mariadb.com/cloud-get-started.