MariaDB Vector: How it works. Part II

In the first post of this series, I’ve described how the vector index is stored in a table and how it achieves full transactional behavior and ACID properties compatible with the storage engine of the table the user created. But while the table provides persistent storage of the index, it’s in-memory part that gives it the performance. This is how it works.

Distance calculations

This is the most performance sensitive part of the HNSW. According to various estimates, distance calculations account for 80–90% of search time. And this operation time grows linearly with the vector length.

MariaDB Vector: How it works

You might have seen that MariaDB Vector is fast. And is getting faster. But why? How does it achieve that? And why it is said to use mHNSW (modified HNSW) algorithm? What did it modify in the conventional HNSW that all other databases are using? Let’s take it apart and analyze piece by piece.

Introduction into HNSW

This post is not a full description of HNSW, there are many HNSW descriptions online and they are good, better than what I could’ve written. I will only show the basic concepts beyond HNSW, concepts that are crucial for the rest of the post.

Big Vector Search Benchmark: 10 databases comparison

I have benchmarked MariaDB Vector before, but it was a while ago. Users kept asking about Milvus. New pgvector alternatives were gaining popularity. And I simply wanted to see if MariaDB got any better. This benchmark round includes more databases, larger dataset, and no irrelevant datasets that only add noise but don’t really help today in 2026.

Dataset

Now is the AI time. Vector search is used for embeddings generated by LLMs. Most ann-benchmarks datasets are pre-AI and use, for example, image transformations and filters to construct vectors. While useful for certain purposes, they are not the main use case for the MariaDB Vector and providing these results would be misleading and distracting from what matters to users.

Making MariaDB the Natural Successor to MySQL

At the MariaDB Foundation, clarity of purpose matters. In an ecosystem as foundational as open-source databases, confidence is built not through slogans, but through predictability, restraint, and long-term commitment.

As I reflect upon what we learned in 2025 and how we can serve the database community in 2026, one thought stands out: MariaDB is the natural successor to MySQL, as Oracle loses its interest in the development of what has been the default Open Source Relational DBMS.

The MariaDB Foundation recognises its responsibility. As uncertainty around MySQL’s long-term direction continues to grow, the global community of users, operators, and vendors quite reasonably seeks continuity.

How deep can a bug be?

Last year I filed a bug report MDEV-33603 on what a looked like a benign problem with an optimizer taking a different code path in a particular trivial looking test. Its benign looking nature lead to me not looking at it until last week. The “benign” bug as it turned out is a bug in an OpenSSL optimization on IBM POWER, which maybe not the lowest level of “How deep”, but its certainly a long way from the high level (above storage engines) optimizer decisions in MariaDB.

Image by: Valerie Hinojosa on WikiMedia Commons

I feel I need to start this story justifying why it was left so long.

MariaDB Cloud: A Semi-Technical Introduction

When co-founding MariaDB plc under the name SkySQL Corporation fifteen years ago (before MariaDB Foundation existed), we picked the name SkySQL with a bit of a reference to the cloud. Obviously, we didn’t then have a clear understanding of what type of a cloud offering MariaDB should have. I am glad to note that those days are finally and completely over, with MariaDB Cloud. I wish it hadn’t taken fifteen years!

So now, I sat down for a proper chat with Jags Ramnarayan, the technical father of SkySQL / MariaDB Cloud.

How to Succeed in the MariaDB Python Hackathon, Bangalore

Last Friday, we hosted an Ask Me Anything session with HackerEarth – and we promised to share the same insights here in written form. So here it is: your guide to success in the MariaDB Python Hackathon!

A Great Idea Is Only the Beginning

A brilliant idea submission is just the start. The real work lies in the development — and that’s exactly what’s happening this month.

We want you to succeed. Success can mean that your hackathon contribution is widely used, that it puts you in the spotlight, and that it builds your reputation as a developer who makes a real impact.

MariaDB and AI: Building the Bridge That Really Matters

Not what AI can do for MariaDB – but what MariaDB can do for AI

I have hinted at this before (This Month in MariaDB – August 2025), but it deserves to be said again: our vision for MariaDB’s role in AI is both clear and ambitious. We do not simply want to participate in the AI space – we aim to be the bridge between real-world data and modern AI systems.

Large Language Models are, at their core, vast read-only neural networks. The data that organisations truly depend upon does not reside inside these models;