MariaDB 11.8 LTS Vector Search Is GA; Semantic Kernel Lacks Connector

MariaDB Vector Is Shipping Software, and Coding Assistants Still Skip It​

The capability behind Arnö's complaint is not new and not a preview. MariaDB's server documentation says MariaDB Vector was introduced in MariaDB Community Server 11.7, a rolling release, and is generally available from MariaDB Community Server 11.8 onwards, the first long-term support (LTS) release to include it. Commercial customers got it earlier on an older branch: in MariaDB Enterprise Server, vector search was backported to the 11.4 release series and is available from MariaDB Enterprise Server 11.4.5-3 onwards. It is also included in MariaDB Enterprise Server 11.8, which is generally available from 11.8.3-1 onwards.

The Foundation's release post called 11.8 the yearly long term support release for 2025. It's the first LTS with support for MariaDB Vector. Independent coverage at the time, including Linuxiac, described MariaDB Vector as the release's headline feature. Vector search lets an application find items by similarity instead of exact matches, which is a common requirement in AI applications. Retrieval-augmented generation (RAG), semantic search and recommendations all depend on it.

Arnö's frustration, as The Register reports it, is blunt: "We're so frustrated that the world doesn't understand that MariaDB has vectors." He described how new projects actually pick a vector store: "People start using vector databases based on some framework or based on some default choices of the LLM." He then described the outcome he wants to change: a developer who is vibecoding and presses enter on whatever Claude Code proposes "will not end up using MariaDB for your vector search."

The Register ran what it called a decidedly unscientific check. Asked which database to use for vector search, Claude suggested PostgreSQL first and did not mention MariaDB. Asked to compare MariaDB with PostgreSQL for the same job, it discussed MariaDB's capabilities in detail. That is one prompt, not a measurement of how often assistants leave MariaDB out. It still shows the pattern Arnö describes: the model had the knowledge but did not offer it unprompted.

Kaj Arnö Recasts SEO as LLM Optimization for Database Choice​

Arnö's framing borrows from the web. He compared the problem to the old days of improving a Google ranking, which he called "a mystical science" because nobody really knew how Google ordered its results. In his view, "the world has moved on" from search engine optimization to LLM optimization.

He gives several causes, and they are his explanations, not measured findings. Models may have been trained on data from before MariaDB shipped vectors. The documentation, tutorials and framework examples developers find elsewhere may still favour established alternatives. And early movers keep their lead. "If the water starts flowing in a certain direction, it will continue to flow in that direction," he told The Register.

That leaves a chicken-and-egg problem. Assistants learn from examples, discussions and code that real users produce. MariaDB's vector search needs more users to produce that material, and it needs the material to attract users. Arnö admits vendors could try to game recommendations, but he rejects that route. The only proper way to influence them, he said, is "by having it and by documenting it and by people using it."

MariaDB's documentation shows the Foundation working on this directly. The Vector Overview page points to a machine-readable documentation index (an llms.txt file) and offers each page as Markdown. It also links to "MariaDB skills for AI agents," a set of guidance files that includes a MariaDB Vector skill file with usage and tuning advice written for Claude Code and other agents. In practice, this is LLM optimization done through documentation: material formatted so an agent reading the docs gets MariaDB's vector syntax right.

What MariaDB 11.8 LTS Actually Puts in the Server​

Setting recommendations aside, here is what the feature does. The Foundation's project page describes storing embeddings in a VECTOR column next to your relational data and querying both — vector similarity and ordinary SQL filters — in a single transactional statement. Native VECTOR(N) data type and VECTOR INDEX index type (modified HNSW); up to 16,383 dimensions; euclidean and cosine distance. Full ACID transactions, concurrent reads and writes.

HNSW is a graph-based algorithm for approximate nearest neighbour search. It finds vectors close to a query quickly without comparing against every row, and gives up a little accuracy to do it. MariaDB's documentation says its implementation supports concurrent reads and writes and all transaction isolation levels. Vector columns store 32-bit IEEE 754 floating-point numbers.

MariaDB stores and searches embeddings but does not create them. The Foundation's FAQ says embeddings come from a model such as OpenAI, Llama, Claude, Gemini or an open model, run in the application tier. It also warns that embeddings from different models are not interchangeable, so a project should pick one embedding model and use it consistently.

The SQL surface is small:

