Author Archives: alkin

MySQL Contributor Summit, Nov 4–5, 2026: vector search in MySQL in four phases, from the MyVector spark to the benchmark wars

Vector search in MySQL: from a plugin to the top of the Contributor Summit agenda

Leave a reply

A plugin started the fire, the M-ecosystem picked it up, the hyperscalers went native, and now the benchmark wars have begun.

Not long ago, if you asked about vector search in MySQL, you got a polite smile and a link to pgvector. Even after MySQL 9 added a VECTOR column type, the obvious next questions had no answer. Where is the index? Where is the distance function? For a while the honest answer was “use something else.”

This week the MySQL Contributor Summit (Nov 4–5, online) opened its technical program with vector search. The first discussion block, AI & Cloud, had four vector and AI proposals back to back from Oracle, Google, Percona and Intel. It was the clearest sign yet of how far vector search in MySQL has come.

Looking back, vector search in MySQL has moved through four phases:

  1. The spark: MyVector
  2. Adoption: the M-ecosystem picks up the idea
  3. Going native: the hyperscalers arrive
  4. The benchmark wars: where we are now

Phase 1: The spark, MyVector

We didn’t want to wait for a server release, so I co-founded MyVector, which I now own. It gives MySQL HNSW indexing, distance functions and approximate nearest neighbor search, all open source.

MyVector started as a plugin on MySQL 8.0. It has since moved to MySQL’s component architecture, which is far more robust on recent MySQL releases, and it now supports MySQL Community Edition 8.4, 9.7 and 26.10.

We took it to FOSDEM and SCALE, and the conversation changed from “MySQL can’t do this” to “wait, MySQL can do this?” You can try it yourself at demo.myvector.online.

Phase 2: Adoption, the M-ecosystem picks it up

Once MyVector showed that vector search fits naturally inside a MySQL-compatible engine, the idea spread across the M-ecosystem. MariaDB, TiDB, VillageSQL and Percona all started adopting the idea in their own products and distributions.

Each took its own path, but they all headed the same way: embeddings belong next to the data, inside the database people already run.

Phase 3: Going native, the hyperscalers arrive

The third phase is native implementations, with contributions now coming from the hyperscalers and the biggest names in the ecosystem. You could see it at the summit, where the four AI & Cloud talks came from the upstream owner, a hyperscaler, a fork vendor and a chip maker:

SessionFromGitHub
Evolving MySQL VECTOR Support: Native Indexing and Similarity Search
Mayank Prasad, Kuba Lopuszanski		OracleIssue #3
Invoking AI models from MySQL
Julia Offerman		GoogleIssue #158
DISTANCE() Functions for the VECTOR Data Type
Catalin Besleaga		PerconaPR #860
Bringing SVS’s Graph-Based Vector Search to MySQL
Kelly L. McKeighan		IntelIssue #116
AI & Cloud discussion block, MySQL Contributor Summit Fall 2026, followed by a design review with all attendees

All four brought proposals, bug reports and pull requests for the same feature.

Phase 4: The benchmark wars

With several implementations in play, the next step was inevitable: people started measuring in public and answering each other’s numbers.

Percona, Aug 27: Benchmarking vector indexes

Evgeniy Patlan set the ground rules with vector-bench, an open harness that runs each engine in its own pinned container on the same cores with the same data. Every measurement is a pair of throughput and recall, and recall is a setting, not a property of the engine.

ef_search 10 → 800 · recall 0.959 → 0.999 · 3,678 → 409 QPS

askdba, Oct 14: How fast is vector search inside MySQL?

I ran MyVector on MySQL against MariaDB Vector on 50,000 vectors. MariaDB’s first run came in at only 29 QPS. Instead of publishing that, I traced it to the 16 MB default HNSW cache, which could not hold the 27 MB index, and reran it.

MyVector ≈ 548 QPS @ recall 0.82 · MariaDB ≈ 257 QPS @ recall 0.95

lefred (MariaDB), Oct 16: Vector Search in MySQL vs MariaDB: Look Beyond QPS

lefred answered: two QPS figures at different recall are not apples to apples. He estimated MariaDB at matched recall, showed that a bigger cache cut index build from about 583 to 92 seconds, and argued the 16 MB default deserves a rethink. Fair points, made in good faith.

