MariaDB launches ai-ready Enterprise Platform with 56 percent higher throughput. - Content Director Published: Nov 3, 2026 Summarize with AI MariaDB has unveiled Enterprise Platform 2027, combining artificial intelligence capabilities, real-time analytics and improved database performance to help businesses deploy AI agents. The launch also introduces a new brand identity reflecting the company's evolution beyond traditional database technology. MariaDB Targets the Agentic Enterprise MariaDB has launched Enterprise Platform 2027, introducing new artificial intelligence (AI) capabilities and improved database performance designed to support businesses adopting autonomous AI agents. The platform delivers 56 percent higher peak throughput compared with the previous major release, alongside enhanced resilience for multi-region deployments and new tools for developing and managing AI applications. The announcement marks a shift in MariaDB's positioning from an open-source database provider towards a unified enterprise data platform supporting transactions, analytics and AI workloads. Rohit de Souza, CEO of MariaDB, said businesses need reliable data infrastructure to support increasingly complex AI applications. "The AI race won't be won by the smartest model. It will be won by the companies that unify the infrastructure underneath their agents," said de Souza. "Every system you bolt on for AI adds another seam, and seams break. Agents need a durable foundation that doesn't shift underneath them, so you can trace every action they take." Accelerating AI development and performance. Enterprise Platform 2027 introduces several capabilities designed to simplify the development and operation of AI agents. Its AI Retrieval service connects agents with documents and live operational data, enabling natural-language questions to be converted into read-only Structured Query Language (SQL) queries. AI plugins also integrate MariaDB expertise into coding agents, including Claude Code and Codex, supporting developers working with database applications. Meanwhile, Agent Memory provides persistent, in-memory storage across sessions, allowing AI agents to retain information during longer-running tasks. A Semantic Cache capability can return previously stored answers to similar questions, helping reduce response times and AI token consumption. The platform also incorporates native vector search, which MariaDB says delivers up to 30 percent more queries per second than the previous major release. Unified data platform reduces complexity. A central focus of the launch is reducing the complexity associated with enterprise data infrastructure. MariaDB argues that businesses frequently rely on separate operational databases, data warehouses, vector stores and caching systems to support AI applications. Connecting these technologies can introduce latency, synchronisation delays and additional points of failure. Enterprise Platform 2027 brings together transactional processing, real-time analytics and AI capabilities within a unified environment. Its MariaDB Exa technology enables real-time analytics using live operational data without requiring complex data pipelines. "Most enterprises will not rebuild their data infrastructure to adopt agents. They will add agents to the systems that already run the business, which makes the transactional core and its ability to serve analytics, retrieval, and memory from the same live data the practical starting point for agentic workloads." Strengthening enterprise resilience and security. Alongside its AI capabilities, MariaDB has introduced performance and resilience improvements for businesses operating across multiple regions. The platform's 56 percent increase in peak throughput was recorded in third-party testing against the previous major release. Raft clustering and conflict detection and resolution capabilities are designed to support more resilient multi-region deployments. A unified role-based access control system also provides security management across different workloads. For organisations with specific data sovereignty or regulatory requirements, MariaDB offers Bring Your Own Cloud deployment options and Federal Information Processing Standards (FIPS) 140-3 capabilities. The platform can operate on premises, across cloud environments or through MariaDB's managed cloud service. MariaDB unveils new brand identity. The technology launch coincides with a company-wide rebrand, reflecting MariaDB's expansion beyond its traditional database offering. Developed alongside two years of strategic investment and engineering, the new identity includes a redesigned logo, updated visual system and refreshed website. Tracy Strauss, Chief Marketing Officer at MariaDB, said the rebrand reflects the company's changing role in enterprise technology. "Our new identity shows a company that is open by design, unified across every workload and built for the agentic enterprise. It is bright and confident on purpose, because that is the company we have become." Platform available to enterprise customers. MariaDB Enterprise Platform 2027 is now generally available, incorporating Enterprise Server 12.3, MariaDB Exa, MariaDB GridGain, MariaDB MaxScale, Enterprise Manager and the Enterprise Kubernetes Operator. MariaDB AI Retrieval is scheduled to enter public preview on MariaDB Cloud later in November 2026. This article was produced by the editorial team at EME Outlook and published as part of the Outlook Publishing global network of B2B industry magazines. Outlook Publishing delivers industry insights, company stories, and sector coverage across manufacturing, mining, construction, healthcare, supply chains, food production, and sustainability. EME Outlook provides ongoing coverage of organisations and developments shaping industries across Europe and the Middle East. Add to your Preferred Sources CREDIT: MariaDB Content Director Neil Perry is Content Director for Outlook Publishing. Add to your Preferred Sources Issue 73 out now.

