MariaDB Enterprise Manager

MariaDB Enterprise Operator

MariaDB Enterprise Operator provides a seamless way to run and operate containerized versions of MariaDB Enterprise Server and MaxScale on Kubernetes, allowing you to leverage Kubernetes orchestration and automation capabilities. This document outlines the features and advantages of using Kubernetes and the MariaDB Enterprise Operator to streamline the deployment and management of MariaDB and MaxScale instances.

MariaDB Enterprise MCP Server

MariaDB Enterprise MCP (Model Context Protocol) Server is a secure, enterprise-grade application designed to act as the primary interface between AI assistants and MariaDB data ecosystems. This product solves a key challenge: how to allow powerful AI agents to safely and efficiently leverage an organization's most valuable asset—its data.

MariaDB AI RAG

MariaDB AI RAG is an enterprise-grade Retrieval-Augmented Generation (RAG) solution that integrates with MariaDB to provide AI-powered document processing, semantic search, and natural language generation capabilities.

MariaDB Enterprise Manager is a comprehensive observability and management solution designed for your entire database fleet. It provides advanced, topology-aware monitoring and a powerful suite of visual tools for query development and schema management, all from a single, centralized interface.

At its core, Enterprise Manager uses lightweight agents to collect deep telemetry from your standalone databases, replicated topologies, and MaxScale clusters via the OpenTelemetry standard. This foundation powers the integrated Grafana dashboards, which come pre-packaged with production-ready visualizations and alerts. Beyond monitoring, the provides a shared environment for developers and DBAs with an advanced Query Editor and a visual ERD Designer. The entire system is secured with role-based access control, audit logging, and can integrate with your corporate identity provider (OIDC) for single sign-on.

MariaDB Enterprise Manager is a client/server application for monitoring and managing MariaDB deployments. It provides topology-aware monitoring, visual schema management, and query editing across multiple database connections.

The architecture consists of two primary components: a central Enterprise Manager Server that aggregates data and hosts the user interface, and an Enterprise Manager Agent that is deployed on each monitored host.

Enterprise Manager Server

The Enterprise Manager Server runs on a dedicated host and acts as the central command center. It is delivered as a suite of Docker containers managed by Docker Compose.

For topologies managed by MaxScale, you can seamlessly access the MaxScale GUI directly from Enterprise Manager using Single Sign-On.SSO to MaxScale requires MaxScale 25.10.0 or higher.1

MariaDB Enterprise Manager allows you to monitor multiple logical databases or clusters that are managed by the same set of high-availability MaxScale instances. After adding your first MaxScale instance, you can easily add more monitors to track different services without re-entering the connection details.

Before installing MariaDB Enterprise Manager, ensure that your firewall and network rules allow traffic on all required ports. Proper connectivity is essential for the system to function correctly.

The following table details the necessary ports and their purposes.

This section provides an overview of the deployment process for MariaDB Enterprise Manager, covering installation and upgrades for both the central server and the monitoring agents.

MariaDB Enterprise Manager is designed for a streamlined deployment experience. You can launch the main server with a single-line command for a quick start, and a UI-integrated helper tool simplifies the process of installing and registering agents on your monitored databases.

Installing the Enterprise Manager Server

The Enterprise Manager Server is a Docker-based application installed on a dedicated host. The installation is handled by the installer script, which pulls the necessary container images and starts the application.

As a first step review the hardware, system, and network requirements:

This guide outlines the system and hardware requirements for deploying the Enterprise Manager Server and the Enterprise Manager Agent.

Enterprise Manager Server 🖥️

The Enterprise Manager Server is the central component that hosts the UI and stores monitoring data.

Hardware Sizing Guide

System Requirements

• CPU Architecture: x86-64

• Operating System: 64-bit Linux with Docker support.

• Software: Docker Engine and Docker Compose must be installed.

Enterprise Manager Agent🕵

The agent must be installed on each and instance you wish to monitor. Below are the supported operating systems.

Supported Platforms for MariaDB Server

Supported Platforms for MariaDB MaxScale

* Monitoring and Single Sign-On(SSO) are only supported for MaxScale versions 25.10 and Above

