MariaDB Enterprise Operator 26.03 is a Stable (GA) release of MariaDB Enterprise Operator, released on 2026-03-11
Release date: 11 March 2026
Running production databases on Kubernetes means planning for the moments when things go wrong: a bad deployment, accidental data changes, or infrastructure incidents. In MariaDB Enterprise Kubernetes Operator 26.03, we’re focused on strengthening disaster recovery with two major additions: Point-in-time recovery (PITR) for granular restores, and native Azure Blob Storage support for reliable backup, restore, and recovery workflows for Azure customers.
These capabilities help teams tighten RPO/RTO targets, reduce downtime, and standardize recovery processes across environments—without adding operational complexity. Let’s take a look at what’s new.
If you're updating from previous versions, please follow the UPDATE GUIDE to ensure a safe transition.
The Enterprise Kubernetes Operator now enables granular database restores to an exact point in time for MariaDB primary/replica topologies. Point-in-time recovery is enabled by combining periodic physical backups made with mariadb-backup or VolumeSnapshot with interval-based binlog archiving to object storage. To restore a database, the Operator restores the latest base backup before a target timestamp and replays archived binlogs from the backup’s GTID position up to the requested moment. Additionally, the Enterprise Kubernetes Operator adds a configurable archiving cadence to control RPO, parallelized upload/download to reduce restore time (RTO), and binlog retention policy to prevent uncontrolled storage growth.
Refer to the point-in-time recovery documentation for more details.
Azure customers now have a native Azure Blob Storage support as an object storage backend for physical backups (mariadb-backup) and binlog archives. This enables backup/restore, bootstrap, scale-out, and recovery workflows to use Azure Blob Storage with the same experience as with S3 storage.
MariaDB Enterprise Kubernetes Operator 26.03 delivers a meaningful step forward in cloud-native resilience: Point-in-time restore brings precise recovery to a specific moment in time, and native Azure Blob Storage support extends backup and recovery workflows seamlessly to Azure. Together, these enhancements make it easier to meet SLAs, reduce data loss during incidents, and recover faster—while keeping everything Kubernetes-native and automated.
Refer to the physical backup documentation for more details.
On-demand physical backups may now be scheduled by setting schedule.onDemand=<id> in the PhysicalBackup resource.
Also, to further expand point-in-time recovery capabilities, physical backups may automatically be scheduled when the primary changes by setting schedule.onPrimaryChange=true in the PhysicalBackup resource
Refer to the physical backup documentation for more details.
targetRecoveryTimeTo satisfy requirements of point-in-time recovery, we have unified the behaviour of the bootstrapFrom.targetRecoveryTime field in the MariaDB object: Logical and physical backup files whose timestamp is closest to targetRecoveryTime, but not after, will be matched.
Please take this into account when upgrading to this version.
MaxScaleTo improve maintainability, minimize complexity and reduce the size of the CRD bundle (getting close to the 1MB hard limit), we are deprecating the MaxScale embedded definition inside the MariaDB CR in favor of deploying MaxScale as a separate CR.
To make the transition easier, we are providing you with this migration guide. Refer to the MaxScale documentation for additional details.
The current release has been tested with the following versions:
Kubernetes
1.35
OpenShift
4.18.6
MariaDB Enterprise Server
11.8.5-2
MaxScale
25.10.1
This page is: Copyright © 2026 MariaDB. All rights reserved.
Last updated
Was this helpful?
Was this helpful?