• A VECTOR(N) column holds the embedding, where N matches the embedding model's output dimensions, such as 1,536 in the documentation's examples.
• A VECTOR INDEX is built for either Euclidean distance (the default) or cosine distance, with one vector index per table on a NOT NULL column.
• VEC_FromText() converts a JSON array of floats into a vector, and VEC_ToText() converts it back.
• VEC_DISTANCE_EUCLIDEAN() and VEC_DISTANCE_COSINE() calculate distances, and VEC_DISTANCE() picks whichever matches the index.

Linuxiac and the Foundation both report SIMD optimizations that leverage AVX2, AVX-512, ARM NEON, and IBM Power10 instructions to speed up distance calculations. The Foundation also says the feature is available on Amazon RDS for MariaDB 11.8, which matters to teams that don't run their own servers.

The documentation has one deliberate gap: MariaDB offers no dot-product (inner product) distance. The server documentation argues that dot product is not a proper distance measure and would add no speed in MariaDB's implementation. For normalized vectors it recommends Euclidean or cosine, which it says are equally fast. A developer porting code from a vector store that defaults to inner product will need to change the metric.

Its big selling point is architectural. The Foundation argues that keeping embeddings in the same relational database means no separate vector system to deploy, secure and keep in sync. It also notes that no extension is needed, unlike PostgreSQL's pgvector. The Foundation says MariaDB Vector is part of the open source Community Server, and draws a contrast with MySQL, whose vector indexing is available through the proprietary HeatWave service.

The Vector Index Rules an AI Assistant Can Get Wrong​

This section matters most in practice. If a coding assistant knows little about MariaDB Vector, the likely failure is not a refusal. It is SQL that runs correctly and silently ignores the index.

According to MariaDB's documentation, the optimizer uses the vector index only when the ORDER BY is the literal VEC_DISTANCE_*(column, vector) call (or its alias), sorted ascending, together with a LIMIT. The Foundation adds that the distance function must match the one the index was built with. Two common patterns break this and fall back to a full table scan:

1. Wrapping the distance in an expression, such as sorting by 1 - cosine distance to get a similarity score. The fix is to keep the inner query's ORDER BY on the bare distance and compute the score in an outer query.
2. Filtering by a threshold with a bare WHERE VEC_DISTANCE(...) < threshold and no ORDER BY ... LIMIT. The index cannot drive that range predicate. The fix is to fetch an indexed top-K and apply the threshold to it, for example in a subquery.

The second fix has a documented catch. The LIMIT caps how many rows the index returns before the threshold applies. If it is too small, qualifying rows beyond it are silently dropped. MariaDB's advice is to set it generously when many rows might match.

Ordinary SQL filtering works as advertised. The Foundation's quick-start example combines WHERE owner_id = 42 with ORDER BY VEC_DISTANCE(...) LIMIT 10 in one statement. That is the combined relational-plus-similarity query MariaDB treats as its main advantage.

The index's M setting controls the trade-off between accuracy and cost. Higher values give more accurate results but slow down SELECT and INSERT, enlarge the index and use more memory. MariaDB's own sources disagree on the valid range: the server reference documentation gives 3 to 200, and the Foundation's project page, in its description of 11.8 LTS, gives 3 to 100. Anyone tuning above 100 should check against the server version they actually run.

On newer releases, the server documentation says MariaDB 13.1 adds INFORMATION_SCHEMA.VECTOR_INDEXES. It reports each vector index's on-disk size, graph node count, cached nodes and cache memory. MariaDB calls that memory figure the value to watch when tuning mhnsw_max_cache_size.

LangChain and Spring AI Support MariaDB, Semantic Kernel Does Not​

Arnö says frameworks are one of the "million places" that need updating, and MariaDB's integration catalogue shows how uneven that coverage is. The documentation groups each framework by status: supported natively, supported via a separate package, partial, or only an open request.

In AI frameworks, MariaDB lists working support for:

• LangChain for Python, through the MariaDB-maintained langchain-mariadb package, with LangGraph reusing those vector stores.
• LangChain.js, through a MariaDBStore exported from @langchain/community.
• LangChain4j, through MariaDbEmbeddingStore in the langchain4j-mariadb module.
• LlamaIndex, whose vector store the documentation notes offers only a synchronous API.
• Spring AI, through MariaDBVectorStore with Spring Boot auto-configuration.
• A MariaDB MCP server in Python, which the Foundation says connects AI agents and assistants to MariaDB for SQL operations and vector-based semantic search.