The mema-agent is a small application that must be installed on every server you wish to monitor with MariaDB Enterprise Manager, including MariaDB Server nodes and MaxScale nodes.

This guide covers the recommended installation method using a package manager.

Prerequisite: Create the Local Monitor User

Before installing the agent on a MariaDB Server host, you must create a local user that the agent will use to connect to the database and collect metrics.

Log in to your MariaDB Server and run the following:

Replace <password> with a secure password. You will need these credentials later when linking the agent in the Enterprise Manager UI.

Installation via Package Manager (Recommended)

This method uses your OS's native package manager (dnf, apt, zypper) to install the agent from the MariaDB Enterprise repository.

Step 1: Configure the MariaDB Enterprise Repository

If you haven't already configured the MariaDB Enterprise repository on the server, follow these steps.

Step 2: Install the Agent Package

Once the repository is configured, use your system's package manager to install the agent.

The agent is now installed and running as a service.

Next Steps: Linking the Agent 🔗

After the agent is installed, it is running but not yet configured or linked to your MariaDB Enterprise Manager server.

The final step is to link the agent, which is done from the Enterprise Manager UI. Please refer to the for the specific steps to generate the linking command.

MariaDB Enterprise Manager provides a powerful and flexible alerting system, built on the capabilities of the integrated Grafana Alerting engine. It allows you to proactively monitor your entire database fleet, define custom rules for potential issues, and receive notifications through various channels to ensure you can respond quickly.

How It Works: The Alerting Flow

The alerting process in MariaDB Enterprise Manager follows a clear, four-step flow from detection to notification.

Key Alerting Concepts

To configure alerting effectively, it's helpful to understand these core concepts from Grafana:

This operator allows you to configure standalone MariaDB Enterprise Server instances. To achieve this, you can either omit the replicas field or set it to 1:

apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb
spec:
  rootPasswordSecretKeyRef:
    name: mariadb
    key: password

  replicas: 1

  port: 3306

  storage:
    size: 1Gi

  myCnf: |
    [mariadb]
    bind-address=*
    default_storage_engine=InnoDB
    binlog_format=row
    innodb_autoinc_lock_mode=2
    innodb_buffer_pool_size=800M
    max_allowed_packet=256M

  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      memory: 1Gi

  metrics:
    enabled: true

Whilst this can be useful for development and testing, it is not recommended for production use because of the following reasons:

• Single point of failure

• Upgrades require downtime

• Only vertical scaling is possible

For achieving high availability, we recommend deploying a highly available topology as described in the .

The MariaDB Enterprise Manager Workspace includes a powerful set of integrated tools that allow DBAs and developers to perform common administrative tasks graphically, without needing to write raw SQL commands. These features are primarily accessed through the Schemas Sidebar and dedicated tabs in the main worksheet area.

Schema Inspector

The Schema Inspector provides detailed, read-only metadata views for any selected schema object. This allows you to quickly understand the structure, data types, constraints, and dependencies of your tables, views, and other objects without querying the information_schema. To use it, simply click on an object in the Object Browser.

Object Browser

The Object Browser is the hierarchical tree view located in the Schemas Sidebar on the left side of the Workspace. It is your primary tool for navigating and exploring your database instances. You can expand databases to see their tables, views, stored procedures, and triggers, and use the filter box at the top to quickly locate specific objects.

Object Editor

The Object Editor allows you to create, modify, and delete schema objects using graphical forms and dialogs. You can access these functions by right-clicking on an object (or object type) in the Object Browser. This will open a context menu with actions such as:

• CREATE TABLE, CREATE VIEW

• ALTER TABLE

• DROP TABLE

User Management

This dedicated tab provides a grid-based interface for managing database users and their privileges directly, without writing GRANT or CREATE USER statements.

From this interface, you can:

• View a list of all database users and their assigned global privileges.

• Create new database users using a simple form.

• Edit an existing user's password or modify their privileges.

• Delete users who no longer require access.

Process List Viewer

The Processlist tab provides a real-time view of the database server's active sessions and the commands they are executing, equivalent to running SHOW FULL PROCESSLIST. This is an essential tool for diagnosing performance issues.

