MariaDB a annoncé Enterprise Platform 2026 avec un message clair pour les développeurs, équipes de données et administrateurs de bases : unifier en une plateforme unique les moteurs transactionnels, analytique et vectoriels, intégrer RAG natif et agents IA, et déployer le tout dans un environnement serverless dans le cloud. L’objectif ? répondre à des charges élastiques et imprévisibles propres aux applications intelligentes. La promesse est claire : moins d’éléments, moins de latence et plus de rapidité pour convertir des données opérationnelles en valeur commerciale.

Ce lancement positionne MariaDB comme la plateforme ultime pour construire la prochaine génération d’applications intelligentes. Au-delà du slogan, le package propose des décisions architecturales visant à éliminer radicalement le traditionnel ballet des ETL, data lakes, vector stores séparés et multiples pipelines qui freinent les équipes.

Qu’est-ce que “agéntique” en pratique (et pourquoi cela compte pour une base de données) ?

Le terme IA agéntique désigne des agents capables de raisonner, agir et coordonner des outils avec des objectifs de haut niveau. Dans le domaine des données, cela implique deux besoins :

1. Interroger et comprendre l’information avec contexte sémantique (d’où la recherche vectorielle et le RAG).
2. Transacter en temps réel (passer commande, ajuster des prix, ouvrir des sinistres, enregistrer des événements) sans changer de plateforme.

MariaDB 2026 cherche à résoudre ces deux enjeux dans un même plan d’exécution : transactionnel + analytique + vecteurs + RAG, avec, en plus, des copilotes qui proposent des capacités via langage naturel. L’idée ? si l’agent vit “dedans” la base et que celle-ci comprend sémantique, statistique et opérationnel, le passage d’un événement métier à une réponse intelligente et concrète se fait plus rapidement.

Les nouveautés, pièce par pièce

1) Vecteurs intégrés nativement (sans “autre” base vectorielle)

Après avoir introduit la recherche vectorielle au début de l’année, MariaDB insiste sur une approche native : pas besoin d’un moteur externe pour les incrustations, ce qui réduit la latence et déplace moins de données. La solution économise infrastructure et surtout complexité opérationnelle : une seule authentification, observabilité et sécurité pour tout.

2) “RAG-in-a-Box”: RAG géré et automatisé

La plateforme intègre MariaDB AI RAG, son fameux “RAG en box”. La société affirme qu’il élimine la nécessité de pipelines de récupération, stores vectoriels ou même de gérer les embeddings explicitement : la base se charge de toutes les étapes de manière automatisée et optimisée. Pour ceux qui ont souffert des “fils” classiques RAG (tokenisation, batchs d’embeddings, chunking, rafraîchissement), l’objectif d’opérationnaliser le RAG avec moins d’éléments peut faire une différence essentielle.

3) Copilotes intégrés : un Text-to-SQL pour les devs et un “DBA as a service”

MariaDB Cloud propose des agents prêts à l’emploi :

• Un copilote développeur (Text-to-SQL) qui répond en langage naturel et génère des requêtes directement sur les données.
• Un copilote DBA, dédié à l’optimisation, débogage et opérations, orienté vers la productivité des équipes de base de données.

Ce qui prime, ce n’est pas le buzzword, mais une intégration avec sécurité, catalogue et audit de la plateforme.

4) MCP Servers : l’intermédiaire avec l’écosystème des agents

Grâce à Model Context Protocol (MCP) Servers, les agents peuvent dialoguer avec MariaDB et d’autres systèmes de façon standardisée. Au-delà de la consultation ou la recherche vectorielle, ces serveurs peuvent lancer des bases serverless dans le cloud et se connecter aux copilotes MariaDB. Résultat : une automatisation intelligente qui lit, raisonne et exécute des actions (création de bases, migrations, déclenchements de tâches).

5) Serverless dans MariaDB Cloud : élastique par défaut

Les plateformes intelligentes sont confrontées à des pics imprévisibles. Pour les absorber sans maintenir des machines sous-utilisées, MariaDB propose sa base serverless: échelle automatique, simplicité opérationnelle et paiement à l’usage. Rien de révolutionnaire dans le cloud, mais essentiel lorsque 100 agents décident d’opérer simultanément ou qu’un flux RAG explose en campagne commerciale.

6) Analytique opérationnelle accélérée avec MariaDB Exa

La grande nouveauté en analytique : MariaDB Exa, conçue pour analyses complexes sur des données opérationnelles multi-TB, avec des performances qui, selon MariaDB, dépassent de >1.000× celles des moteurs OLTP classiques et plusieurs fois celles des principaux moteurs analytiques. En s’appuyant sur une alliance stratégique avec Exasol, l’objectif est d’obtenir des insights immédiats sans avoir à déplacer les données vers d’autres systèmes, en privilégiant la consultation en place.

7) Performance, sécurité et gestion “enterprise”

• Performance : en benchmarks internes, MariaDB Enterprise Server 11.8 — cœur de la plateforme — affiche une progression de +250 % face à la version 10.6.
• Gestion / observabilité : MariaDB Enterprise Manager centralise topologies, métriques et offre un IDE visuel pour requêtes et schémas.
• Sécurité : MaxScale intègre un firewall de base de données amélioré, avec des règles programmables pour contrôler chaque requête utilisateur et réduire la surface d’attaque.

Pourquoi combiner OLTP, OLAP et vecteurs dans une même “boîte” ?

De nombreuses équipes ont constaté que la perte de temps entre journaux de transactions, ETL, data lake, vector store et service RAG est souvent ce qui fait échouer le produit : latences, coûts croissants et orchestration fastidieuse. La vision de MariaDB ? Fusionner tout ce flux : si le données naît dans la même plateforme qu’elle l’analyse, vectorise, récupère pour un LLM et agit (transation), alors on simplifie et on accélère.

