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.
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.
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.
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.
Engine
Build (s)
Insert QPS
ANN QPS
ANN 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.
Alkin Tezuysal and René Cannaò will co-present “Beyond the Proxy: The Expanding ProxySQL Ecosystem” — a live webinar hosted by the OurSQL Foundation on November 3, 2026.
The session covers the broader ProxySQL ecosystem: expanding support for MySQL and PostgreSQL, a roadmap toward DuckDB, deeper cloud integration, and how tools like Orchestrator and dbdeployer fit in — structured around real operational problems rather than a feature checklist.
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.
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:
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:
Step
10k
100k
full (1,035,695)
Insert
7 s
41 s
407 s
Build the HNSW index (16 threads)
29 s
33 s
545 s
HNSW search
3–5 ms
4–7 ms
5–20 ms
Exact search (scans every row)
30 ms
280 ms
3 s warm
Recall@10, HNSW vs exact
100%
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 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.
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.
MyVector was featured at the inaugural MySQL Ecosystem Spotlight at Percona Live Amsterdam (September 9–11, 2026) — a shared community booth showcasing open-source MySQL projects, organized by the OurSQL Foundation.
Alkin Tezuysal, founder of MyVector, represented the project alongside four other MySQL ecosystem tools. On the experience, he said:
“The best way to unite the community and bring projects together.”
He also noted that while MyVector has been around for years and is well known within the close MySQL circle, the Spotlight helped it reach an audience that had never heard of it before.
All public conference slide decks are collected on the askdba SlideShare profile. Topics span MySQL ecosystem evolution, ClickHouse, ProxySQL, Vitess, MyRocks, vector search, and database design.
