Benchmarking Vector search in six database engines - Percona

Enterprise-ready open source PostgreSQL
Percona Software for PostgreSQL
Open source PostgreSQL software for production workloads
Model infrastructure requirements for PostgreSQL deployments.
Download PostgreSQL software and tools
Enterprise Support and Services
Expert help to run PostgreSQL in production
Open source MySQL for enterprise use
Percona Software for MySQL
Production-ready open source MySQL software
Compare DBaaS vs MySQL on Kubernetes cloud costs
Download MySQL software and tools
Enterprise Support and Services
Expert help to run MySQL in production
Enterprise-grade value for MongoDB®
Percona Software for MongoDB®
Source-available, enterprise-grade compatible software for MongoDB®
Compare MongoDB® deployment options, costs, and trade-offs.
Download MongoDB® software and tools
Enterprise Support and Services
Expert help to run MongoDB® in production
Run and manage Redis or Valkey
Discover the benefits of migrating from Redis to Valkey
Download Valkey software and tools
Enterprise Support and Services
Expert help to run Redis and Valkey in production
Monitoring & Management (PMM)
Coroot Percona Edition
Expert Consulting and Services
We loaded 990,000 OpenAI embeddings of 1,536 dimensions into six databases that index vectors themselves, built an HNSW index in each, and measured five things: time to a queryable index, storage and memory, recall against throughput, throughput under concurrent clients, and what happens when 10% of the corpus is rewritten. Same host, same container shape, same query set.
The build numbers spread wider than we expected. Time to a queryable index ran from 1.9 minutes to 6.7 hours for the same million vectors. Index size ran from 3.9 GiB to 15.1 GiB, and the engine with the smallest index took the longest to build it. At recall 0.99 the field closes up: MariaDB 12.3, Valkey and pgvector are within a factor of 1.3 of each other. Under 32 clients pgvector returns 21.7× its single-client throughput. We do not report a comparable figure for the three InnoDB-based engines: their multi-client numbers measured a limit in our client, not in the server (see Concurrency).
This is one run on one machine. Multi-client numbers for MariaDB 11.8, MariaDB 12.3 and AliSQL are not reported, and the reason is below. Framework and configuration: github.com/Percona-Lab/vector-bench. Raw records, logs and manifest of this run: release run-full-20260825.
The database runs in one container and the harness in another, on a private network. One container would charge the several hundred megabytes of NumPy holding the query set to the server’s cgroup and ruin the memory numbers. The harness never configures a server. The orchestrator does, from the same code for every engine, and each engine’s settings are in its server logs beside the results.
Memory went to each engine’s own main cache, so the sizes differ by engine: a 42.3 GB buffer pool for the three InnoDB engines, 72.5 GB of shared_buffers plus 12.1 GB of maintenance_work_mem for pgvector, 108.7 GB of maxmemory for Valkey. Percona Search ran on MongoDB’s default WiredTiger cache, which came to 57–64 GB; the framework did not set it. The three engines with a graph cache, MariaDB 11.8, MariaDB 12.3 and AliSQL, got 30.2 GB of it. All three default to 16 MiB, and leaving that in place would judge a vendor on a value it plainly intends you to change. Index builds got 8 threads; the orchestrator clamped them down from 64, because more than a handful contend rather than help and a large value stalled writes into a populated index outright. It raised /dev/shm from 8 GB to 13 GB so pgvector’s parallel build could hold a segment the size of maintenance_work_mem.
In the recall-against-throughput results, recall is ann-benchmarks’ distance-threshold definition, so those numbers stay comparable with published ANN results. The filtered and churn sections score recall as the overlap with the true top-10 IDs. Ground truth for filtered queries is recomputed by brute force over the rows that satisfy each predicate. A WHERE clause changes the correct answer set, and scoring a filtered query against unfiltered neighbours scores every engine against the wrong targets.
Percona Search for MongoDB is a Technical Preview and its documentation says not for production. Its numbers use the scalar-quantized index, which MongoDB recommends above a 3 GB vector index.
MHNSW and VIDX update the graph on every INSERT, so their load is the index build and there is nothing separate to time. That puts them at 41 to 76 rows a second against pgvector’s 613 and Valkey’s 30,170. pgvector’s 40.9 minutes is 26.9 minutes of COPY plus 14.0 minutes of parallel build across 8 workers.
They get the smallest index for it: 3.9 GiB, where the raw float32 vectors alone are 5.7 GiB. The index is smaller than the vectors because MHNSW and VIDX keep 16-bit quantized copies of the vectors in the graph, while pgvector and Valkey index full float32. The full-precision vectors stay in the table: MariaDB stores 14.3 GiB there, Percona Search 5.8 GiB. Counting index and table together, AliSQL uses 14.4 GiB, pgvector 15.2, MariaDB 11.8 and Valkey 18.2 each, and Percona Search 20.9. Percona Search’s index measured 15.1 GiB after the load and 7.2 GiB at the start of the churn phase; we do not know which reflects its steady state.
Build time is a re-indexing window. Changing embedding model is an afternoon on pgvector and a weekend on AliSQL.
Best throughput whose measured recall clears each floor. MariaDB and AliSQL repeat a number across two columns because their lowest ef_search setting already returns recall 0.956 to 0.989. It wins both floors. For every MySQL-family engine the ef_search 10 point measured slower than ef_search 20, a warm-up effect the report flags, so their ≥ 0.90 column may be understated. Percona Search shows dashes because the scalar-quantized index used everywhere else in this post peaks at recall 0.892; unquantized, it reaches 138, 124 and 88 QPS at the three