MariaDB est. ≈ 1,196 QPS @ recall 0.82 · build 583 s → 92 s

VillageSQL, Oct 22: Benchmarking vector indexes in MySQL with vector-dev-bench

Adam Levin, working with Percona, released vector-dev-bench, a laptop-scale companion that answers in minutes. It sweeps ef_search and measures what writers cost readers.

20k × 32-dim · recall 0.787 → 0.988 · 8,829 → 2,044 QPS · reads −40% with writers

Every round raised the bar. The community converged on pairing throughput with recall, exposing defaults and testing writes alongside reads. MyVector is being added to vector-bench as an engine, so anyone will be able to rerun the numbers. Results for MyVector and other engines are published side by side at bench.myvector.online. That is how an open-source ecosystem decides something matters.

The spark is now a fire.

Why this matters

We have seen this pattern before. JSON in MySQL went through the same steps: store it as text, then a native type, then functions, then indexes, and finally the default choice.

Vectors are moving through those steps much faster, because a plugin proved it was possible, the ecosystem adopted it, the hyperscalers are building it in, and the benchmarks keep everyone honest.

For teams running MySQL in production, the question is moving away from “which separate vector database?” and toward “can my embeddings live next to my transactional data, in the database my team already knows how to run?”

Join the conversation

The Contributor Summit is open and online. Proposals are filed as issues in the mysql/mysql-community GitHub repo, and the hallway track continues in the MySQL Community Slack in #contributor-summit-hallway-track. If you work on vector search in MySQL, bring your ideas, your pull requests and your benchmarks to the next one.

What’s next

  • Native indexing and similarity search proposals moving through upstream design review
  • Standard DISTANCE() functions replacing vendor-specific workarounds
  • MyVector continuing as a way to run vector search on MySQL Community Edition today, with open, reproducible benchmarks

We’re not done. Thanks to Heather VanCura and the MySQL Community team for running an open, design-review-style summit.

Links

Oracle MySQL logo

MyVector Featured in the MySQL Ecosystem Project Spotlight of the Week

Leave a reply
Oracle MySQL logo

MyVector has been featured as the MySQL Ecosystem Project Spotlight of the Week in the MySQL group on LinkedIn. Thank you to Lilly Berry and the MySQL community team for the shout-out!

This week, we’re spotlighting MyVector, an open source plugin that brings vector storage and similarity search capabilities to MySQL. Semantic search and recommendation features open up exciting possibilities for MySQL applications, giving developers a way to explore those possibilities using familiar SQL tools. Keeping vector search alongside application data may eliminate the need for a separate ETL pipeline for certain use cases.

With HNSW indexing and a SQL interface, MyVector offers an interesting starting point for developers building applications around embeddings. It’s also a great example of the MySQL community extending what developers can do with the database.

Lilly Berry, Communications @ Oracle, in the MySQL group on LinkedIn

If you’re exploring semantic search or recommendations with MySQL, take a look at the documentation, try the examples, and share your feedback.

🔗 Spotlight post in the MySQL LinkedIn group · MyVector on GitHub

MySQL MCP Server v1.8.0: 37 vulnerabilities fixed, integration tests passing on MySQL 8.0, 8.4, 9.7, 26.7 and MariaDB 11.4, 12.3

MySQL MCP Server v1.8.0 is out

Leave a reply

On paper it’s a boring release. No new tools, no new flags, nothing to reconfigure. In practice it’s one I’m glad I didn’t skip: it closes 37 known vulnerabilities that the server could actually reach, and I found them more or less by accident.

It started as a compatibility check

I had MySQL 8.4, 9.7 and 26.7 running on my test box, plus MariaDB 12.3. So I pointed the MCP server’s test suite at all of them. Mostly to tick a box before moving on to something more fun.

The code was fine. Every version passed.

MySQL 26.7 and MariaDB 12.3 join the matrix

Every pull request now runs the full integration suite against six servers:

  • MySQL 8.0, 8.4, 9.7 and 26.7
  • MariaDB 11.4 and 12.3

26.7 is the first Innovation release under Oracle’s new calendar versioning. If you follow MyVector, you know I’ve been chasing it there too.

MySQL 9.0 is out of CI. It was a short-lived Innovation release, and 9.7 covers that line now.