Using the Processlist Viewer, you can:

• Monitor all active connections, their current status (e.g., Query, Sleep), and how long they have been running.

• Identify long-running or problematic queries that may be impacting server performance.

• Manage live sessions, which may include the ability to terminate (kill) a specific process.

The examples catalog contains a number of sample manifests that aim to show the operator functionality in a practical way. Follow these instructions for getting started:

• Download the examples catalog:

curl -sLO https://operator.mariadb.com/examples/manifests.tar.gz
mkdir -p examples
tar -xzf manifests.tar.gz -C examples

• Install the configuration shared by all the examples:

• Start deploying examples:

Some examples rely on external dependencies for specific tasks, make sure to install them when it applies:

• for metrics

• for TLS certificates

• for S3 object storage

It is recommended to complement the examples with the documentation to understand the full range of configuration options available.

If you are looking for production-grade examples, you can check the following manifests:

• mariadb_replication_production.yaml and maxscale_replication_production.yaml for

• mariadb_galera_production.yaml and maxscale_galera_production.yaml for

The following is a list of images that have plugins installed and available to use.

apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb
spec:
  # ....
  myCnf: |
    [mariadb]
    plugin_load_add = auth_pam # Load auth plugin
  # ....

Standard SQL Query

{ "tool": "execute_sql", "parameters": { "database_name": "test_db", "sql_query": "SELECT * FROM users WHERE id = %s", "parameters": [123] } }

Create Vector Store

{ "tool": "create_vector_store", "parameters": { "database_name": "test_db", "vector_store_name": "my_vectors", "model_name": "text-embedding-3-small", "distance_function": "cosine" } }

Insert Documents into Vector Store

Semantic Search

RAG Generation

MariaDB AI RAG runs as a web service using Uvicorn/FastAPI. You can manage the service using standard system commands.

Starting the Service

# Start the service using the executable directly
./databridge

Viewing Logs

Logs are stored in the logs directory within the installation path:

MariaDB Enterprise Manager is a database management and observability solution that provides advanced topology-aware monitoring coupled with visual schema management, query editing, and ERD design across multiple database connections.

This guide describes steps to install MariaDB Enterprise Manager for evaluation purposes.

Prerequisites

In this guide, we will be migrating an external MariaDB into a new MariaDB instance running in Kubernetes and managed by MariaDB Enterprise Kubernetes Operator. We will be using for achieving this migration.

1. Take a logical backup of your external MariaDB using one of the commands below:

If you are currently using or migrating to a Galera instance, use the following command instead:

2. Ensure that your backup file matches the following format: backup.2024-08-26T12:24:34Z.sql

This guide illustrates, step by step, how to update to 25.10.2 from previous versions.

• The Galera data-plane must be updated to the 25.10.2 version. You must set updateStrategy.autoUpdateDataPlane=true in your MariaDB resources before updating the operator. Then, once updated, the operator will also be updating the data-plane based on its version:

The dashboard mirrors most sections from the dashboard extending it with Galera Metrics section and the Galera Nodes table. Use this dashboard when you need Galera-specific cluster health alongside the familiar server views.

Galera Metrics

Insights into Galera Cluster health with critical metrics and node-specific status details.

Note: This is about backing up the data, configuration and collected metrics of the Enterprise Manager (EM), not the databases.

Backing up Enterprise Manager Server

The MariaDB Enterprise MCP (Model Context Protocol) Server is a secure, enterprise-grade application designed to act as the primary interface between AI assistants and MariaDB data ecosystems. This product solves a key challenge: how to allow powerful AI agents to safely and efficiently leverage an organization's most valuable asset—its data.

It achieves this by providing a single, hardened endpoint that offers not only standard database operations but also advanced AI workflow orchestration and integration with industry-standard authentication systems.

To set the hostname or IP address for an existing MariaDB Enterprise Management instance, follow these instructions. Changing the hostname or IP address is useful if your server's IP changed or if you need to switch from an IP address to a public DNS name.

