> ## Content Index > Fetch the complete content index at: https://stackurity.ai/blog/llms.txt > Use this file to discover other available public pages before exploring further. # MariaDB 13.0 end of life: December 31, 2026 and what to do - URL: https://stackurity.ai/blog/mariadb-13-0-end-of-life/ - Published: 2026-11-12T02:05:04.000Z - Updated: 2026-11-12T02:05:04.000Z - Description: MariaDB 13.0 reaches end of life on December 31, 2026. See who is affected, how to check one server and how to plan the upgrade. - Author: Stackurity Research Team - Tags: Web Servers and Databases, #deep-dive ## TL;DR - MariaDB 13.0 reaches end of life on December 31, 2026, according to endoflife.date, about seven weeks from today. - The line was released on September 15, 2026, and the latest release in it is 13.0.2\. The record lists no separate extended support date and does not mark it as a long term support release. - Update every 13.0 server to 13.0.2 now, then plan the move to a MariaDB release line that is still supported. - After the end of life date, new vulnerabilities are fixed only in newer release lines, so any MariaDB 13.0 server left behind keeps its flaws. - Stackurity matches end-of-life data against your inventory every day, including MariaDB found in packages, images and managed database services. ## What reaches end of life, in plain English MariaDB is a relational database that sits behind web shops, content management systems, internal tools and billing systems. Each release line is supported for a limited time. While it is supported, the project ships patch releases that fix bugs and security flaws. When it reaches end of life, that stops, even if a serious flaw is reported the following week. The [endoflife.date record for MariaDB](https://endoflife.date/mariadb) shows that the 13.0 line was released on September 15, 2026 and reaches end of life on December 31, 2026\. The record shows no extended support date and does not mark it as a long term support release, so December 31, 2026 is the date to plan around. In short, this is a release line that was available for a little over three months before its support window closes. ## Why it matters now Nothing stops working on the day. Your applications keep running and your queries keep returning rows. What changes is the next time a flaw is found: a supported line gets a patch and you update, while an unsupported line gets nothing, and you must move to a newer release under pressure. A database is also where the valuable data lives: customer records, orders, sessions and credentials. A flaw in the database server is rarely the first thing an attacker uses, but it is often the thing that turns a small foothold into a large incident. Our guides to [a PostgreSQL release leaving support](https://stackurity.ai/blog/postgresql-14-end-of-life/) and to [a Redis release line reaching its end](https://stackurity.ai/blog/redis-8-0-end-of-life/) describe the same pattern for other data stores, and teams that run several of them face a handful of deadlines in a few weeks. There is also an audit cost. Customers and auditors ask which components are still supported, and a database on an unsupported release needs an exception, a compensating control or a dated upgrade plan. It is far easier to have the plan before the date than to explain the gap afterwards. Database upgrades take time because applications depend on client libraries, replication setups, backup tooling and stored routines that were tested against one release line. Seven weeks is not enough to finish a careful move for every instance, but it is enough to find them all, patch to the latest release and put a date on each remaining move. Because the date falls at the end of the year, remember that change freezes and holidays shrink the number of maintenance windows you really have. ## Am I affected? You are affected if any server, container image, managed database or application you run uses MariaDB 13.0, in production, staging, a reporting replica or a scheduled job. Any release whose version starts with the line number 13.0 belongs to it, up to the latest, 13.0.2. To check one Linux machine by hand, run: ``` mariadbd --version mariadb --version ``` The first prints the version of the server binary, and the second the version of the command line client, which can differ. To ask a running server what it is, connect and run: ``` SELECT VERSION(); ``` To see whether MariaDB came from a distribution package, run one of these: ``` dpkg -l 'mariadb*' rpm -qa 'MariaDB*' ``` For a container image, run the same commands inside the container, and also read the image named in each Dockerfile and compose file, since MariaDB may come from the image rather than from your own packages. For a managed service, read the engine version in the provider console or API. Also search repositories for configuration that pins a MariaDB image tag. One caveat applies to distribution packages. Linux distributions backport fixes, so a package version can look older than the upstream release while still containing a fix. The end of life date, however, is the upstream line's date: when the line ends, the distribution and the MariaDB project decide separately what they will keep supporting, so read your distribution's notice rather than relying on the upstream date alone. ## How to upgrade away from MariaDB 13.0 1. Find every use of MariaDB 13.0\. List servers, container images, managed databases and repositories, and note the owner, environment and data sensitivity of each. 2. Update each one to 13.0.2, the latest release in the line, run the tests and deploy. This keeps you on the newest patched code while you plan the larger move. 3. Choose the supported MariaDB line you will move to. Check the MariaDB release notes and the endoflife.date page for MariaDB for the current list, because it is not part of the data we cite here, and pick one your client libraries, replication setup and hosting service support. 4. Rehearse the move on a copy. Restore a recent backup into a test instance on the new line, run your application against it and compare query behaviour, performance and replication before you touch production. 5. Switch over in a maintenance window, keep the old instance until the new one has served traffic cleanly, and update base images and compose files to match. 6. Check again after deploying. Confirm that no host or image still reports MariaDB 13.0, and record the instances you could not move before the date, each with an owner and a deadline. ## How to check with Stackurity Stackurity keeps one live inventory of your servers, applications, repositories, container images, Kubernetes workloads and AWS managed services, and matches it against end-of-life dates every day. A read-only agent reads installed packages on supported Linux distributions, and with the opt-in Docker setting it also reads the images of running containers. Managed databases such as RDS can be added as AWS managed services. Instances on the MariaDB 13.0 line appear in a short list, most urgent first. Be aware of the limits. Network appliance firmware, statically linked libraries and libraries copied into an application outside a package manager are not covered, so check those by hand. After you upgrade, check again asks the agent for a fresh report and records whether the issue is really gone. See [how Stackurity handles fixes](https://stackurity.ai/docs/remediation) in the docs. The core is open source, and Stackurity Cloud has a 14-day free trial without a card: [start a free trial](https://app.stackurity.dev/signup?utm%5Fsource=blog&utm%5Fmedium=referral&utm%5Fcampaign=web-servers-databases&utm%5Fcontent=mariadb-13-0-end-of-life). ## FAQ ### When does MariaDB 13.0 reach end of life? According to endoflife.date, MariaDB 13.0 reaches end of life on December 31, 2026\. After that date the release line gets no further fixes. ### Is MariaDB 13.0 still getting security updates? Until its end of life date, the line is still listed as supported, and the latest release in it is 13.0.2\. After December 31, 2026 new flaws will be fixed only in newer release lines. ### What should I upgrade MariaDB 13.0 to? Move to a MariaDB release line that the MariaDB project still supports. Read the MariaDB release notes and the endoflife.date page for MariaDB for the current list, then pick the line with the longest remaining support that your clients, replication setup and hosting service accept. ### Does Stackurity find MariaDB 13.0 on my servers? Stackurity reads installed packages on supported Linux distributions, can read the images of running Docker containers when you opt in, and can add AWS managed services such as RDS. It matches end-of-life data against that inventory every day. MariaDB on appliances, or copied into an application outside a package manager, is not covered. Sources: [endoflife.date record for MariaDB](https://endoflife.date/mariadb), [Stackurity product facts](https://stackurity.ai/llms.txt).