MySQL 8.0 is staying. Yes, it reached end of life in April. No, I’m not dropping it. Plenty of you are still on 8.0 and haven’t moved to 8.4 yet, and I’d rather keep testing it than pretend otherwise.

One more thing turned up along the way. The Sakila tests weren’t running in CI at all: the sample database was never loaded, so they skipped quietly. They run now, on every version.

Green CI, 37 vulnerabilities

CI was not fine. The vulnerability scan and the linter had been failing quietly for a while. Both were set to informational, so nothing ever turned red.

Once the scan ran again, it found 37 vulnerabilities in code the server actually calls. Most were in the Go 1.24 standard library, the rest in the SSH and MCP SDK dependencies.

v1.8.0 fixes all of them:

  • Go 1.24 → 1.26
  • golang.org/x/crypto v0.43.0 → v0.58.0
  • MCP Go SDK v1.2.0 → v1.8.0

If you use the SSH tunnel: that library jumped 15 minor versions, so I tested it through a bastion before tagging. It still connects, and it still refuses a server whose host key doesn’t match known_hosts.

And since the release, govulncheck blocks merges and releases, so this can’t quietly happen again.

Release candidates stay out of Homebrew

This one’s a bit embarrassing. When I cut v1.7.1, all four release candidates went straight to the Homebrew tap. If you ran brew upgrade that week, you got an RC. Sorry about that.

RCs now only show up on the GitHub releases page. brew upgrade only ever gives you a final release.

v1.8.0 went out the new way. rc.1 first, smoke-tested against real 8.4, 9.7, 26.7 and MariaDB 12.3 servers, then the final tag. Homebrew users never saw the RC.

Things I learned the hard way

Two, mostly.

First, don’t write [skip ci] in a commit message. Not even when you’re describing a different commit that had it. GitHub doesn’t read for context. My PR sat there with no CI run at all while I wondered what was going on. With a required check on main now, that PR would have stayed stuck until I reworded the commit.

Second, the AI code reviewers earned their keep this time. CodeRabbit spotted a startup race in the CI health checks. Codex pointed out that scanning on Linux alone misses Windows-only code. And Copilot noticed that one of my test fixes would have broken the release workflow on the very first tag. I would have found that one at release time, which is the worst time to find anything.

Upgrading

Breaking change: building from source now needs Go 1.26 or later. Homebrew, Docker and the release binaries aren’t affected, and there’s nothing to reconfigure.

Homebrew:

brew update && brew upgrade mysql-mcp-server

Docker:

docker pull ghcr.io/askdba/mysql-mcp-server:1.8.0

Or grab a binary from the v1.8.0 release. Here’s what my Mac said after brew upgrade:

$ mysql-mcp-server --version
mysql-mcp-server 1.8.0
  Build time: 2026-10-17T09:14:37Z
  Git commit: f946f1d37654b5d8958d45a027a3e68133f01d1a

The full list is in the CHANGELOG. Questions, bugs and ideas are welcome on GitHub.

Alkin Tezuysal at All Things Open 2024

Speaking at All Things Open 2026 in Raleigh

Leave a reply

Presenting From Source Code to Source of Truth: 30 Years of Open Source Database Evolution at All Things Open 2026 in Raleigh, North Carolina.

Conference: October 19-20, 2026 · Raleigh Convention Center, Raleigh, NC

This session traces three decades of open source database innovation — from early MySQL and PostgreSQL adoption through NoSQL proliferation, the cloud-native era, and into today’s AI-augmented stack. The talk draws on personal experience across Percona, PlanetScale, Altinity, and now ProxySQL to show how community-driven development shaped modern data infrastructure.

🔗 Session page at allthingsopen.org

Oracle ACE Spotlight: Featured on #JoelKallmanDay

Leave a reply

The Oracle ACE Program published a spotlight feature on Alkin Tezuysal as part of #JoelKallmanDay 2026 — an annual celebration honoring the spirit of community, generosity, and knowledge-sharing that Oracle ACE Joel Kallman embodied throughout his career.

The spotlight dives into Alkin’s 30+ years of open-source database experience — from his early career through his current role as Director of Services at Altinity Inc., his work on the MyVector plugin for MySQL, and his life as a prolific international conference speaker. It also touches on a personal detail many might not know: during summer months, he works remotely from his sailboat somewhere between the Greek and Turkish islands.