This page explains how to configure email alerting for MariaDB Enterprise Manager using Grafana's integrated alerting engine. Configure SMTP credentials and server details in the main environment file so Enterprise Manager can send alert notifications via email.

This is an advanced draft.

Token management is a critical part of the system's security, handled primarily by the RAG API.

Token Generation

The process involves two main steps:

System Requirements

• Operating System: Linux (Debian/Ubuntu/RHEL), macOS 10.15+, or Windows 10/11

• CPU: 4+ cores recommended

By default, MariaDB Enterprise Manager retains detailed metrics for 30 days. You can configure this data retention period to balance your need for historical data with storage costs.

This guide explains how to change the retention period and how the underlying storage system works.

How to Change the Retention Period

Changing the retention time is done by editing the environment file for Enterprise Manager and then restarting the services.

Data Retention Policy

Prometheus, the time-series database used by Enterprise Manager, does not delete expired data instantly.

• Block-Based Storage: Prometheus stores metrics data in blocks, which are typically two-hour chunks of time. In the background, these small blocks are compacted into larger ones.

• Delayed Cleanup: Data is not deleted on a sample-by-sample basis. Instead, Prometheus removes an entire block once all the data within it has passed the retention period. This cleanup process runs in the background and may not be immediate.

Valid Retention Time Units

When setting PROMETHEUS_RETENTION_TIME, you can use the following units:

• y - years

• w - weeks

• d - days

This dashboard shows MaxScale’s health and load, how backend servers are seen by each MaxScale, and the traffic/query volume flowing through it—plus cache efficiency from the Query Classifier.

Topology Overview

Provides a visual representation of the entire system's architecture and connectivity.

System Metrics

System Metrics provide comprehensive insights into the performance and health of individual system resources.

MaxScale Metrics

Query Classifier Cache Metrics help in analyzing and optimizing query routing efficiency by tracking cache hits/misses and monitoring cache size.

Query Classifier Cache Metrics

Evaluate query routing efficiency by tracking and optimizing cache metrics like hits, misses, and cache size.

This guide aims to provide a quick way to get started with the MariaDB Enterprise Kubernetes Operator for Kubernetes. It will walk you through the process of deploying a MariaDB Enterprise Cluster and MaxScale via the MariaDB and MaxScale CRs (Custom Resources) respectively.

Before you begin, ensure you meet the following prerequisites:

• Configure your customer access for docker.mariadb.com

• Install the MariaDB Enterprise Kubernetes Operator

The first step will be configuring a Secret with the credentials used by the MariaDB CR:

Next, we will deploy a MariaDB Enterprise Cluster (Galera) using the following CR:

Let's break it down:

• rootPasswordSecretKeyRef: A reference to a Secret containing the root password.

• imagePullSecrets: The name of the Secret containing the customer credentials to pull the MariaDB Enterprise Server image.

• maxScaleRef: The name of the

After applying the CR, we can observe the MariaDB Pods being created:

Now, let's deploy a MaxScale CR:

Again, let's break it down:

• imagePullSecrets: The name of the Secret containing the customer credentials to pull the MaxScale image.

• mariaDbRef: A reference to the MariaDB CR that we want to connect to.

• replicas: The number of MaxScale instances to deploy.

After applying the CR, we can observe the MaxScale Pods being created, and that both the MariaDB and MaxScale CRs will become ready eventually:

To conclude, let's connect to the MariaDB Enterprise Cluster through MaxScale using the initial user and database we initially defined in the MariaDB CR:

Refer to the , the and the for further detail.

In order to effectively manage the full lifecycle of both replication and Galera topologies, the operator relies on a set of components that run alonside the MariaDB instances and expose APIs for remote management. These components are collectively referred to as the "data-plane".

Components

The mariadb-enterprise-operator data-plane components are implemented as lightweight containers that run alongside the MariaDB instances within the same Pod. These components are available in the operator image. More preciselly, they are subcommands of the CLI shipped as binary inside the image.

Init container

The init container is reponsible for dynamically generating the Pod-specifc configuration files before the MariaDB container starts. It also plays a crucial role in the MariaDB container startup, enabling replica recovery for the replication topolology and guaranteeing ordered deployment of Pods for the Galera topology.

