# MariaDB Enterprise Kubernetes Operator 26.03

**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**](https://mariadb.com/docs/tools/mariadb-enterprise-operator/updates/update-26.03) to ensure a safe transition.

### Point-in-Time Recovery

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](https://mariadb.com/docs/tools/mariadb-enterprise-operator/backup-and-restore/pitr) for more details.

### Azure Blob Storage Support for Backup and Restore

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](https://mariadb.com/docs/tools/mariadb-enterprise-operator/backup-and-restore/physical_backup#storage-types) for more details.

### New scheduling options for physical backups

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](https://mariadb.com/docs/tools/mariadb-enterprise-operator/backup-and-restore/physical_backup#scheduling) for more details.

### Behaviour change in `targetRecoveryTime`

To 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.

## Deprecating embedded `MaxScale`

To improve maintainability, minimize complexity and reduce the size of the CRD bundle (getting close to the [1MB hard limit](https://azure.github.io/azure-service-operator/design/adr-2023-02-helm-chart-size-limitations/)), 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](https://mariadb.com/docs/tools/mariadb-enterprise-operator/migrations/migrate-embedded-maxscale-to-maxscale-resource). Refer to the [MaxScale documentation](https://mariadb.com/docs/tools/mariadb-enterprise-operator/topologies/maxscale) for additional details.

### Platform and component versions

The current release has been tested with the following versions:

| Platform/Component        | Version  |
| ------------------------- | -------- |
| Kubernetes                | 1.35     |
| OpenShift                 | 4.18.6   |
| MariaDB Enterprise Server | 11.8.5-2 |
| MaxScale                  | 25.10.1  |

<sub>*This page is: Copyright © 2025 MariaDB. All rights reserved.*</sub>

{% @marketo/form formid="4316" formId="4316" %}