Alkin holds Oracle ACE Pro status (awarded 2025), co-authored MySQL Cookbook, 4th Edition (O’Reilly, 2022) and Database Design and Modeling with PostgreSQL and MySQL (Packt, 2024), and has been recognized as MySQL Rockstar 2023 and Most Influential in the Database Community 2022 by The Redgate 100.

👉 Read the full spotlight on the Oracle ACE Blog

Bar chart showing MySQL vector search benchmark: 548 QPS for MySQL 9.7, 257 QPS for MariaDB 12.3

How fast is vector search inside MySQL?

Leave a reply

Benchmarks · HNSW vector search

MyVector adds approximate nearest-neighbor search to stock MySQL — no separate vector database. We put it on identical hardware across three MySQL versions, added MariaDB’s native vector type as a reference, and measured build time, throughput, latency, and recall on the same data.

askdba/myvector · live dashboard at bench.myvector.online

548
peak ANN queries/sec (MySQL 9.7), ~1.8 ms median
0.95
best recall@10 (MariaDB 12.3) once tuned
4×
engines, one 50k×128 workload, identical 4 vCPU / 24 GB slices

Why benchmark this at all

Vector search usually means standing up a dedicated database next to your primary store, then keeping the two in sync. MyVector takes the other path: it lives inside MySQL as UDFs and stored procedures, builds an HNSW index over a column of vectors, and answers nearest-neighbor queries in SQL. The obvious question is whether that convenience costs you speed or accuracy.

To answer it honestly we needed a level field. Every engine runs in its own container on one Ampere A1 host, each pinned to the same 4 vCPU / 24 GB slice, loading the same 50,000 synthetic 128-dimensional vectors (seeded, so every engine indexes identical data), and builds an HNSW index with the same parameters (M=16, ef_construction=200, L2 distance). Three of the four are MySQL running MyVector — versions 8.4, 9.7 and 26.7. The fourth is MariaDB 12.3, which ships its own native VECTOR type, included as a cross-engine reference point.

What each number means

Five measurements, each isolating one thing:

  • Index build — wall-clock seconds to build the HNSW graph over all 50k rows.
  • Insert throughput — rows/sec written into a live, indexed table.
  • ANN QPS & latency — approximate nearest-neighbor queries per second through the index, and their median response time.
  • Recall@10 — of the true 10 nearest neighbors (found by exact brute-force search), how many the approximate search actually returns, averaged over held-out queries that were never inserted. 1.0 is perfect; 0.82 means it finds ~8 of the real 10.
  • ef_search sweep — the accuracy/throughput trade-off: searching more of the graph raises recall but lowers QPS.

Results

The headline is throughput. On identical A1 hardware, all three MySQL versions clear ~530–550 approximate queries per second at ~1.8 ms median — roughly 500× faster than the exact brute-force scan (~1 QPS) they fall back to without an index. 8.4, 9.7 and 26.7 land within a few percent of each other, so moving to a newer MySQL costs nothing here.

Approximate nearest-neighbor throughput at the default operating point (ef_search=200). Higher is better. All four engines on identical Ampere A1 hardware.
Recall@10 at the same operating point. The three MyVector builds land at 0.82; MariaDB 12.3 reaches 0.948 — it trades some speed for accuracy in how it walks the graph.

The real picture: accuracy vs throughput

A single QPS number hides the trade-off. The ef_search knob lets each query decide how hard to look: low values are fast but miss neighbors, high values are accurate but slow. Plotting recall against QPS across that sweep is the honest comparison — up and to the right is better.

Each point is one ef_search setting (10 → 200). MariaDB’s curve sits higher on recall at a given speed; the MySQL/MyVector curves reach higher raw QPS. All share the same synthetic ground truth.
EngineBuild (s)Insert QPSANN QPSANN p50 (ms)Recall@10

Exact brute-force KNN measured ~1 QPS (~700 ms) on every engine — the baseline the index is beating.

The MariaDB surprise

The first MariaDB run looked grim: 29 ANN QPS, a 583-second build, recall aside. Taken at face value it was 15× behind MySQL. That gap was too large to be a real engine difference, so we dug in.