Critical MariaDB flaws can let attackers execute code and steal database data. October 13, 2026 MariaDB has disclosed security flaws that, under specific conditions, could let attackers run code, access restricted database tables, and steal login credentials. Security updates notification The issues affect several server branches and MariaDB Connector/C. Although the headline describes a critical risk, the vendor rates the main code execution flaws as High, not Critical. Exploitation depends on installed plugins, account permissions, or unsafe settings. Discover more Compare Security The leading concern is CVE-2026-107815, a memory corruption flaw in the CONNECT storage engine. MariaDB assigns it a CVSS score of 8.5 and says researchers demonstrated remote code execution in laboratory conditions. The advisory describes a network attack requiring low privileges, high attack complexity, and no user interaction. It does not report confirmed attacks against live systems. The CONNECT flaw affects how it handles its DOS table. A faulty boundary check allows an attacker to write one zero byte beyond a stack buffer at an attacker-controlled position. Even this small write can corrupt memory in a way that supports code execution, as the laboratory test showed. MariaDB recommends removing the CONNECT engine plugin when you don't need it. Critical MariaDB vulnerability. A second issue, CVE-2026-107821, affects checks on binary .frm files that MariaDB reads when opening tables. Specially crafted files can cause crashes, out-of-bounds reads or writes, and potentially remote code execution. The official MariaDB advisory rates this vulnerability High with a CVSS score of 8.0. Vulnerability assessment tool That attack has important limits. Placing a malicious file in the database directory requires the FILE privilege and a secure-file-priv setting that permits access there. MariaDB says properly configured servers block file-level access to this directory and grant FILE sparingly. These requirements make it misleading to describe the flaw as an unrestricted attack against every exposed server. The separate CVE-2026-102523 vulnerability could allow attackers to read or change tables outside their normal permissions. MariaDB failed to encode partition names safely for filesystem use during ALTER TABLE... CONVERT... PARTITION operations. Its partition security advisory gives the issue a CVSS score of 8.0. It lists low privileges and user interaction as attack requirements. Connector/C also needs attention. CVE-2026-107819 affects libmariadb versions 3.4.1 through 3.4.9. An attacker positioned between client and server could present a valid certificate for the wrong host and request cleartext password authentication. Discover more Cybersecurity news subscription Cyberattack prevention service Security updates notification A programming mistake could allow the client to send its password over that unverified connection. Other MariaDB connectors are not affected. The risks extend beyond server code alone. Cybersecuritynews previously covered a cPanel database privilege flaw involving MySQL and MariaDB access, along with a PostgreSQL tool injection flaw that could enable code execution. Those separate reports provide useful context on how database permissions and supporting tools can widen an attack's impact. The CONNECT and binary .frm flaws affect MariaDB 10.6.1-10.6.27, 10.11.1-10.11.18, 11.4.1-11.4.12, 11.8.1-11.8.8, 12.3.1-12.3.2, and 13.0.1. Fixes are available in 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3, and 13.0.2. The partition flaw does not list the 10.6 branch as affected. Administrators should upgrade affected server branches and update Connector/C to 3.4.10. While preparing updates, remove unused CONNECT plugins and review FILE permissions and database-directory access. MariaDB also offers disabling partition support as a workaround for the partition flaw. Apply that measure only after checking whether existing databases depend on partitioned tables. Update defenses against new malware as soon as it appears. Integrate TI Feeds with data from 16K SOCs. Abi is a Security Editor and fellow reporter with Cyber Security News. She is covering various cyber security incidents happening in the Cyber Space. 0-Hour Cyber Security Alerts! Get the latest Cyber security News sent directly to your inbox. Discover more Compare Browsers Ethical hacking course Malware removal software Discover more Crowdstrike Falcon platform Vulnerability assessment tool Audit Security