Agent sidecar

The agent sidecar provides an HTTP API that enables the operator to remotely manage MariaDB instances. Through this API, the operator is able to remotely operate the data directory and handle the instance lifecycle, including operations such as replica recovery for replication and cluster recovery for the Galera topology.

It supports methods to ensure that only the operator is able to call the agent API.

Agent auth methods

As previously mentioned, the agent exposes an API to remotely manage the replication and Galera clusters. The following authentication methods are supported to ensure that only the operator is able to call the agent:

ServiceAccount based authentication

The operator uses its ServiceAccount token as a mean of authentication for communicating with the agent, which subsequently verifies the token by creating a . This is the default authentication method and will be automatically applied by setting:

This Kubernetes-native authentication mechanism eliminates the need for the operator to manage credentials, as it relies entirely on Kubernetes for this purpose. However, the drawback is that the agent requires cluster-wide permissions to impersonate the ClusterRole and to create , which are cluster-scoped objects.

Basic authentication

As an alternative, the agent also supports basic authentication:

Unlike the , the operator needs to explicitly generate credentials to authenticate. The advantage of this approach is that it is entirely decoupled from Kubernetes and it does not require cluster-wide permissions on the Kubernetes API.

Updates

Please refer to the updates documentation for more information about .

Welcome to MariaDB AI RAG! This section will guide you through installing, configuring, and running the MariaDB AI RAG API and MCP Server.

Documentation in This Section

Overview

Learn about the MariaDB AI RAG system architecture and components:

• System architecture

• Core modules (Ingestion, Chunking, Retrieval, Generation)

• Data flow and processing pipeline

• Integration with MariaDB vector database

Step-by-step installation instructions for all supported platforms:

• Linux (Ubuntu/Debian - .deb packages)

• Linux (RHEL/Fedora - .rpm packages)

• Windows (.msi installer)

• System requirements and prerequisites

Configure the RAG API and MCP Server:

• Environment variables

• Configuration file setup

• Database connection settings

• API keys and authentication

Manage the RAG API and MCP Server services:

• Starting and stopping services

• Service status monitoring

• Log file locations

• Troubleshooting service issues

Quick Start Guide

1. Install the package for your platform (see )

2. Configure your environment with database credentials and API keys (see )

3. Start the services using the service management commands

4. Verify installation by accessing the API health endpoint:

Next Steps

After completing the getting started guide:

• Explore the for detailed endpoint documentation

• Learn about for user management

• Review for optimization

Suspended state

When a resource is suspended, all operations performed by the operator are disabled, including but not limited to:

• Provisioning

• Upgrades

• Volume resize

• Galera cluster recovery

More specifically, the reconciliation loop of the operator is omitted, anything part of it will not happen while the resource is suspended. This could be useful in maintenance scenarios, where manual operations need to be performed, as it helps prevent conflicts with the operator.

Suspend a resource

Currently, only MariaDB and MaxScale resources support suspension. You can enable it by setting suspend=true:

This results in the reconciliation loop being disabled and the status being marked as Suspended:

To re-enable it, simply remove the suspend setting or set it to suspend=false.

MariaDB Server Metrics

MariaDB Server metrics are gathered with the Prometheus exporter for MySQL and stored in Enterprise Manager’s Prometheus with the mariadb prefix. The agent runs the exporter with the following collector flags:

MaxScale Metrics

MariaDB Enterprise Manager collects a wide range of time-series metrics from your MariaDB MaxScale instances to provide deep insight into their performance, health, and activity. Monitoring these metrics is crucial for diagnosing performance bottlenecks, ensuring high availability, and understanding how your database proxy is handling application traffic.

Here is the list of available collected by Enterprise Manager.

Node Metrics

Node metrics provide crucial information about the health and performance of the underlying hardware and operating system on each monitored host. These metrics are essential for diagnosing infrastructure bottlenecks, understanding resource utilization, and planning for future capacity.

MariaDB Enterprise Manager gathers these metrics using Prometheus Node Exporter, which includes a default set of collectors.