The cause was one default. MariaDB caches its HNSW graph in memory up to mhnsw_max_cache_size, which ships at 16 MB — but the index for this dataset is ~27 MB. The graph didn’t fit, so every search and the whole online build re-read nodes from disk. MyVector sidesteps this by loading its entire index into memory, so the default pitted a disk-bound MariaDB against an in-memory MyVector.

Sizing the cache above the index changed everything:

MariaDB 12.3, same data and hardware, cache at its 16 MB default vs sized above the index. ANN throughput rose ~9×; build dropped from 583 s to 92 s; recall improved from 0.85 to 0.95. (Search alone, measured in isolation, was ~15× faster.)

The lesson, not the leaderboard

Properly configured, MariaDB’s native vector search is competitive with MyVector on speed and ahead on recall. The takeaway isn’t a winner — it’s that a single cache default can make one engine look an order of magnitude slower than it is. Benchmarks are only as fair as their configuration, which is why the setup here is in the open.

Takeaways

  • Native MySQL vector search is fast. ~530–550 QPS at single-digit-millisecond latency on 4 modest cores, ~500× over brute force — without a second database to run.
  • Newer MySQL isn’t slower. 8.4, 9.7 and 26.7 land within a few percent of each other; there’s no regression moving forward.
  • MariaDB 12.3 holds its own once its HNSW cache fits the index — higher recall, comparable throughput.
  • Configuration is part of the result. The most interesting finding wasn’t a speed number; it was a default that quietly handicapped an engine 15×.

Every number here is reproducible. The live, interactive dashboard is at bench.myvector.online, and the benchmark harness and raw results live in github.com/askdba/myvector under scripts/bench-dashboard. Workload: 50,000 × 128-d vectors, L2 distance, HNSW M=16 / ef_construction=200, held-out queries for recall, each engine pinned to 4 vCPU / 24 GB on Ampere.

Movie Finder: semantic search over 1M films, inside MySQL

Leave a reply

Type “a heist that goes wrong in a snowy town” and get back real films, with posters, in a few milliseconds. The vector search behind it runs inside MySQL, with no separate vector database.

Movie Finder is the new demo app that ships with MyVector. It searches up to 1,035,695 TMDB movies by meaning, not keywords. One docker compose up gives you the whole thing: MySQL 9.7 with the MyVector component, a loader, and a small web app.

Try it live: https://demo.myvector.online/

We built it to answer the questions people ask us most. Does vector search in MySQL hold up at a million rows? Can I mix it with ordinary WHERE filters? What happens when I insert a new row? The demo shows the answers on the page, with the SQL that ran under every result.

Live: What you can do on the page

Every feature on the page maps to a MyVector capability, and every result panel shows its SQL.

  • Describe a movie in your own words and get the nearest films. Ask for “a boy wizard at a school of magic” and Harry Potter comes back first.
  • Filter by genre, year, rating and language. These are plain SQL predicates combined with the vector search, and the page tells you which filtered-search path ran and why.
  • Rank by similarity alone, or with a small boost for films many people have rated, so the famous match beats an obscure one at almost the same distance. Both are ordinary ORDER BY expressions.
  • More like this: a film’s stored vector becomes the next query, in pure SQL.
  • HNSW vs exact: run both side by side and compare speed and recall.
  • Add a movie: a plain INSERT, searchable within about a second, with no index rebuild. (Not on live demo)
  • Under the hood: live index details from myvector_index_status, a bar showing where each query’s time went, and a speed-vs-recall chart that sweeps ef_search from 10 to 640 against an exact scan.

How it works

The app embeds only your query text; every movie’s vector already sits in MySQL, so a search is one SQL round trip. The movie vectors come with the dataset, made by nomic-embed-text-v1.5 from each film’s title, tagline, and overview. The app uses the same model locally on the CPU, so there is no API key, and nothing leaves your machine.

New rows need no rebuild. Adding a movie is a plain INSERT; MyVector’s binlog listener picks it up and adds it to the HNSW index, usually within a second.

The SQL

The whole index is declared in a column comment. This is the movies table’s vector column:

embedding VARBINARY(3080) COMMENT
  'MYVECTOR COLUMN type=HNSW,dim=768,size=...,M=16,ef=100,dist=Cosine,online=Y,idcol=id,threads=N'

The loader inserts the rows, then builds the HNSW index with one call:

CALL mysql.myvector_index_build('movies.movies.embedding', 'id');

