Key takeaways
- Accelerated AI Development & Execution: MariaDB Enterprise Platform 2027 delivers built-in AI Acceleration capabilities that enable teams to build and deploy high-performance AI agents faster while significantly reducing large language model (LLM) operational costs and latency.
- Unified Hybrid Search & Retrieval: AI Retrieval unifies Document RAG and Text-to-SQL workflows through a single managed service and API layer, querying operational relational data, JSON documents, and vector embeddings in real time without external data synchronization.
- Optimized Context Management & Caching: Agent Memory maintains long-running multi-agent workflows outside the prompt window to prevent context rot, while Semantic Cache cuts duplicate LLM calls by up to 86% while using sub-millisecond vector lookups in MariaDB GridGain.
- Distributed Scalability & Developer Tooling: Distributed Vector Search horizontally scales similarity search across in-memory clusters, while open-source AI Plugins (including a new MCP server for MariaDB Server) automate schema generation, query testing, and MySQL migrations to MariaDB.
Almost every application we use today, from the banking app on our phones to the order screen at the coffee shop, was built on a simple bargain with the database underneath it: a developer wrote the queries ahead of time, someone tuned them, and the same handful ran request after request. That bargain is starting to change, because a new kind of user is showing up at the database, one that writes its own queries at runtime, branches on every result, and rarely travels alone.
Enter the AI agent.
Today (November 3), we announced MariaDB Enterprise Platform 2027, and in preview in the release is AI Acceleration, a set of capabilities built into the platform so that agents are faster to build and faster to run. Let’s walk through why AI sits at the center of our strategy and what each new capability solves.
Why AI Sits at the Center
I would argue the database has always been where trust lives in an enterprise (the customer record, the order, the account balance), and an agent is only as useful as the data it can reach. With this release, we are enabling agents to work directly on the data that already runs the business, with relational rows, JSON documents and vectors (numeric representations of meaning, also called embeddings) living together in one place, alongside the retrieval, memory and speed agents need to run in production.
What has changed is who is asking. An application is a regular at a restaurant with a fixed menu, so the kitchen can prep ahead, while an agent orders off-menu, one dish at a time, some ready in seconds and others tying up the kitchen for an hour, and brings dozens of friends who do the same.
Applications vs. agents · fixed menu vs. off-menu
What we consistently hear from enterprise teams is some version of the same story: the pilot worked, and then production meant stitching together a separate vector store, a cache, a retrieval pipeline and a second security model. Teams are asking for fewer moving parts, answers grounded in live data and a real handle on AI cost, and nearly every capability in this release traces back to one of those asks.
Two Kinds of Context
My current thinking is that what agents need from a data layer comes down to one word, context, and context comes in two kinds:
- Business context: this is what the agent knows, meaning live, persistent data such as customers and orders, which needs transactions and lives in MariaDB Server, our system of record.
- Working context: this is what the agent remembers, meaning its memory, checkpoints and reusable answers, which is short-lived, grows with the number of agents, and lives in MariaDB GridGain, a distributed in-memory key-value and vector store.
Two Kinds of Context · business context vs. working context
Keeping the two apart means a burst of agent traffic cannot slow down the checkout page, and a team can add agent capacity without scaling the system of record. To be fair to the alternative, a single database is simpler to reason about, and for a handful of agents it may be all a team needs.
AI Retrieval
Priya, a support representative at a financial services company, asks her internal assistant:
Priya: “What’s the current account status for this customer, and what have they complained about recently?”
The first half lives in the operational database, the second in support ticket history, and today answering both usually means two pipelines to develop and maintain: document RAG (Retrieval-Augmented Generation, where relevant text is fetched and handed to the model) and Text-to-SQL (turning a plain-language question into a database query), often running against a copy of the data.
The Text-to-SQL half hides most of the work. A question only becomes correct SQL if the system knows what the database means, which requires a semantic map (a plain-language guide to what each table and column represents, for example that a column named acct_st holding the value 3 means the account is on hold), and in most enterprises that knowledge lives in people’s heads rather than in the schema.
MariaDB AI Retrieval is a managed service that handles both halves through one set of APIs (Application Programming Interfaces). It builds the semantic map automatically from the live database, runs validated, read-only SQL, and handles document parsing, chunking and embeddings, with MariaDB serving as both the operational database and the vector store, so there is no copy to keep in sync.
AI Retrieval · today DIY vs. with one service
The do-it-yourself route still has its place, since a team with deep retrieval expertise and very specific needs may prefer to own every piece of the pipeline, but it requires a lot of time and effort to develop and maintain.
Agent Memory
Long-running agents forget, and the longer they run, the worse it gets. As an agent’s context window (the text a model can hold in view at once) fills up, two problems creep in. The first is context rot: a model’s accuracy degrades as its input grows, even on simple tasks. A 2025 Chroma study observed this across the 18 models it tested [1], and in practice the agent starts dropping subgoals and repeating tool calls. The second is cost, since most model providers bill for every token sent, and an agent typically resends its growing context on every step, so each call costs more than the last. Every handoff to another agent tends to start from scratch, too.
Picture an Audit Agent working through more than 50 tool calls across SEC (Securities and Exchange Commission) filings before handing off to a Risk Agent. With MariaDB Agent Memory, the Audit Agent checkpoints its progress at every step and keeps extracted figures in GridGain rather than in its context window, and the Risk Agent picks up the verified results from shared memory without redoing the Audit Agent’s work, reading a compact set of findings rather than hundreds of raw filings.
Agent Memory · what it does and why it matters
Agent Memory offers sub-millisecond reads, expiry settings so old state ages out on its own, and integrations with LangChain and LangGraph (popular frameworks for building agents).
Semantic Cache
To an LLM (large language model), “How do I reset my password?” and “I forgot my password, what now?” are two separate questions, which means two charges and two waits. Semantic Cache recognizes that a new question means the same thing as one already answered, even in different words, and returns the stored answer from MariaDB GridGain with no LLM call and a far shorter wait (a quick embedding step plus a sub-millisecond lookup, vs. a multi-second model call).
Semantic Cache · without vs. with the cache
Public research is encouraging on the cost savings of semantic caches. An AWS study of 63,796 real chatbot queries reported up to 86% lower LLM cost and up to 88% lower average latency at a 0.75 similarity threshold, with 91% of cached answers judged accurate [2], and a paper by Regmi and Pun saw up to 68.8% fewer LLM API calls [3]. Both tested other products, so I would treat them as a guide to what is possible.
The tradeoff lives in the matching threshold (how similar two questions must be to count as the same). Stricter matching saves less, and at a 0.9 threshold the AWS study saw 72.5% savings [2], while looser matching risks answering a question that only looks similar. Questions that repeat across many users and have stable answers are good candidates (FAQs, product and policy questions, how-to and troubleshooting steps, internal knowledge-base lookups). Questions tied to one person or one moment are poor ones (account-specific requests, real-time data such as prices or order status, one-off analysis of unique inputs, and anything involving sensitive personal data).
Distributed Vector Search
Agent Memory and Semantic Cache both depend on similarity search (finding the stored items closest in meaning to a new one), and at agent scale a single node eventually runs out of room. MariaDB GridGain 8.10 distributes HNSW-based vector search across a partitioned, in-memory cluster: a query fans out to every node, each node searches its own share, and the best matches are merged and returned. Adding a node adds both memory and search capacity, and expiry rules age out stale memories and cached answers, so the cluster’s memory holds only what agents still need. For existing GridGain users, this means vector search now scales the same way the rest of their cluster already does, so as agents multiply and memory grows, they add nodes rather than bolt on a separate vector database. Vectors live in memory right next to the key-value data those users already run, with one cluster to operate and one security model to manage.
Distributed Vector Search · one query across every node
AI Plugins
AI coding tools tend to treat MariaDB as a simple MySQL fork and miss features such as the native UUID (Universally Unique Identifier) data type, so developers end up fixing the output by hand. When Dana, a backend developer, asks her coding agent to design a notes-app schema with UUID keys and test it, MariaDB AI Plugins give the agent two things in one install: skills (MariaDB-specific guidance it reads when relevant) and a connection to the new MCP server for MariaDB Server, built into MariaDB Shell (MCP is the Model Context Protocol, an open standard for connecting AI tools to data).
AI Plugins · coding agent without vs. with the plugins
The MCP server is the piece that turns MariaDB guidance into action. It gives the agent a live connection to a MariaDB server, so it can read the schema, run queries, analyze a slow query with EXPLAIN, version schema changes or start a throwaway test instance. It runs as a native plugin inside MariaDB Shell, which installs automatically the first time the agent starts the server and keeps database credentials in its own secure store. Teams that only want the guidance can use the skills on their own, with no database connection at all [4].
The plugins also help teams moving from MySQL. A developer can ask the agent what would change if the application moved to MariaDB, and the agent reviews the schema and queries against MariaDB-specific compatibility guidance. With the optional migration tooling, the agent then plans the migration (validating each step without changing anything), runs it, resumes from where it stopped if a run fails, and verifies the result on the target by checking object counts, foreign keys, row counts, sample values and logins for each migrated account. Teams can rehearse the whole migration in a sandbox first [4].
Security is top of mind from the start. The agent can only reach the databases and folders a developer has approved, plus its own sandbox. Inside a database, it can only do what its MariaDB account allows, and passwords are never stored where the agent can read them. The plugins are open source and work today in Claude Code, OpenAI Codex, OpenCode, Pi and Hermes Agent [4]. Their sandbox defaults favor convenience on a developer laptop, and the plugins do not replace code review, but they make the agent’s first draft far more likely to be right.
What’s Next
You can try AI Retrieval in MariaDB Cloud, and Agent Memory, Semantic Cache and Distributed Vector Search in MariaDB GridGain 8.10. The AI Plugins, including the MCP server for MariaDB Server, are available to download from GitHub (github.com/mariadb-corporation/ai-plugins), and the MySQL migration tools are available from the MariaDB downloads page (mariadb.com/downloads/community/migration-tools).
In the coming weeks, you will see posts on AI that will dive into new capabilities offered by MariaDB. Most importantly, we want to hear from the people putting agents into production, since that feedback shaped this release and will shape the next one.
Please let me know if you have any questions or have thoughts on the above. I look forward to discussing!
References
[1] Kelly Hong, Anton Troynikov and Jeff Huber, Context Rot: How Increasing Input Tokens Impacts LLM Performance, Chroma Technical Report (July 2025).
[2] AWS Database Blog, Lower cost and latency for AI using Amazon ElastiCache as a semantic cache with Amazon Bedrock (November 2025).
[3] Sajal Regmi and Chetan Phakami Pun, GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching, arXiv (2024).
[4] MariaDB documentation, MariaDB AI Plugins.
MariaDB Enterprise Platform 2027 is an enterprise database platform designed to support transactional, analytical, and AI agent workloads. It integrates relational data, JSON documents, and vector embeddings into a unified system with features like AI Retrieval, Agent Memory, Semantic Cache, and Distributed Vector Search.
MariaDB AI Retrieval acts as a managed service with a single API layer that automatically creates semantic maps for operational database tables while handling document parsing, chunking, and vector embedding generation. This enables queries across live relational data and unstructured documents without needing separate data sync pipelines.
Semantic Cache uses vector similarity search in MariaDB GridGain to match reworded or repeated queries with previously generated responses. By returning cached answers in sub-milliseconds without triggering new LLM calls, it can reduce LLM API calls by up to 86% and lower average latency.
Agent Memory offloads intermediate agent execution states, tool call outputs, and checkpoints from the LLM prompt window into MariaDB GridGain. Keeping context concise prevents context rot (accuracy degradation in large context windows) and reduces per-step LLM token billing across long-running or multi-agent workflows.
MariaDB AI Plugins equip AI coding assistants (such as Claude Code and OpenAI Codex) with MariaDB-specific database knowledge and Model Context Protocol (MCP) server integration. This allows agents to safely connect to local database instances, analyze execution plans, version schemas, and automate migrations from MySQL.