Est-ce toujours préférable d’avoir “une seule base” ? Pas toujours. Pour des charges analytiques à haute échelle ou pour des organisations avec des standards bien rodés (comme des data warehouses spécifiques), la stratégie hub-and-spoke reste pertinente. Mais pour les applications où la proximité entre données transactionnelles, sémantique et action crée la valeur, l’unification minimise frictions et risques de dérive.

Ce que cela apporte aux développeurs et aux DBA (et quels risques)

Pour les développeurs, le bénéfice est tangible :

• Moins d’SDK et moins d’attente : un seul point d’accès, avec Text-to-SQL pour explorer et RAG sans avoir à assembler diverses pipelines.
• Une latence moindre entre données et réponses : les agents récupèrent le contexte et agissent dans un même espace.
• Plus de concentration sur la logique et l’expérience utilisateur.

Pour les DBAs, deux messages essentiels :

• Un copilote pour les tâches récurrentes (optimisation, debug, analyse de requêtes), via un Enterprise Manager qui centralise observabilité et opérations.
• Plus de superficie à surveiller : OLTP + OLAP + vecteurs + agents dans une même plateforme exige des restrictions en sécurité, contrôle d’accès granulaire, gouvernance des données et tests de résilience (failures partielles, isolation, quotas).

Les risques à anticiper :

• Gouvernance : si tout est regroupé, la segmentation (schémas, rôles, espaces de travail) et la sécurité par défaut sont vitales.
• Coûts imprévisibles en mode serverless si aucune limite ou alerte n’est définie (car les agents restent actifs en permanence).
• Fermeture de l’écosystème : augmentant l’usage de capacités natives et propriétaires, il faut prévoir stratégies de portabilité pour éviter l’enlisement.

Quels cas d’usage sont les plus adaptés ?

• Applications d’affaires intégrant l’IA : CRM/ERP avec assistants capables de lire, raisonner et exécuter (passer commande, ajuster un crédit, lancer une tâche).
• Soutien client et agents virtuels : RAG avec contexte opérationnel en temps réel, sans synchronisations compliquées.
• Analytique opérationnelle et insights immédiats : dashboards et décisions avec Exa directement sur données vivantes.
• Automatisation intelligente : agents qui initient des bases serverless, déplacent des données selon des règles prédéfinies et documentent leurs actions.

Disponibilité et feuille de route

La version de MariaDB Enterprise Platform 2026 est disponible immédiatement pour les clients. Les améliorations de MariaDB Cloud seront déployées à partir du 1er novembre 2025. La société encourage à tester cette plateforme dans le cloud et à participer aux webinaires de présentation.

Que doivent faire aujourd’hui les organisations intéressées ?

1. Pilote contrôlé : choisir un cas d’usage où RAG + transac apportent une valeur (ex : assistant interne avec autonomie limitée).
2. Modèle de sécurité : définir rôles, limites et traçabilité des actions des copilotes et agents (qui peut faire quoi jusqu’où).
3. Observabilité et coûts : activer des métriques fines (latence, caches, vector recall) et instaurer des limitations pour le budget cloud.
4. Plan de portabilité : encapsuler la logique des agents (MCP, SDKs) pour limiter l’enfermement et garder des options ouvertes.

Une étape vers une IA “praticable” en production

Ce qui rend MariaDB 2026 intéressant, c’est sa composition : vecteurs, RAG, copilotes, MCP et serverless coordonnés avec OLTP/OLAP. Pas une solution miracle, mais un coup de pouce pour que les équipes passent d’ démos à des services opérationnels sans jongler entre cinq outils distincts. Le temps dira si la promesse — moins d’éléments, plus de résultats — tient à grande échelle. Pour l’instant, la trajectoire est claire : rapprocher l’intelligence du donnée et de l’action.

Questions fréquentes

Qu’est-ce que “RAG-in-a-Box” et en quoi diffère-t-il d’un RAG traditionnel ?
Il s’agit de l’implémentation native de RAG dans MariaDB : la plateforme automatise toutes les étapes (segmentation, index vectoriel, récupération et mise en correspondance avec LLM) sans que l’équipe ait besoin de créer ou gérer des pipelines externes ou bases vectorielles. Le but ? réduire latence et complexité.

À quoi servent les copilotes intégrés ?
Deux usages principaux : un copilote développeur (Text-to-SQL), qui répond en langage naturel avec des requêtes et insights, et un copilote DBA qui aide en performance, diagnostic et opérations. Ils résident dans MariaDB Cloud et respectent la sécurité et l’audit.

Quelle est la fonction des Model Context Protocol (MCP) Servers ?
Ils jouent le rôle d’un pont standardisé : ils permettent aux agents d’interagir avec MariaDB et autres systèmes, en exécutant des opérations avancées. Outre la recherche vectorielle, ils orchestrent aussi le lancement de bases serverless et coordonnent les copilotes pour une automatisation à grande échelle.

Quel apport en matière de performance et d’analytique avec MariaDB Exa ?
Exa cible une analytique complexe sur de données multi-TB, avec des vitesses annoncées >1000× supérieures aux moteurs OLTP classiques et plusieurs fois celles des principaux moteurs analytiques. Son objectif est de fournir des insights immédiats sans délocaliser les données, en favorisant la consultation in place.

Sources : annonce officielle de MariaDB Enterprise Platform 2026 (fusions OLTP/OLAP/vecteurs, RAG-in-a-Box, copilotes, MCP Servers, serverless dans MariaDB Cloud, MariaDB Exa, partenariat avec Exasol, améliorations sécurité et gestion, performances du MariaDB Enterprise Server 11.8).**

vía : mariadb