The latest MariaDB Kubernetes Operator release, version 25.08.0, is now available. This ships with enhancements, especially in how you can approach disaster recovery in MariaDB clusters, and how the Operator is adapting to the requirements of modern data-centric applications.
Disaster Recovery with Physical Backups
One of the main features in 25.08.0 is the introduction of PhysicalBackup
Custom Resources. For some time, logical backups have been the only supported method, but as databases grow, so do the challenges of restoring them quickly. Physical backups offer a more efficient path, especially for large datasets. They work at the physical directory level rather than through execution of SQL statements.
This capability has been implemented in two ways:
mariadb-backup
Integration: MariaDB’s native backup tool,mariadb-backup
, can be used directly through the Operator. You can definePhysicalBackup
CRs to schedule backups, manage retention, apply compression, and even specify S3-compatible storage. The restoration process is straightforward: simply reference thePhysicalBackup
in a newMariaDB
resourcebootstrapFrom
field, and the Operator handles the rest, preparing and restoring the backup files. A great feature for reducing RTO (Recovery Time Objective).- Kubernetes-native
VolumeSnapshots
: Alternatively, if your Kubernetes environment is set up with CSI drivers that supportVolumeSnapshots
, physical backups can now be created directly at the storage level. This method creates snapshots of MariaDB data volumes, offering another robust way to capture a consistent point-in-time copy of your database. Restoring from aVolumeSnapshot
is equally simple and allows for quick provisioning of new clusters from these storage-level backups.
These new physical backup options provide greater flexibility and significantly faster recovery times, which are absolutely critical in production environments. The aim is to provide more tools to build a resilient and robust data infrastructure.
MariaDB 11.8 and the VECTOR
Data Type
The Operator is also keeping pace with the latest advancements in MariaDB itself. The MariaDB Kubernetes Operator 25.08.0 now supports MariaDB 11.8 Community Server by default.
One of the most important features in MariaDB 11.8 is the VECTOR
data type. This is a notable development for anyone working with AI applications (watch this webinar to get up to speed). High-dimensional vectors are fundamental in areas like similarity search for RAG (Retrieval Augmented Generation) applications.
With the VECTOR
data type, these vectors can be stored and manipulated directly within a MariaDB database without having to introduce an often complex, dedicated vector database—MariaDB is also a vector database! If you’re using frameworks like LangChain or Spring AI, the new MariaDB integrations allow using MariaDB as a vector store.
Deployments with the New Helm Chart
The mariadb-cluster
Helm chart has been introduced to facilitate database instance deployments. This new chart streamlines the provisioning of a MariaDB cluster along with its associated Custom Resources managed by the Operator. Instead of manually configuring relationships between different CRs, the Helm chart takes care of it, allowing management of an entire MariaDB deployment as a single Helm release.
Enterprise Support
For mission-critical, production environments, the MariaDB Enterprise Kubernetes Operator provides enterprise-grade support, including Red Hat OpenShift certification, and utilizes a secure Red Hat UBI base image. The operator offers robust security features like a customizable certificate lifecycle and advanced private key algorithms, while managing both MariaDB Enterprise Server and MariaDB MaxScale.
What Else is New?
Beyond these major highlights, this release includes important replication improvements, pushing closer to general availability for this feature. You’ll also find various bug fixes and enhancements. A new calendar-based versioning scheme has also been adopted for clarity and predictability.
The team is committed to continuously improving the MariaDB Operator based on user needs. Your feedback is invaluable! So if you have any questions or encounter any issues, please don’t hesitate to open an issue on GitHub or join us on the MariaDB Community Slack.
As always, the detailed changelog and upgrade guide can be found on the GitHub release page.