The gaps matter just as much. Haystack has only an open request. Microsoft's Semantic Kernel, for .NET, Python and Java, has no MariaDB connector and no known request, according to MariaDB's table. A .NET developer building on Semantic Kernel won't see MariaDB as a vector store option, whatever an assistant suggests.

Coverage in ORMs and web frameworks is also mixed. Hibernate ORM 7.0 and TypeORM 0.3.28 support MariaDB vector columns. Laravel is partial: its core compiles vectorIndex() to a MariaDB VECTOR INDEX with M=6 DISTANCE=cosine, and a community package adds similarity helpers. MariaDB's documentation warns that the package's whereVectorSimilarTo filter always does a full table scan, while its ORDER BY-based macros can use the index. Doctrine and Drizzle have only open requests. Django ships no vector field for any database, and Prisma supports MariaDB but has no vector type for it. None of the low-code platforms MariaDB lists (Dify, n8n, Flowise, Langflow and Open WebUI) has a MariaDB vector store connector.

This table backs up Arnö's argument better than any chatbot prompt. When a framework's vector store dropdown lists no MariaDB option, the tutorials, sample code and eventually the training data built on that framework won't include MariaDB either. MariaDB's documentation asks users to add their use case to open requests, noting that maintainers prioritize by demand.

Galera Sits Outside the Foundation's Promise for MariaDB Server​

The interview also touched on a separate issue: what stays in the community edition as MariaDB tries to attract developers. The Register notes that Galera, the clustering technology used with MariaDB, has attracted controversy over its open source future and its place in the company's enterprise product line.

Arnö drew a firm line between the Foundation and MariaDB plc, the commercial company that develops enterprise products and sells support. He said Galera was not built by MariaDB's core engineering team. It came from an entity MariaDB plc acquired, and the company is "allowed to do whatever they want with it." What the Foundation protects, he said, is MariaDB Server: "if anybody is messing with that, we would be quite upset!"

The Foundation's published position supports the server side of that line. Its About page says MariaDB Server will remain free and open source software under GPLv2, independent of any commercial entities. The interview does not detail Galera's current licensing or packaging, and nothing in it suggests vector search is at risk. MariaDB Vector is part of Community Server. Teams that depend on Galera clustering should treat its future as a question for MariaDB plc, which the Foundation's assurances do not cover.

What this means for developers picking a vector store​

If you already run MariaDB, test MariaDB Vector on 11.8 LTS before adding a separate vector database, and don't let a coding assistant's first suggestion make that decision. The case for trying it is strongest when your embeddings sit next to relational data you already filter with SQL and your framework appears on MariaDB's supported list. The case is weaker if your stack depends on Semantic Kernel, Haystack, Django or a low-code platform, where you would be writing the integration yourself.

When an assistant does write MariaDB vector SQL, review it against the index rules above. Code that runs correctly but full-scans every row looks fine on a demo dataset and fails at production scale.

• MariaDB Vector is generally available from Community Server 11.8 LTS and Enterprise Server 11.4.5-3, so production evaluation should start there, not on the 11.7 rolling release.
• The vector index is used only for a bare, ascending ORDER BY VEC_DISTANCE_*(...) with a LIMIT and a distance function that matches the index, so check assistant-generated queries for wrapped expressions or threshold-only filters.
• MariaDB has no dot-product distance, so vector code ported from a store that defaults to inner product should switch to cosine or Euclidean on normalized vectors.
• LangChain, LangChain.js, LangChain4j, LlamaIndex and Spring AI have documented MariaDB vector stores, while Semantic Kernel has no MariaDB connector.
• Check the M range against your installed version, because MariaDB's reference documentation (3 to 200) and its Foundation project page (3 to 100) disagree.
• Treat Galera clustering's future as a MariaDB plc commercial matter, separate from the Foundation's GPLv2 commitment to MariaDB Server.

MariaDB has already done the engineering. What it lacks is presence in the framework connectors, tutorials and agent-readable docs that coding assistants learn from. The Foundation's agent skill files, llms.txt index and open framework requests are its attempt to fix that through documentation, not gaming, as Arnö prescribes. Until Semantic Kernel, Haystack and the low-code platforms add MariaDB connectors, developers who want MariaDB Vector will have to ask for it by name.