Key metrics collected by default include:

• CPU Usage: Overall and per-core utilization, load average, and context switching.

• Memory: Total, used, free, and cached memory, including swap space.

• Disk I/O: Read/write operations, throughput (bytes per second), and I/O time.

• Filesystem Usage: Total, used, and available space for each mounted filesystem.

For a complete and detailed list of all metrics gathered by the default collectors, please refer to the official .

The MariaDB AI RAG API provides a comprehensive RESTful interface for document ingestion, chunking, retrieval, and AI-powered generation. All endpoints require JWT authentication except for the login endpoint.

Available API Documentation

API Reference

Complete reference for all API endpoints including:

• Document ingestion and management

• Chunking operations

• Retrieval and search

• AI generation

Authentication and authorization documentation:

• JWT-based authentication

• User management endpoints

• Role-based access control

• Document sharing and permissions

Direct database ingestion capabilities:

• SQL query ingestion

• Table and view ingestion

• Role-based database access

• Structured data processing

High-level workflow endpoints:

• Full pipeline orchestration

• Ingestion orchestration

• Generation orchestration

• Multi-step RAG workflows

Quick Start

All API requests require authentication. First, obtain a JWT token:

Then include the token in subsequent requests:

Base URL

The default base URL for the API is:

For production deployments, replace with your configured host and port.

MariaDB Enterprise Manager can be integrated with external identity providers (like Okta, Keycloak, or Azure AD) using OpenID Connect (OIDC). This allows you to centralize user authentication, enforce your organization's security policies, and enable single sign-on (SSO).

MariaDB Enterprise Manager includes a comprehensive set of pre-configured alert rules to provide production-ready monitoring for your entire database stack out-of-the-box. These alerts are built on the integrated Grafana Alerting engine and are designed to detect common issues across your MariaDB Servers, Galera Clusters, MaxScale instances, and the underlying operating systems.

A key feature of these rules is the use of a "sustained for" duration. This means a condition must remain true for a specified period (e.g., 3 minutes) before an alert will fire. This prevents alert fatigue from brief, transient spikes and ensures you are only notified of persistent, actionable problems.

MariaDB Server

This documentation shows how to configure metadata in the MariaDB Enterprise Kubernetes Operator CRs.

Children object metadata

MariaDB and MaxScale resources allow you to propagate metadata to all the children objects by specifying the inheritMetadata field:

This means that all the reconciled objects will inherit these labels and annotations. For instance, see the Services

mariadb-enterprise-operator supports managing resources in external MariaDB instances i.e running outside of the Kubernetes cluster where the operator runs. This feature allows to manage users, privileges, databases, run SQL jobs declaratively and taking backups using the same CRs that you use to manage internal MariaDB instances.

ExternalMariaDB configuration

The ExternalMariaDB resource is similar to the internal MariaDB resource, but we need to provide a host

MariaDB Enterprise Kubernetes Operator provides a seamless way to run and operate containerized versions of MariaDB Enterprise Server and MaxScale on Kubernetes, allowing you to leverage Kubernetes orchestration and automation capabilities. This document outlines the features and advantages of using Kubernetes and the MariaDB Enterprise Kubernetes Operator to streamline the deployment and management of MariaDB and MaxScale instances.

What is Kubernetes?

Kubernetes is more than just a container orchestrator; it is a comprehensive platform that provides APIs for managing both applications and the underlying infrastructure. It automates key aspects of container management, including deployment, scaling, and monitoring, while also handling essential infrastructure needs such as networking and storage. By unifying the management of applications and infrastructure, Kubernetes simplifies operations and improves efficiency in cloud-native environments.

The "fleet" dashboard is the central inventory for all your monitored database topologies. It provides a hierarchical, at-a-glance overview of the health, status, and configuration of your entire database environment.

Understanding the Dashboard Columns

MariaDB Enterprise Manager provides security at multiple levels, including transport-layer encryption for all components, secure authentication, and a detailed audit log.

SSL/TLS Certificate Management