A search turns the query vector into a nearest-first list of ids with myvector_ann_set(), then joins back to the table. JSON_TABLE keeps the order:

SELECT m.title, myvector_distance(m.embedding, @q, 'Cosine') AS distance
FROM (SELECT myvector_ann_set('movies.movies.embedding', 'id', @q,
                              'nn=10,ef_search=100') AS js) src,
     JSON_TABLE(src.js, '$[*]' COLUMNS (rank_no FOR ORDINALITY, id INT PATH '$')) nn
JOIN movies.movies m ON m.id = nn.id
ORDER BY nn.rank_no;

“More like this” needs no embedding at all. It reads a film’s stored vector into the query variable:

SELECT embedding INTO @q FROM movies.movies WHERE id = @movie_id;

Filters pick one of two paths. The app counts each filter on its own index and takes the smallest count as an upper bound:

  • 50,000 matches or fewer: it passes the matching keys as the fifth argument of myvector_ann_set, so HNSW searches only among them.
  • More than that: it calls MYVECTOR_ANN_FILTERED, which takes the nearest candidates and keeps those that pass the filter.

Run it yourself

To run your own copy, from a clone of the repository:

cd examples/movie-finder
MOVIES=100k docker compose up      # then open http://localhost:8080

The first start downloads the TMDB data, about 7 GB, once. MOVIES picks how many films to load, most-voted first: 10k, 100k (the default) or full. Measured on a 16-core Arm (Neoverse-N1) Linux host with MySQL 9.7.2:

Step10k100kfull (1,035,695)
Insert7 s41 s407 s
Build the HNSW index (16 threads)29 s33 s545 s
HNSW search3–5 ms4–7 ms5–20 ms
Exact search (scans every row)30 ms280 ms3 s warm
Recall@10, HNSW vs exact100%100%100%

At a million movies, HNSW answers in 5–20 ms where a full scan takes 3 seconds, with the same top 10. Recall is for the unfiltered test query; a broad genre filter (Drama) at full size gave 80% at ef_search 100, and the page lets you raise ef_search to trade time for recall. For the full profile, give Docker about 12 GB of memory and set MYSQL_BUFFER_POOL=6G.

Running it on a remote server? The page and MySQL listen on localhost only. Forward the port instead of opening it: ssh -N -L 8080:127.0.0.1:8080 <server>.

Version note: the demo uses features newer than the v1.26.9 images: filtered search, MYVECTOR_ANN_FILTERED, per-query ef_search, and online updates that survive a restart. Until the next release ships, the README shows how to build a local image from main.

Data: the movie metadata and posters come from TMDB via a Hugging Face mirror. Your machine downloads it; it is not in the repository or any image. This is a non-commercial demo, not endorsed by TMDB.

Try it and tell us

Try the live demo first. To run your own, start with MOVIES=10k for a quick first look, then go to full to watch a million rows answer in milliseconds. The demo guide has screenshots and the other demos; the Movie Finder README has the full details.

If a query surprises you, or you want a feature the page doesn’t show yet, open an issue on GitHub. A star helps other MySQL users find the project.

MyVector v1.26.9: Now Supporting MySQL 26.7 Innovation Release

Leave a reply

MyVector v1.26.9 has been released with support for MySQL 26.7 — the first Innovation release under Oracle’s new calendar-based versioning scheme, which replaces traditional x.y.z numbering with a YYYY.M format.

The release also gives the component-based architecture introduced in v1.26.5 a more rigorous test run across the new Innovation release track. MyVector is an open-source plugin that adds native vector search to MySQL Community Edition, developed and maintained by Alkin Tezuysal.

👉 See the MyVector benchmark: How fast is vector search inside MySQL?

MySQL BR Conf 2026: Managed ProxySQL in Your Own AWS Account

Leave a reply

Alkin Tezuysal co-presented “Managed ProxySQL in Your Own AWS Account” with René Cannaò (CEO of ProxySQL) at MySQL BR Conf 2026 in São Paulo, Brazil on September 26, 2026.

The session covered ProxySQL.Cloud — a bring-your-own-cloud architecture that lets users run managed ProxySQL instances in their own AWS accounts. Topics included configuration, day-to-day operations, and the business case for cloud-native ProxySQL deployment. MySQL BR Conf is the premier MySQL community event in Latin America.

👉 Slides and recap via VillageSQL