How to choose the best database for an AI app. You've built something with an AI model, and now it needs access to your data. So where should that data live? Do you add a dedicated vector database, or use the one that already houses your documents, product details, and past conversations? Picking wrong won't necessarily break anything right away. But it might show up later. Either a second system to maintain, data that drifts out of sync, or a search feature that never quite performs the way you expected. This guide, written for app developers, walks through how to make that choice early, without getting lost in jargon. * AI apps need a database that can store content and search it by meaning (vector search), not just by exact keywords. * A second, dedicated vector database adds complexity: another system to pay for, secure, back up, and keep in sync. * For most projects, especially smaller ones, a general-purpose database that also supports vector search is enough. * MariaDB added vector search starting in version 11.8, so many teams can skip the second database entirely. * A dedicated system still makes sense for very large or fast-growing content, heavy search traffic, or when search is the entire product. An AI app usually asks three things of its database: It has to store the content, whether that's documents, product details, support tickets, or whatever the app should answer from. It has to search by meaning, known as vector search, where the app turns text into vectors, lists of numbers that represent meaning, so it can find the closest matches even when the exact words differ. And it still has to handle everything else: accounts, permissions, settings, and logs, the regular work any app's database does. You'll come across two setups. A dedicated vector database is a system built specifically for storing vectors and searching them. A general-purpose database, the kind that holds your accounts, orders, and settings, can also offer vector search as one of its features. The rest of this guide covers which one fits your project. Four questions to ask before you decide. * How much content are you searching? A help center or product catalog is a different problem than millions of documents. * Is search the whole product, or one feature of it? A chatbot that also handles accounts and billing has different needs than a tool built entirely around search. * How many searches happen at once? Occasional lookups and constant, simultaneous queries put very different demands on a database. * Who's going to run it? A second database needs someone to set it up, monitor it, and keep it secure. Your answers to these four questions point toward one of the two paths below. Why vector search is important. Picture a support chatbot for your product. A customer types "my invoice looks wrong." But your help article is titled "Resolving billing discrepancies." Because the word "invoice" doesn't appear in the article, a plain keyword search may find nothing. AI apps get around this with vector search. Similar meanings produce similar vectors, so the question and the billing article end up close together. The app finds the closest matches and passes that text to the AI model, which writes the answer. Your database has to store the content, run that search, and keep handling regular app data like accounts and permissions. One database is often enough. Vector search sounds like it needs its own database. It often doesn't, and a second database has costs that are easy to overlook. It has to be set up, secured, backed up, and kept running. Your team has another tool to learn. And your content now lives in two places, so every change has to be copied across, or the AI app can answer from outdated information. Say you're running a product's help center. A few thousand articles, moderate traffic, one small team. Adding a dedicated vector database here means a second system to secure and back up, just to search a collection that a regular database can handle without strain. Or you're building an internal tool that answers questions from a set of company documents. The content changes slowly, a handful of people use it, and the searches themselves are infrequent. A dedicated system would sit mostly idle while still needing someone to maintain it. How MariaDB handles vector search. So can your regular database also do vector search? If it's MariaDB, on recent versions the answer is yes. Vector support became generally available in version 11.8, the first long-term support release to include it. You keep the vectors your AI model produces in a regular table, alongside the rest of your data. When your app runs a search, MariaDB compares the new vector to the ones already stored and returns the closest matches, the same idea as the invoice example earlier, just running inside the database you already have. A vector index speeds up that comparison by returning approximate closest matches instead of checking every stored vector one by one, and MariaDB supports reads and writes happening at the same time, so your app can keep adding new content while people are searching. You'll find MariaDB 11.8 in the Kamatera marketplace, vector search included. When a dedicated vector database makes sense. One cloud database isn't the right answer for every project. A dedicated vector database earns its place when several of these apply: Is your content very large or growing fast? A huge or fast-growing collection can strain a database built for general use, especially alongside all its other work. Is search the product itself, not just a feature? If AI search is what customers pay for, its speed and quality justify dedicated tooling built around that one job. Is search traffic heavy? Many searches happening at once can compete with the rest of your app for the same resources, slowing both down. Does your current database actually lack the features you need? Check what it supports before assuming it falls short. Many general-purpose databases cover more than expected. Do you have people to run it? A second system needs someone to set it up, monitor it, and keep it secure. Without that, it becomes a liability rather than an advantage. If you answered yes to several of these, test a dedicated system against your current database using your own data. Closing thoughts. Most AI apps, especially early on, are better served by keeping things in one place, and adding complexity only when the project actually needs it. If that changes later, a dedicated system is still there to add. Starting simple costs you far less than starting with a system you didn't need.