Summary

• MariaDB Enterprise Platform 2027 combines operational databases, real-time analytics, vector search, agent memory, and caching.
• A MariaDB-sponsored benchmark reports 56% higher peak throughput for Enterprise Server 12.3 than version 11.8 under specified test conditions.
• The core platform is generally available, but MariaDB's public materials disagree about the start of AI Retrieval's public preview.

Database company MariaDB has launched an enterprise data platform intended to support conventional applications and artificial intelligence agents using the same operational information, extending its database products into analytics, retrieval, memory, and distributed processing.

MariaDB Enterprise Platform 2027 became generally available on 4 November, combining Enterprise Server 12.3 with analytical, in-memory, management, and deployment components. The company has also introduced additional AI tools and clustering capabilities, alongside a new corporate identity intended to reflect its broader product range.

The release includes a reported 56% increase in peak transaction throughput compared with the previous major server version, based on a sponsored benchmark conducted by McKnight Consulting Group. MariaDB separately reports an improvement of up to 30% in native vector-search throughput under its comparative test conditions.

The platform is designed for businesses introducing AI agents into established applications, where operational records may be distributed across transactional databases, analytical systems, caches, and document stores. Combining some of those functions could reduce integration work, although the costs and reliability of running additional workloads together will vary between deployments.

AI agents need current operational records

Conventional enterprise software commonly uses transactional databases to maintain business records, including orders, account balances, inventory, customer information, and payments. Analytical systems may receive copies of that information to support reporting and investigation without placing additional demands on the operational database.

AI applications can introduce further layers. A language model may rely on document retrieval, vector search, persistent memory, and external tools to assemble an answer or carry out an authorised task.

Where the underlying records are copied between several systems, the information returned to an AI application may not reflect the latest operational changes. An item could already have been sold, an account amended, or an order cancelled before the associated analytical or search system receives an update.

MariaDB’s strategy is to make more of these workloads available through a unified platform. Enterprise Server maintains transactional processing, while MariaDB Exa provides analytics against live operational data and GridGain contributes in-memory capabilities.

Native vector search also allows applications to compare numerical representations of information without necessarily operating a separate vector database. These representations can support searches for documents, records, or other material that is semantically related to a user’s request.

The company reports that Enterprise Server 12.3 delivers up to 30% more vector queries per second than version 11.8 at the same accuracy in its tests. Actual results will depend on data volumes, indexes, query patterns, hardware, and the configuration of an individual application.

A common platform may simplify administration, but it does not remove the need to establish reliable data permissions or appropriate separation between demanding workloads. Analytical queries and automated retrieval can compete with transactional operations for processing and memory resources if capacity is not managed properly.

Agent memory introduces new operational questions

MariaDB has introduced Agent Memory to provide persistent state across interactions and sessions. An AI agent performing work over an extended period may need to retain its progress, recover from interruptions, and resume after a person approves a particular step.

Maintaining that information outside the language model can make a workflow more predictable, particularly where the underlying application needs to recover after failures or continue work across separate sessions.

Semantic Cache addresses a different problem by storing answers that can be reused when a new question has substantially the same meaning as one previously processed. Avoiding unnecessary model calls could reduce latency and token expenditure where applications handle repeated requests.

However, reusing an earlier answer creates a risk when the underlying information has changed. A cached response about inventory, pricing, or customer records may no longer be accurate, even when the new question resembles the previous one.

Applications therefore need rules governing cache expiry, data changes, and permissions. A response generated for one employee should not become visible to another person simply because both ask similar questions.

MariaDB AI Retrieval is designed to combine documents and live operational data, including natural-language requests translated into read-only SQL. Restricting the generated queries to reading information provides a boundary between retrieving data and authorising changes to it.

Its public availability requires clarification. MariaDB’s 4 November release schedules the AI Retrieval public preview for later in the month, while a company blog published on the same day describes the preview as already available on MariaDB Cloud. Organisations planning immediate evaluations will need the company to confirm the applicable service status.

Developer integrations are also being expanded through AI plugins for coding assistants including Claude Code and Codex. These tools may help generate database queries and application code, but the resulting work still needs testing, security review, and validation against operational requirements.

Benchmarks show potential rather than universal gains

The headline 56% throughput improvement comes from testing of MariaDB Enterprise Server 12.3.3-0 against version 11.8.3-1 on Google Cloud, using HammerDB’s TPROC-C workload.

McKnight Consulting Group performed the tests, but MariaDB sponsored the research. TPROC-C is derived from the TPC-C transaction-processing benchmark and does not constitute an official TPC-C result.

The figures demonstrate the performance observed under the published configuration rather than establishing a guaranteed improvement across existing customer systems. Transaction throughput depends on query design, indexing, memory, concurrency, infrastructure, and the proportion of work allocated to different applications.

An organisation running a database that is already constrained by storage performance or poorly optimised queries may not achieve the same results. Likewise, adding analytical and AI workloads changes the pattern of demand placed on the infrastructure.

The release also introduces Raft-based clustering and conflict detection and resolution intended to support availability across multiple regions. Raft clustering coordinates agreement between participating nodes, while separate conflict-management mechanisms address situations where data is updated in more than one location.

Such arrangements can improve resilience and support geographically distributed services, but they do not remove every trade-off between performance, consistency, complexity, and recovery behaviour. Customers still need to decide how an application should behave when communications fail or simultaneous changes cannot be reconciled automatically.

Control extends beyond where data is stored

MariaDB’s Bring Your Own Cloud option allows customers to retain the data plane within their own AWS, Microsoft Azure, or Google Cloud accounts while MariaDB operates the database service. The arrangement may appeal to businesses seeking greater control over infrastructure and information handling.

The platform also offers role-based access controls across its workloads. These controls can help maintain consistent permissions, although businesses still need to assess which identities can retrieve information and what actions an automated application is allowed to perform.

For regulated organisations, MariaDB describes support for FIPS 140-3 requirements through its Kubernetes Operator and validated cryptographic modules. That should not be read as proof that every MariaDB deployment, or the entire platform in every configuration, has independently obtained the same certification.

Rohit de Souza, chief executive of MariaDB, described the difficulty of integrating additional infrastructure into enterprise systems: “Every system you bolt on for AI adds another seam, and seams break.”

Reducing the number of independent components could simplify some operations, but it may also concentrate more responsibility within a single supplier and technology environment. Procurement decisions will therefore depend on workload performance, resilience, support arrangements, portability, and the cost of operating the combined system.

Enterprise Platform 2027 is available for deployment on premises, through cloud infrastructure, and as a managed service. Its longer-term commercial performance will depend on whether customers can introduce agent memory, retrieval, and analytics alongside existing transactional applications without weakening the reliability of the systems on which their businesses already depend.