The Node Dashboard pane provides detailed visibility into the health and performance of individual nodes that run MariaDB Server and MaxScale. It combines uptime, system capacity, operating system details, and hardware utilization with disk and network activity. This view helps administrators ensure each node has sufficient resources and can support the workloads running on it.

Node Information

Provides a high-level, at-a-glance summary of a specific server node's status, configuration, and capacity.

This documentation aims to provide guidance on how to configure access to docker.mariadb.com in your MariaDB Enterprise Kubernetes Operator resources.

Customer credentials

MariaDB Corporation requires customers to authenticate when logging in to the . A Customer Download Token must be provided as the password. Customer Download Tokens are available through the MariaDB Customer Portal. To retrieve the customer download token for your account:

Troubleshooting installation/deployment issues for Enterprise Manager and Agent

This guide illustrates, step by step, how to update to 25.8.0 from previous versions.

• Uninstall you current mariadb-enterprise-operator for preventing conflicts:

Alternatively, you may only downscale and delete the webhook configurations:

• Upgrade mariadb-enterprise-operator-crds to 25.8.0

MariaDB AI RAG is an enterprise-grade Retrieval-Augmented Generation (RAG) solution that integrates with MariaDB to provide AI-powered document processing, semantic search, and natural language generation capabilities.

Documentation Contents

Getting Started

This operator gives you flexibility to define the storage that will back the /var/lib/mysql data directory mounted by MariaDB.

Configuration

The simplest way to configure storage for your MariaDB is:

This will make use of the default StorageClass available in your cluster, but you can also provide a different one:

Overview

This guide covers the basic configuration of the MariaDB AI RAG system. For production deployments and advanced configuration scenarios, please refer to the .

See Also:

• - Production configuration for Ubuntu/Debian

MariaDB Enterprise Manager provides two primary methods for exporting metrics, allowing you to integrate with external observability platforms for aggregation or long-term retention.

Enterprise manager provides a visual interface for creating entity relationship diagrams (ERD) and for observing existing database schemas, so you can quickly understand table relationships, identify dependencies, and visually assess the impact of schema changes before implementation.

This procedure outlines the steps required to access and utilize the ERD Designer within the Workspace section of Enterprise Manager UI.

1. From the main Workspace screen, click the "Run Queries" card.\
2. In the "Connect to..." dialog, select your target server, enter your credentials, and click Connect.\
3. Upon successful connection, the main ERD worksheet will appear.\

Creating ERD diagram

ERD Worksheet Features

The core of the designer is a visual canvas where you can build and manage your database structures.

Model Tables, Indexes, and Relationships

You can graphically manage all core MariaDB schema objects.

Create New Tables

Use the toolbar or right-click on the canvas to add new table entities to your diagram.

Edit Entities

Double-click any table to open the Entity Editor at the bottom of the screen.

Here, you can define and modify columns (including data types and NOT NULL constraints), indexes, and foreign keys through an intuitive interface.

Draw Foreign Keys

To create a new relationship, simply click the connection point on a column in one table and drag it to the column it references in another table.

Auto Layout

For large or complex schemas, the diagram can become cluttered. Use the Auto Arrange Entities feature, typically found in the top toolbar, to automatically rearrange the tables and relationships into a clean, organized, and easily navigable diagram.

Working with the ERD Worksheet

The ERD worksheet provides several tools and shortcuts to streamline your workflow.

Managing Foreign Keys

Right-click on a relationship link between two tables to open a context menu with quick actions, such as editing or removing the foreign key, toggling the relationship type (e.g., one-to-one vs. one-to-many), and changing NOT NULL constraints.

Exporting Your Model

Once your design is complete, you can export it for documentation or deployment. The export options, found in the toolbar or by right-clicking the canvas, include the following:

• Export as SQL Script: Generates the CREATE TABLE and ALTER TABLE statements for your entire diagram.

• Export as JPEG: Creates an image of your diagram for use in presentations or other documents.

• Copy script to clipboard: A quick way to get the SQL for pasting elsewhere.

Applying Changes to a Database

Click the "Apply Script" button (▶) in the toolbar to execute the generated SQL against your connected database. This allows you to deploy your new or modified schema directly from the designer.