Vector engine benchmark: eshoponweb

Run started 5 Oct 2026, 03:15 UTC. Data: eShopOnWeb, 524 vectors. Queries: 20 labelled questions.

Used by: published-2026-10-08 (basis v5)

The runs of v5 were also used by the set blocked-2026-10-05-v5, which was not published; its verdict, design/verdicts/v5-verdict.txt, holds the word BLOCK.

sources

file design/verdicts/v5-verdict.txt#BLOCK = BLOCK
consolidated consolidated:reuse[session=v5].verdict = design/verdicts/v5-verdict.txt
consolidated consolidated:reuse[session=v5].blockedFolders[0] = blocked-2026-10-05-v5

Corrections to statements recorded in this run

This run's report is kept as it was written. A set that uses this run states that the recorded statements below are false, misleading or unbacked. Each is marked in the report text.

False: Weaviate, durability. Recorded: weaviate.compose.yaml sets no persistence variable deploy/engines/weaviate.compose.yaml sets PERSISTENCE_DATA_PATH to /var/lib/weaviate. The compose file does set a persistence variable. Listed in published-2026-10-08. Marked in the report text, lines: 1.
sources
- file deploy/engines/weaviate.compose.yaml#PERSISTENCE_DATA_PATH: /var/lib/weaviate = PERSISTENCE_DATA_PATH: /var/lib/weaviate
- results results@20261005-031556-eshoponweb:targets[weaviate].durability#sets no persistence variable = sets no persistence variable
Misleading: ClickHouse, disk.text. Recorded: 906.61 MiB added by this load The figure is the growth of the whole data folder over the engine's turn, as the same line says (3.52 GiB at the end, 2.64 GiB before). The load itself is 524 vectors of 1024 dimensions, 2,146,304 bytes as 4-byte floats (2.05 MiB); the figure is 950,649,750 bytes. Listed in published-2026-10-08. Marked in the report text, lines: 1.
sources
- results results@20261005-031556-eshoponweb:targets[clickhouse].disk.text = 906.61 MiB added by this load (3.52 GiB (whole engine data folder), 2.64 GiB before)
- results results@20261005-031556-eshoponweb:rows = 524
- results results@20261005-031556-eshoponweb:dimension = 1024
False: framing line. Recorded: Measured end to end through each engine's .NET client The statement is false for 8 of the 19 engines of this run: chroma, clickhouse, elasticsearch, milvus, opensearch, typesense, vespa and weaviate are reached through the benchmark's own HttpClient REST code, not through a .NET client of the engine. For those engines the figure is the cost of the benchmark's own request code. A code line of each is cited. Listed in published-2026-10-08. Marked in the report text, lines: 1.
sources
- file src/GenericVectorBuilder.Engines/Sinks/ChromaSink.cs#new HttpClient { BaseAddress = new Uri( options.BaseUrl = new HttpClient { BaseAddress = new Uri( options.BaseUrl
- file src/GenericVectorBuilder.Engines/Sinks/ClickHouseSink.cs#new HttpClient { BaseAddress = new Uri( $"http://{options.Host}:{options.Port}/" = new HttpClient { BaseAddress = new Uri( $"http://{options.Host}:{options.Port}/"
- file src/GenericVectorBuilder.Engines/Sinks/ElasticsearchRest.cs#new HttpClient { BaseAddress = new Uri( _baseUrl + "/" ) = new HttpClient { BaseAddress = new Uri( _baseUrl + "/" )
- file src/GenericVectorBuilder.Engines/Sinks/MilvusSink.cs#new HttpClient { BaseAddress = new Uri( options.BaseUrl = new HttpClient { BaseAddress = new Uri( options.BaseUrl
- file src/GenericVectorBuilder.Engines/Sinks/OpenSearchRest.cs#new HttpClient { BaseAddress = new Uri( _baseUrl + "/" ) = new HttpClient { BaseAddress = new Uri( _baseUrl + "/" )
- file src/GenericVectorBuilder.Engines/Sinks/TypesenseRest.cs#new HttpClient { BaseAddress = new Uri( _baseUrl + "/" ) = new HttpClient { BaseAddress = new Uri( _baseUrl + "/" )
- file src/GenericVectorBuilder.Engines/Sinks/VespaRest.cs#_data = new HttpClient( handler ) = _data = new HttpClient( handler )
- file src/GenericVectorBuilder.Engines/Sinks/WeaviateSink.cs#new HttpClient { BaseAddress = new Uri( options.BaseUrl = new HttpClient { BaseAddress = new Uri( options.BaseUrl
Not backed by a saved source: index. Recorded: an earlier run gave about 0.09 at 100,000 No log was saved for this figure, and the summary does not print the clause. A saved re-run of the MariaDB effort test (10 repeats, 524 and 2,000 random 1024-dimension vectors) read recall@10 at ef 100 of 0.988 to 0.996 at 524 vectors and 0.894 to 0.932 at 2,000. The 100,000-row figure was not re-measured the same way and is dropped. Listed in published-2026-10-08. Marked in the report text, lines: 2.
sources
- file design/bench-inputs/mariadb-effort-2026-10-07/SOURCES.txt#for which no log was saved = for which no log was saved
- file design/bench-inputs/mariadb-effort-2026-10-07/SOURCES.txt#The 100,000-row figure was not re-measured the same way, so the report drops it. = The 100,000-row figure was not re-measured the same way, so the report drops it.
- file design/bench-inputs/mariadb-effort-2026-10-07/run.log#RECALL@10 on 524 random 1024-dim vectors, 50 queries: ef 20 0.872, ef 100 0.988, ef 3200 0.988 = RECALL@10 on 524 random 1024-dim vectors, 50 queries: ef 20 0.872, ef 100 0.988, ef 3200 0.988
- file design/bench-inputs/mariadb-effort-2026-10-07/run.log#RECALL@10 on 524 random 1024-dim vectors, 50 queries: ef 20 0.886, ef 100 0.996, ef 3200 0.996 = RECALL@10 on 524 random 1024-dim vectors, 50 queries: ef 20 0.886, ef 100 0.996, ef 3200 0.996
- file design/bench-inputs/mariadb-effort-2026-10-07/run.log#RECALL@10 on 2000 random 1024-dim vectors, 50 queries: ef 20 0.468, ef 100 0.894, ef 3200 0.994 = RECALL@10 on 2000 random 1024-dim vectors, 50 queries: ef 20 0.468, ef 100 0.894, ef 3200 0.994
- file design/bench-inputs/mariadb-effort-2026-10-07/run.log#RECALL@10 on 2000 random 1024-dim vectors, 50 queries: ef 20 0.482, ef 100 0.932, ef 3200 0.992 = RECALL@10 on 2000 random 1024-dim vectors, 50 queries: ef 20 0.482, ef 100 0.932, ef 3200 0.992
- file deploy/bench/recorded-text-classes.json#"drop": "mariadb-recall" = "drop": "mariadb-recall"

Machine: CPU Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz; Logical CPUs 8; RAM (GiB) 62.7; OS Ubuntu 24.04.5 LTS, kernel 6.8.0-142-generic; Governor performance; Partition client 0-1,4-5; engines 2-3,6-7; Release build; Exact mode seconds 60.

Warm-up, as this run's notes record it: Warm-up: every timed pass started with its own untimed warm-up of 20 searches in the same search mode and with the same number of searchers, stopped early after 60 s; with machine control on, the check for a quiet box comes right before the warm-up, so warm-up and timed pass run back to back.

No CPU clock pin is recorded in this run's notes.

Engine	p50 (ms)	Searches per second, one searcher	Searches per second, eight searchers at once	Exact mode p50 (ms)	Client CPU per search, one searcher (ms)	Recall in hits	Flags
Chroma	2.03	488	805	-	0.46	200 of 200
ClickHouse	4.73	204	427	6.43	0.83	197 of 200
DuckDB	3.49	284	279	4.01	4.81	200 of 200
Elasticsearch	1.34	716	2,653	1.24	0.47	200 of 200	Ix
MariaDB	0.62	1,573	5,970	1.58	0.48	200 of 200
Milvus	2.21	432	1,276	-	0.54	200 of 200
MongoDB Atlas Local	1.38	699	2,063	1.23	0.31	200 of 200
OpenSearch	2.02	486	1,479	2.60	0.47	200 of 200
Oracle 23ai Free	0.90	1,089	3,156	2.44	0.88	200 of 200
Qdrant (HNSW)	0.92	1,079	3,457	0.89	0.74	200 of 200
Qdrant (exact)	0.88	1,118	3,284	-	0.73	200 of 200
Redis redis holds its data in memory: its saved docs page says 'Redis is an in-memory but persistent on disk database', and its compose file sets save "300 1" and appendonly no. sources doc `doc:design/engine-docs/redis-faq-2026-10-07.html#Redis is an in-memory but persistent on disk database` = Redis is an in-memory but persistent on disk database file `deploy/engines/redis.compose.yaml#--save "300 1"` = --save "300 1" file `deploy/engines/redis.compose.yaml#--appendonly no` = --appendonly no	0.35	2,679	5,089	0.32	0.53	200 of 200
SQL Server 2025	3.85	253	618	-	1.22	200 of 200
SQL Server 2025 + DiskANN	3.56	276	695	3.57	1.03	193 of 200
Typesense	4.03	245	588	5.46	0.51	200 of 200
Vespa	1.88	516	915	1.88	0.96	200 of 200
Weaviate	5.16	174	316	-	0.56	200 of 200
pgvector	0.85	1,158	4,102	2.19	0.68	200 of 200
sqlite-vec	1.81	545	529	1.81	1.93	200 of 200

Engines are listed in alphabetical order. The table does not rank them.

A dash means the table has no figure there.

The small markers after an engine name are flags. Hover a marker for its evidence, or read the list below the tables.

Ix index-not-ready The engine did not report a finished index after the load or after the searches.

Evidence behind the flags

Elasticsearch index-not-ready afterLoad: the engine's index state read not ready, 0 of 524 vectors indexed
Elasticsearch index-not-ready afterSearch: the engine's index state read not ready, 0 of 524 vectors indexed

Full results

This report is printed as the run wrote it, except for any sentence a note above it says was left out. This page does not check the engine texts in it. The summary page's facts table gives the label of each fact it uses.

Run 2026-10-05T03:15:56Z (run-all). Command line:

~/gvb-work/lanes/v5-final/src/GenericVectorBuilder.Bench/bin/Release/net10.0/GenericVectorBuilder.Bench.dll run-all --pipeline eshoponweb --queries golden --seed 502 --out ~/ForClaude/GenericVectorBuilder/bench-results

Machine: bench-host, Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz (8 logical CPUs), 62.7 GiB RAM, GPU NVIDIA GeForce RTX 3060, 12288 MiB, Ubuntu 24.04.5 LTS, kernel 6.8.0-142-generic, .NET 10.0.12, load average at start 3.47 2.99 2.95
Data: 524 vectors x 1024 dims, collection gvbbench_eshoponweb. Read READ-ONLY from GenericVectorBuilder.dbo.gvb_eshoponweb in ChunkId order, vectors as native SqlVector<float>, 0.2 s.
Queries: golden: 20 labelled questions from ~/ForClaude/evalkit/questions_golden.json, embedded with qwen3-emb-0.6b (cached in ~/gvb-data/bench-cache/golden-eshoponweb-68df42ca69efa079.json, no embedding calls). Top 10. Throughput at concurrency 1, 8 for 20 s each.
Request speed on a small collection (524 vectors): Measured end to end through each engine's .NET client [Correction 3]; at this size it reflects per-request cost including the client library, not index scaling.
Client CPU per search is the CPU time the test's .NET client itself used for each search, measured in the same pass as the figure beside it.
Ground truth: brute force over every vector in memory, 0.0 s for all 20 queries.
nDCG@10 of the exact answer itself (the ceiling for this embedder): 0.518

engine	index	load rows/s	p50 ms	p95 ms	p99 ms	QPS@1	QPS@8	client CPU ms/search@1	client CPU ms/search@8	recall@10	nDCG@10	RAM	disk
mariadb	VECTOR INDEX (HNSW variant) DISTANCE=cosine, M=16 (no ef_construction setting exists), mhnsw_ef_search=100 per statement (the ef 100 most engines here use, so the search effort matches; MariaDB's own default is 20; recall@10 at ef 100 falls as the set grows (random 1024-dimension vectors, measured 2026-10-04: 0.99 at 524, 0.89 to 0.92 at 2,000; an earlier run gave about 0.09 at 100,000 [Correction 4])), mhnsw_max_cache_size 4G; exact mode = IGNORE INDEX full scan	1,022	0.62	0.71	0.90	1572.8	5969.6	0.48	0.38	1.000	0.518	169.5 MiB	22.01 MiB
weaviate	HNSW maxConnections(M)=16 efConstruction=128, ef=-1 (dynamic: limit x 8 clamped 100..500), cosine, no quantization; approximate only (no exact mode)	821	5.16	10.4	11.6	173.7	315.7	0.56	0.60	1.000	0.518	103.4 MiB	2.88 MiB
redis	HNSW TYPE FLOAT32 M=16 EF_CONSTRUCTION=128, EF_RUNTIME=100 per query, cosine; exact mode = FLAT index built on first exact query	10,625	0.35	0.46	0.69	2679.3	5089.4	0.53	0.36	1.000	0.518	21.26 MiB	0 B
sqlitevec	vec0 brute-force scan, no ANN index (exact), float32, cosine distance, default chunk_size=1024; score = 1 - cosine distance	4,350	1.81	2.01	2.23	545.3	529.5	1.93	1.99	1.000	0.518	-	9.72 MiB
qdrant	exact scan: the builder's sink sends exact=true on every search, so no HNSW graph is used whether or not Qdrant has built one (see the index state)	5,751	0.88	1.00	1.41	1117.7	3284.2	0.73	0.54	1.000	0.518	37.73 MiB	196.08 MiB
oracle	HNSW in-memory neighbor graph NEIGHBORS=16 EFCONSTRUCTION=128, EFSEARCH=100 per query, cosine; exact mode = FETCH EXACT FIRST (full scan); Oracle Free caps itself at 2 CPUs (cpu_count 2 in V$PARAMETER, edition FREE in V$INSTANCE, 8 host CPUs in V$OSSTAT NUM_CPUS; the 2 CPU thread limit is Oracle's documented Free edition limit)	2,070	0.90	1.06	1.80	1088.6	3155.6	0.88	0.65	1.000	0.518	2.14 GiB	0 B
mongodb	vectorSearch index, HNSW maxEdges=16 numEdgeCandidates=128, float32 binData, cosine, numCandidates=20x hits (min 100); exact mode = $vectorSearch exact:true	3,394	1.38	1.71	2.08	699.1	2063.4	0.31	0.28	1.000	0.518	651.9 MiB	0 B
vespa	HNSW float32 tensor, prenormalized-angular (cosine), max-links-per-node=16, neighbors-to-explore-at-insert=128; search targetHits=top, ef=100 via exploreAdditionalHits; exact mode = approximate:false; vectors held in memory	297	1.88	2.30	2.60	516.0	914.6	0.96	0.95	1.000	0.518	2.74 GiB	2.01 MiB
qdrant-hnsw	HNSW m=16 ef_construct=100, hnsw_ef=server default, cosine; indexing_threshold_kb 1 and full_scan_threshold_kb 10 (server defaults are 10,000 each) so a small collection builds and walks its graph	6,667	0.92	1.02	1.46	1078.9	3456.8	0.74	0.52	1.000	0.518	38.14 MiB	164.1 MiB
typesense	HNSW float32 (hnswlib), m=16, ef_construction=128, cosine; search k=top, ef=100; exact mode = filter ordinal:>=0 with flat_search_cutoff; index held in memory	498	4.03	4.34	4.73	245.3	588.2	0.51	0.57	1.000	0.518	118.1 MiB	0 B
chroma	HNSW M=16 ef_construction=128, ef_search=100 (Chroma default), cosine; approximate only (no exact mode)	920	2.03	2.26	2.55	487.9	805.0	0.46	0.46	1.000	0.518	44.77 MiB	414.16 KiB
duckdb	HNSW (vss extension) FLOAT[n] metric=cosine m=16 ef_construction=128, ef_search=100 per connection, persistent (hnsw_enable_experimental_persistence=true, checkpoint_threshold=256MB); exact mode = array_cosine_similarity sequential scan; score = 1 - cosine distance	1,526	3.49	3.85	5.04	283.9	279.4	4.81	4.95	1.000	0.518	-	2.9 MiB
elasticsearch	HNSW float32, no quantization, m=16, ef_construction=128, cosine; search k=top, num_candidates=100; 1 shard, 0 replicas; force-merged to one segment after the load (at 1,024 dimensions a segment under 1,043 vectors gets no graph)	468	1.34	1.72	2.16	716.0	2652.9	0.47	0.49	1.000	0.518	2.5 GiB	2.39 MiB
sql-diskann	DiskANN (preview) via VECTOR_SEARCH, cosine, build {"StartId":"306", "L":"48", "M":"8", "R":"48"}; the exact mode scans the same table	612	3.56	4.02	5.14	275.5	694.8	1.03	1.10	0.965	0.526	530.2 MiB	4.52 MiB
pgvector	HNSW vector_cosine_ops m=16 ef_construction=128, hnsw.ef_search=100 per query, float32 vector(n), cosine; exact mode = same query with index scans off (sequential scan)	611	0.85	1.00	1.27	1158.2	4102.0	0.68	0.54	1.000	0.518	100.7 MiB	7.59 MiB
sql	exact VECTOR_DISTANCE cosine, no vector index (full scan)	637	3.85	4.44	5.81	253.5	618.2	1.22	1.21	1.000	0.518	527.3 MiB	5.15 MiB
milvus	HNSW M=16 efConstruction=128, ef=100, metric COSINE, Strong consistency searches; approximate only (no exact mode)	1,181	2.21	2.74	3.59	431.6	1275.7	0.54	0.63	1.000	0.518	222.2 MiB	10.86 MiB
clickhouse	vector_similarity HNSW cosineDistance, quantization bf16, M=16 ef_construction=128, hnsw_candidate_list_size_for_search=256, rescoring off; exact mode = full scan with skip indexes off	2,348	4.73	5.63	7.41	204.1	427.2	0.83	1.05	0.985	0.532	728.2 MiB	906.61 MiB
opensearch	faiss HNSW float32, no compression, m=16, ef_construction=128, cosinesimil; search k=top, ef_search=100; 1 shard, 0 replicas; graph built at any segment size (approximate_threshold=0); force-merged to one segment after the load	409	2.02	2.23	2.71	486.3	1479.2	0.47	0.50	1.000	0.518	2.6 GiB	9.47 MiB

Details per target

MariaDB mariadb

Engine: MariaDB 11.8.9 (InnoDB + VECTOR INDEX) (compose)
Index: VECTOR INDEX (HNSW variant) DISTANCE=cosine, M=16 (no ef_construction setting exists), mhnsw_ef_search=100 per statement (the ef 100 most engines here use, so the search effort matches; MariaDB's own default is 20; recall@10 at ef 100 falls as the set grows (random 1024-dimension vectors, measured 2026-10-04: 0.99 at 524, 0.89 to 0.92 at 2,000; an earlier run gave about 0.09 at 100,000 [Correction 4])), mhnsw_max_cache_size 4G; exact mode = IGNORE INDEX full scan
Load: 524 rows in batches of 1000, 0.5 s of upserts (1,022 rows/s); count matched 0.0 s after the last upsert; index step 0.5 s (VECTOR INDEX is maintained inside every INSERT, nothing to build; confirmed after 2 poll(s) in 0.5 s (poll 1 of 2 said: not ready: a search at mhnsw_ef_search 100 returned only 403 of 524 requested rows through the index (EXPLAIN key 'vec_idx') (information_schema lists vec_idx as INDEX_TYPE VECTOR, EXPLAIN of the default search uses key vec_idx, the server applied mhnsw_ef_search 100 (asked for 100, read back from the server), a search at that effort returned 403 of 524 requested rows through the index; MariaDB has no per-index row count (the graph is a hidden InnoDB table), so indexed vectors are not reported)): information_schema lists vec_idx as INDEX_TYPE VECTOR, EXPLAIN of the default search uses key vec_idx, the server applied mhnsw_ef_search 100 (asked for 100, read back from the server), a search at that effort returned 520 of 524 requested rows through the index; MariaDB has no per-index row count (the graph is a hidden InnoDB table), so indexed vectors are not reported)
Search: 31456 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.48 ms, 8 searchers 0.38 ms
Exact mode: 37,291 searches, p50 1.58 ms, p95 1.71 ms, recall 1.000
RAM: 169.5 MiB (docker stats); disk: 22.01 MiB added by this load (182.79 MiB (whole engine data folder), 160.78 MiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started mariadb-bench.compose.yaml with every container created on CPUs 2-3,6-7: gvbbench-mariadb cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, ? of 524 indexed (information_schema lists vec_idx as INDEX_TYPE VECTOR, EXPLAIN of the default search uses key vec_idx, the server applied mhnsw_ef_search 100 (asked for 100, read back from the server), a search at that effort returned 520 of 524 requested rows through the index; MariaDB has no per-index row count (the graph is a hidden InnoDB table), so indexed vectors are not reported). Durability: innodb_flush_log_at_trx_commit=2 (mariadb.compose.yaml): the InnoDB redo log is written to the operating system at every commit but fsynced about once a second, so a crash of the mariadbd process loses nothing, while an operating-system crash or power cut can lose the last second of commits; innodb_doublewrite is on (default), the binary log is off, and the vector graph is an InnoDB table under the same log (settings read from the running server with SHOW VARIABLES; the crash behaviour is InnoDB's documented behaviour for this setting and was not tested, because gvb-mariadb is shared and stays up).
Load average 3.25 2.96 2.94 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 7,497 searches in 5.0 s, exact 3,089 searches in 5.0 s, default@8 30,091 searches in 5.0 s.
Settle: settled after 0.3 s and 400 searches (0 failed); p50 of the last windows of 100: 0.59, 0.59, 0.59 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 3,123 searches in 2.0 s: p50 0.628 ms against the settled p50 0.586 ms, 7% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:16:23.746Z to 2026-10-05T03:16:43.747Z (20.0 s), 31,456 searches, 0 failed, p50 0.623 ms, mean 0.634 ms, p99 0.899 ms, 1572.8 QPS (1000/QPS 0.636 ms).
Pass exact after default@1: 2026-10-05T03:16:43.899Z to 2026-10-05T03:17:43.900Z (60.0 s), 37,291 searches, 0 failed, p50 1.580 ms, mean 1.607 ms, p99 2.159 ms, 621.5 QPS (1000/QPS 1.609 ms).
Pass default@8 after exact: 2026-10-05T03:17:43.940Z to 2026-10-05T03:18:03.941Z (20.0 s), 119,398 searches, 0 failed, p50 1.300 ms, mean 1.338 ms, p99 2.455 ms, 5969.6 QPS (1000/QPS 0.168 ms).
Passes in the order run: default@1, exact, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 44,260 sent, 0 failed (warmupErrors). Index after the searches: ready, ? of 524 indexed (information_schema lists vec_idx as INDEX_TYPE VECTOR, EXPLAIN of the default search uses key vec_idx, the server applied mhnsw_ef_search 100 (asked for 100, read back from the server), a search at that effort returned 520 of 524 requested rows through the index; MariaDB has no per-index row count (the graph is a hidden InnoDB table), so indexed vectors are not reported).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvbbench-mariadb (d78c2651a20a) on network gvbbench-mariadb_default at container-ip:3306, not through docker-proxy localhost:13306. Open after the passes: container-ip:3306 x8 (this target), localhost:1433 x2 (not this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvbbench-mariadb: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvbbench-mariadb: 14 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.13 during, client CPU 0.483 ms per search; exact 3592/3592 MHz, performance, outside load 0.12 before the warm-up, 0.12 during, client CPU 0.502 ms per search; default@8 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.06 during, client CPU 0.382 ms per search.

Weaviate weaviate

Engine: Weaviate 1.39.8 (single node, REST + GraphQL) (compose)
Index: HNSW maxConnections(M)=16 efConstruction=128, ef=-1 (dynamic: limit x 8 clamped 100..500), cosine, no quantization; approximate only (no exact mode)
Load: 524 rows in batches of 1000, 0.6 s of upserts (821 rows/s); count matched 0.0 s after the last upsert; index step 0.0 s (HNSW is updated inside every batch, nothing to build; confirmed in 0.0 s: shard Dv6Hedvh8BDL vectorIndexingStatus READY, vectorQueueLength 0, node status objectCount 0 (refreshed only when the memtable is flushed, so it lags a minute and does not decide readiness), schema shard Dv6Hedvh8BDL status READY, Aggregate count 524, Aggregate nearVector with objectLimit 524 reached 524, Weaviate reports no count of vectors in the HNSW index, so indexed vectors are not reported)
Search: 3474 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.56 ms, 8 searchers 0.60 ms
RAM: 103.4 MiB (docker stats); disk: 2.88 MiB added by this load (4.94 MiB (whole engine data folder), 2.06 MiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started weaviate.compose.yaml with every container created on CPUs 2-3,6-7: gvb-weaviate cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, ? of 524 indexed (shard Dv6Hedvh8BDL vectorIndexingStatus READY, vectorQueueLength 0, node status objectCount 0 (refreshed only when the memtable is flushed, so it lags a minute and does not decide readiness), schema shard Dv6Hedvh8BDL status READY, Aggregate count 524, Aggregate nearVector with objectLimit 524 reached 524, Weaviate reports no count of vectors in the HNSW index, so indexed vectors are not reported). Durability: Weaviate 1.39.8 defaults, weaviate.compose.yaml sets no persistence variable [Correction 1]: every object is appended to the LSM write-ahead log with a plain write and no fsync, and the log is fsynced only when its memtable is flushed, 60 seconds after the last write (PERSISTENCE_MEMTABLES_FLUSH_IDLE_AFTER_SECONDS default; measured with strace: 2,080 writes into the objects log during a 2,000-object load, the first fsync 60 s after the last write), so a power cut can lose the last minute of writes; the HNSW commit log is buffered inside the process (77 writes for 2,000 vectors), so a killed process loses the newest vectors from the vector index while their objects survive (measured with docker kill, which is SIGKILL, one second after the load and a restart, two runs each: 0 to 1 of 50, 264 to 267 of 300 and 1,992 to 1,997 of 2,000 stored objects were still reachable through a vector search).
Load average 2.91 2.90 2.91 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 852 searches in 5.0 s, default@8 1,580 searches in 5.0 s.
Settle: settled after 1.7 s and 300 searches (0 failed); p50 of the last windows of 100: 5.18, 5.16, 5.16 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 350 searches in 2.0 s: p50 5.151 ms against the settled p50 5.163 ms, 0% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:18:42.105Z to 2026-10-05T03:19:02.107Z (20.0 s), 3,474 searches, 0 failed, p50 5.160 ms, mean 5.755 ms, p99 11.642 ms, 173.7 QPS (1000/QPS 5.758 ms).
Pass default@8 after default@1: 2026-10-05T03:19:02.181Z to 2026-10-05T03:19:22.195Z (20.0 s), 6,319 searches, 0 failed, p50 23.959 ms, mean 25.328 ms, p99 53.405 ms, 315.7 QPS (1000/QPS 3.167 ms).
Passes in the order run: default@1, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 3,122 sent, 0 failed (warmupErrors). Index after the searches: ready, ? of 524 indexed (shard Dv6Hedvh8BDL vectorIndexingStatus READY, vectorQueueLength 0, node status objectCount 0 (refreshed only when the memtable is flushed, so it lags a minute and does not decide readiness), schema shard Dv6Hedvh8BDL status READY, Aggregate count 524, Aggregate nearVector with objectLimit 524 reached 524, Weaviate reports no count of vectors in the HNSW index, so indexed vectors are not reported).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-weaviate (16135b2cb6ff) on network gvb-weaviate_default at container-ip:8080, not through docker-proxy localhost:8085. Open after the passes: container-ip:8080 x8 (this target), localhost:1433 x2 (not this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-weaviate: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-weaviate: 10 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3587/3565 MHz, performance, outside load 0.11 before the warm-up, 0.11 during, client CPU 0.564 ms per search; default@8 3564/3565 MHz, performance, outside load 0.11 before the warm-up, 0.11 during, client CPU 0.602 ms per search.

Redis redis

Engine: Redis 8.10.2 (query engine, HASH + vector index) (compose)
Index: HNSW TYPE FLOAT32 M=16 EF_CONSTRUCTION=128, EF_RUNTIME=100 per query, cosine; exact mode = FLAT index built on first exact query
Load: 524 rows in batches of 1000, 0.0 s of upserts (10,625 rows/s); count matched 0.0 s after the last upsert; index step 0.0 s (HNSW index finished after 0.0 s of waiting: FT.INFO indexing 0, percent_indexed 1, hash_indexing_failures 0, flat_buffer_size 0, num_docs 524, hashes counted with SCAN under gvb_gvbbench_eshoponweb: 524)
Search: 53586 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.53 ms, 8 searchers 0.36 ms
Exact mode: 176,574 searches, p50 0.32 ms, p95 0.43 ms, recall 1.000
RAM: 21.26 MiB (docker stats); disk: 0 B added by this load (89 B (whole engine data folder), 89 B before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started redis.compose.yaml with every container created on CPUs 2-3,6-7: gvb-redis cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (FT.INFO indexing 0, percent_indexed 1, hash_indexing_failures 0, flat_buffer_size 0, num_docs 524, hashes counted with SCAN under gvb_gvbbench_eshoponweb: 524). Durability: save "300 1" and appendonly no (redis.compose.yaml): an RDB snapshot is written every 5 minutes if at least one key changed, and on a clean stop; there is no append-only log, so a crash loses every write since the last snapshot (up to 5 minutes plus the time a snapshot takes; measured with docker kill, which is SIGKILL, right after a 2,000-vector load: none of the 2,000 hashes were there after the restart, and the restart loaded an older snapshot that still held keys of a collection that had been dropped since).
Load average 2.84 2.86 2.89 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 13,214 searches in 5.0 s, exact 14,176 searches in 5.0 s, default@8 25,525 searches in 5.0 s.
Settle: settled after 0.3 s and 700 searches (0 failed); p50 of the last windows of 100: 0.35, 0.34, 0.35 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 5,539 searches in 2.0 s: p50 0.343 ms against the settled p50 0.346 ms, 1% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:19:47.864Z to 2026-10-05T03:20:07.864Z (20.0 s), 53,586 searches, 0 failed, p50 0.352 ms, mean 0.372 ms, p99 0.691 ms, 2679.3 QPS (1000/QPS 0.373 ms).
Pass exact after default@1: 2026-10-05T03:20:07.934Z to 2026-10-05T03:21:07.934Z (60.0 s), 176,574 searches, 0 failed, p50 0.320 ms, mean 0.338 ms, p99 0.630 ms, 2942.9 QPS (1000/QPS 0.340 ms).
Pass default@8 after exact: 2026-10-05T03:21:08.107Z to 2026-10-05T03:21:28.109Z (20.0 s), 101,797 searches, 0 failed, p50 1.537 ms, mean 1.570 ms, p99 2.242 ms, 5089.4 QPS (1000/QPS 0.196 ms).
Passes in the order run: default@1, exact, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 59,214 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (FT.INFO indexing 0, percent_indexed 1, hash_indexing_failures 0, flat_buffer_size 0, num_docs 524, hashes counted with SCAN under gvb_gvbbench_eshoponweb: 524).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-redis (989f19e9cdad) on network gvb-redis_default at container-ip:6379, not through docker-proxy localhost:6379. Open after the passes: localhost:1433 x2 (not this target), container-ip:6379 x1 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-redis: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-redis: 6 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.09 before the warm-up, 0.10 during, client CPU 0.528 ms per search; exact 3492/3492 MHz, performance, outside load 0.09 before the warm-up, 0.10 during, client CPU 0.511 ms per search; default@8 3492/3492 MHz, performance, outside load 0.10 before the warm-up, 0.08 during, client CPU 0.357 ms per search.

sqlite-vec sqlitevec

Engine: SQLite 3.53.3 + sqlite-vec 0.1.7-alpha.2.1 (vec0, embedded, in process) (embedded)
Index: vec0 brute-force scan, no ANN index (exact), float32, cosine distance, default chunk_size=1024; score = 1 - cosine distance
Load: 524 rows in batches of 1000, 0.1 s of upserts (4,350 rows/s); count matched 0.0 s after the last upsert; index step 0.0 s (nothing to build, every search scans all vectors; checked in 0.00 s: no index, exact scan by design: gvb_gvbbench_eshoponweb is a vec0 virtual table holding 524 vectors and every search compares all of them (EXPLAIN QUERY PLAN: SCAN gvb_gvbbench_eshoponweb VIRTUAL TABLE INDEX 0:3{___}___ | USE TEMP B-TREE FOR ORDER BY))
Search: 10906 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 1.93 ms, 8 searchers 1.99 ms
Exact mode: 32,665 searches, p50 1.81 ms, p95 2.01 ms, recall 1.000
RAM: in this process, not measured; disk: 9.72 MiB added by this load (9.72 MiB (engine data folder), 0 B before)
Index after the load: ready, ? of 524 indexed (no index, exact scan by design: gvb_gvbbench_eshoponweb is a vec0 virtual table holding 524 vectors and every search compares all of them (EXPLAIN QUERY PLAN: SCAN gvb_gvbbench_eshoponweb VIRTUAL TABLE INDEX 0:3{___}___ | USE TEMP B-TREE FOR ORDER BY)). Durability: PRAGMA journal_mode=WAL and PRAGMA synchronous=NORMAL (set by this sink when it opens the file): each commit is appended to the -wal file and handed to the operating system, but the WAL is fsynced only when SQLite checkpoints it (measured with strace: 40 single-record commits caused 3 WAL fsyncs), so a crash of the process loses nothing (measured with kill -9 and a reopen: all 50, 300 and 2,000 rows were there), while an operating-system crash or power cut can lose the newest commits since the last checkpoint and leaves the database consistent.
Load average 3.07 2.81 2.86 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: exact 2,694 searches in 5.0 s, default@1 2,709 searches in 5.0 s, default@8 2,605 searches in 5.0 s.
Settle: settled after 0.6 s and 300 searches (0 failed); p50 of the last windows of 100: 1.86, 1.81, 1.82 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 1,086 searches in 2.0 s: p50 1.816 ms against the settled p50 1.819 ms, 0% apart (limit 15%).
Pass exact after settle: 2026-10-05T03:21:47.489Z to 2026-10-05T03:22:47.490Z (60.0 s), 32,665 searches, 0 failed, p50 1.812 ms, mean 1.834 ms, p99 2.229 ms, 544.4 QPS (1000/QPS 1.837 ms).
Pass default@1 after exact: 2026-10-05T03:22:47.558Z to 2026-10-05T03:23:07.559Z (20.0 s), 10,906 searches, 0 failed, p50 1.809 ms, mean 1.831 ms, p99 2.226 ms, 545.3 QPS (1000/QPS 1.834 ms).
Pass default@8 after default@1: 2026-10-05T03:23:07.607Z to 2026-10-05T03:23:27.621Z (20.0 s), 10,597 searches, 0 failed, p50 14.784 ms, mean 15.101 ms, p99 17.896 ms, 529.5 QPS (1000/QPS 1.889 ms).
Passes in the order run: exact, default@1, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 9,454 sent, 0 failed (warmupErrors). Index after the searches: ready, ? of 524 indexed (no index, exact scan by design: gvb_gvbbench_eshoponweb is a vec0 virtual table holding 524 vectors and every search compares all of them (EXPLAIN QUERY PLAN: SCAN gvb_gvbbench_eshoponweb VIRTUAL TABLE INDEX 0:3{___}___ | USE TEMP B-TREE FOR ORDER BY)).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: in this process (embedded), no network: no network address. No open connection seen (no open TCP connection was found).
CPU pinning: none: an embedded engine runs inside the benchmark client process, so it shares the client CPUs, CPUs 0-1,4-5.
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): exact 3600/3592 MHz, performance, outside load 0.13 before the warm-up, 0.12 during, client CPU 1.932 ms per search; default@1 3598/3592 MHz, performance, outside load 0.12 before the warm-up, 0.12 during, client CPU 1.931 ms per search; default@8 3598/3592 MHz, performance, outside load 0.12 before the warm-up, 0.12 during, client CPU 1.987 ms per search.

Qdrant (exact) qdrant

Engine: Qdrant 1.17.0 in container gvb-qdrant (image qdrant/qdrant:v1.17.0@sha256:f1c7272cdac52b38c1a0e89313922d940ba50afd90d593a1605dbbc214e66ffb; cpuset 2-3,6-7 from its creation; 3 search thread(s)) (compose)
Index: exact scan: the builder's sink sends exact=true on every search, so no HNSW graph is used whether or not Qdrant has built one (see the index state)
Load: 524 rows in batches of 1000, 0.1 s of upserts (5,751 rows/s); count matched 0.0 s after the last upsert; index step 1.0 s (status Green, 0 of 524 vectors in HNSW segments (2 segments), waited 1.0 s)
Search: 22354 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.73 ms, 8 searchers 0.54 ms
RAM: 37.73 MiB (docker stats); disk: 196.08 MiB (collection folder)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started qdrant.compose.yaml with every container created on CPUs 2-3,6-7: gvb-qdrant cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 0 of 524 indexed (status Green, optimizer ok, indexed_vectors_count 0 of 524 points, 2 segments, indexing_threshold_kb 10,000, full_scan_threshold_kb 10,000; no index used, exact scan by design (the builder's sink sends exact=true on every search); no graph was built; searches counted since the collection was created: unfiltered_hnsw 0, unfiltered_plain 0, unfiltered_exact 0). Durability: What was measured (strace -f on the Qdrant server process, 30 single-point REST upserts per setting, every sync call timed against the request that caused it): with wait=true each upsert had exactly one msync(MS_SYNC) of the write-ahead-log segment inside the request, before the reply (30 of 30); with wait=false the 30 upserts were acknowledged within 0.26 s with no sync call, and the first WAL msync (one call covering all 30 records) came 2.7 s after the last reply, followed by the segment-file flushes. So the log is flushed to disk under both settings, but with wait=false the flush comes after the acknowledgement: an operating-system crash or power cut in that gap loses acknowledged writes, while a crash of the Qdrant process alone should not, because the bytes are already in the kernel's page cache (inferred, not tested). Every upsert here is sent with wait=true in batches of 256 over gRPC; the strace used one point per request, so one flush per batch is inferred, not measured. Segment files are flushed every 5 s; log segments 32 MB, 0 created ahead. /qdrant/config/config.yaml in container gvb-qdrant (the image's own file; its storage keys are listed) sets: storage.collection.quantization = null, storage.collection.replication_factor = 1, storage.collection.vectors.on_disk = null, storage.collection.write_consistency_factor = 1, storage.hnsw_index.ef_construct = 100, storage.hnsw_index.full_scan_threshold_kb = 10000, storage.hnsw_index.m = 16, storage.hnsw_index.max_indexing_threads = 0, storage.hnsw_index.on_disk = false, storage.hnsw_index.payload_m = null, storage.max_collections = null, storage.node_type = Normal, storage.on_disk_payload = true, storage.optimizers.default_segment_number = 0, storage.optimizers.deleted_threshold = 0.2, storage.optimizers.flush_interval_sec = 5, storage.optimizers.indexing_threshold_kb = 10000, storage.optimizers.max_optimization_threads = null, storage.optimizers.max_segment_size_kb = null, storage.optimizers.vacuum_min_vector_number = 1000, storage.performance.max_search_threads = 0, storage.performance.optimizer_cpu_budget = 0, storage.performance.update_rate_limit = null, storage.shard_transfer_method = null, storage.snapshots_config.snapshots_storage = local, storage.snapshots_path = ./snapshots, storage.storage_path = ./storage, storage.temp_path = null, storage.update_concurrency = null, storage.wal.wal_capacity_mb = 32, storage.wal.wal_segments_ahead = 0; no QDRANT__ environment overrides in the server process. Not tested by cutting power; whether the disk's own write cache reaches the media was not checked..
Load average 1.33 2.22 2.63 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 5,416 searches in 5.0 s, default@8 16,460 searches in 5.0 s.
Settle: settled after 0.3 s and 300 searches (0 failed); p50 of the last windows of 100: 0.90, 0.88, 0.87 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 2,238 searches in 2.0 s: p50 0.882 ms against the settled p50 0.881 ms, 0% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:23:47.676Z to 2026-10-05T03:24:07.677Z (20.0 s), 22,354 searches, 0 failed, p50 0.882 ms, mean 0.893 ms, p99 1.412 ms, 1117.7 QPS (1000/QPS 0.895 ms).
Pass default@8 after default@1: 2026-10-05T03:24:07.706Z to 2026-10-05T03:24:27.707Z (20.0 s), 65,689 searches, 0 failed, p50 2.352 ms, mean 2.433 ms, p99 4.190 ms, 3284.2 QPS (1000/QPS 0.304 ms).
Passes in the order run: default@1, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 24,454 sent, 0 failed (warmupErrors). Index after the searches: ready, 0 of 524 indexed (status Green, optimizer ok, indexed_vectors_count 0 of 524 points, 2 segments, indexing_threshold_kb 10,000, full_scan_threshold_kb 10,000; no index used, exact scan by design (the builder's sink sends exact=true on every search); no graph was built; searches counted since the collection was created: unfiltered_hnsw 0, unfiltered_plain 224,994, unfiltered_exact 0).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-qdrant (87511a708990) on network gvb-qdrant_default at container-ip:6334, not through docker-proxy localhost:16334; container gvb-qdrant (87511a708990) on network gvb-qdrant_default at container-ip:6333, not through docker-proxy localhost:16333. Open after the passes: container-ip:6334 x1 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-qdrant: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-qdrant: 24 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.10 before the warm-up, 0.09 during, client CPU 0.735 ms per search; default@8 3492/3492 MHz, performance, outside load 0.09 before the warm-up, 0.07 during, client CPU 0.544 ms per search.

Oracle 23ai Free oracle

Engine: Oracle AI Database Free 23.26 (23ai line, VECTOR FLOAT32) (compose)
Index: HNSW in-memory neighbor graph NEIGHBORS=16 EFCONSTRUCTION=128, EFSEARCH=100 per query, cosine; exact mode = FETCH EXACT FIRST (full scan); Oracle Free caps itself at 2 CPUs (cpu_count 2 in V$PARAMETER, edition FREE in V$INSTANCE, 8 host CPUs in V$OSSTAT NUM_CPUS; the 2 CPU thread limit is Oracle's documented Free edition limit)
Load: 524 rows in batches of 1000, 0.3 s of upserts (2,070 rows/s); count matched 0.0 s after the last upsert; index step 3.3 s (HNSW graph holds 524 of 524 rows, change log waiting: 0 inserts and 0 deletes, USER_INDEXES status VALID, plan of the default search: VECTOR INDEX HNSW SCAN > TABLE ACCESS BY INDEX ROWID, index used by 0 queries so far; Oracle Free caps itself at 2 CPUs (cpu_count 2 in V$PARAMETER, edition FREE in V$INSTANCE, 8 host CPUs in V$OSSTAT NUM_CPUS; the 2 CPU thread limit is Oracle's documented Free edition limit); graph rebuilt in 2.0 s)
Search: 21772 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.88 ms, 8 searchers 0.65 ms
Exact mode: 24,057 searches, p50 2.44 ms, p95 2.83 ms, recall 1.000
RAM: 2.14 GiB (docker stats); disk: 0 B added by this load (6.88 GiB (whole engine data folder), 6.88 GiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started oracle.compose.yaml with every container created on CPUs 2-3,6-7: gvb-oracle cpuset 2-3,6-7, gvb-oracle-seed cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (HNSW graph holds 524 of 524 rows, change log waiting: 0 inserts and 0 deletes, USER_INDEXES status VALID, plan of the default search: VECTOR INDEX HNSW SCAN > TABLE ACCESS BY INDEX ROWID, index used by 0 queries so far; Oracle Free caps itself at 2 CPUs (cpu_count 2 in V$PARAMETER, edition FREE in V$INSTANCE, 8 host CPUs in V$OSSTAT NUM_CPUS; the 2 CPU thread limit is Oracle's documented Free edition limit)). Durability: By these settings a committed row should survive a crash or power loss. The sink uses a plain COMMIT and commit_logging, commit_wait and commit_write are unset in the database, so every commit waits for its redo to be written. Measured 2026-10-04: 50 separate client commits raised V$SYSSTAT 'redo synch writes' by 55 (the 50 commits plus the CREATE and DROP of the probe table), and the log writer and the datafile writer hold their files open with O_DSYNC (open flags 02110002, filesystemio_options none). The database runs NOARCHIVELOG (V$DATABASE.LOG_MODE), so redo serves crash recovery only and there is no point-in-time restore. The HNSW graph lives in the 768 MB vector memory pool (oracle-init/01-vector-memory.sh) and is not the durable copy; the table is. Not tested by cutting power; whether the disk's own write cache reaches the media was not checked. CPU: Oracle Free caps itself at 2 CPUs (measured 2026-10-04: cpu_count 2 in V$PARAMETER, edition FREE in V$INSTANCE, 8 host CPUs in V$OSSTAT NUM_CPUS; the 2 CPU thread limit is Oracle's documented Free edition limit; this sink reads the live value when the index state is read)..
Load average 3.04 2.58 2.73 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@8 15,261 searches in 5.5 s, exact 1,968 searches in 5.0 s, default@1 5,404 searches in 5.0 s.
Settle: settled after 0.3 s and 300 searches (0 failed); p50 of the last windows of 100: 0.87, 0.89, 0.89 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 2,182 searches in 2.0 s: p50 0.895 ms against the settled p50 0.890 ms, 1% apart (limit 15%).
Pass default@8 after settle: 2026-10-05T03:25:04.348Z to 2026-10-05T03:25:24.349Z (20.0 s), 63,115 searches, 0 failed, p50 1.581 ms, mean 2.532 ms, p99 3.404 ms, 3155.6 QPS (1000/QPS 0.317 ms).
Pass exact after default@8: 2026-10-05T03:25:24.421Z to 2026-10-05T03:26:24.422Z (60.0 s), 24,057 searches, 0 failed, p50 2.435 ms, mean 2.492 ms, p99 3.924 ms, 400.9 QPS (1000/QPS 2.494 ms).
Pass default@1 after exact: 2026-10-05T03:26:24.460Z to 2026-10-05T03:26:44.460Z (20.0 s), 21,772 searches, 0 failed, p50 0.895 ms, mean 0.917 ms, p99 1.799 ms, 1088.6 QPS (1000/QPS 0.919 ms).
Passes in the order run: default@8, exact, default@1; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 25,175 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (HNSW graph holds 524 of 524 rows, change log waiting: 0 inserts and 0 deletes, USER_INDEXES status VALID, plan of the default search: VECTOR INDEX HNSW SCAN > TABLE ACCESS BY INDEX ROWID, index used by 108074 queries so far; Oracle Free caps itself at 2 CPUs (cpu_count 2 in V$PARAMETER, edition FREE in V$INSTANCE, 8 host CPUs in V$OSSTAT NUM_CPUS; the 2 CPU thread limit is Oracle's documented Free edition limit)).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-oracle (1d59e41e9fe6) on network gvb-oracle_default at container-ip:1521, not through docker-proxy localhost:1521. Open after the passes: container-ip:1521 x15 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-oracle: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-oracle: 86 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@8 3492/3492 MHz, performance, outside load 0.15 before the warm-up, 0.12 during, client CPU 0.646 ms per search; exact 3492/3492 MHz, performance, outside load 0.13 before the warm-up, 0.12 during, client CPU 0.952 ms per search; default@1 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.11 during, client CPU 0.879 ms per search.

MongoDB Atlas Local mongodb

Engine: MongoDB 8.0.32 Atlas Local (mongod + mongot Vector Search) (compose)
Index: vectorSearch index, HNSW maxEdges=16 numEdgeCandidates=128, float32 binData, cosine, numCandidates=20x hits (min 100); exact mode = $vectorSearch exact:true
Load: 524 rows in batches of 1000, 0.2 s of upserts (3,394 rows/s); count matched 1.8 s after the last upsert; index step 1.1 s (index status READY, queryable True; mongot holds 524 of 524 documents in 4 segment(s), 4 searched through the HNSW graph (Approximate); wait took 1.1 s)
Search: 13982 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.31 ms, 8 searchers 0.28 ms
Exact mode: 48,020 searches, p50 1.23 ms, p95 1.41 ms, recall 1.000
RAM: 651.9 MiB (docker stats); disk: 0 B added by this load (1.3 GiB (whole engine data folder), 1.3 GiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started mongodb.compose.yaml with every container created on CPUs 2-3,6-7: gvb-mongodb cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (index status READY, queryable True; mongot holds 524 of 524 documents in 4 segment(s), 4 searched through the HNSW graph (Approximate)). Durability: Acknowledged writes are journaled before the acknowledgement. The sink sets no write concern, so the server default applies: getDefaultRWConcern gives w majority and the one-member replica set (--replSet gvbmongo in the image) has writeConcernMajorityJournalDefault true, with WiredTiger journaling on (journalCommitInterval 100 ms is only the interval for unacknowledged work). Measured 2026-10-04: 30 acknowledged single-document inserts raised WiredTiger 'log sync operations' by 30 and strace showed fdatasync on /data/db/journal/WiredTigerLog files. A crash loses no acknowledged write. mongot's search index is not part of that promise: it follows the collection asynchronously and is rebuilt from it..
Load average 1.85 2.49 2.69 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 1,799 searches in 5.0 s, default@8 5,736 searches in 5.0 s, exact 3,506 searches in 5.0 s.
Settle: settled after 0.6 s and 400 searches (0 failed); p50 of the last windows of 100: 1.39, 1.36, 1.39 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 1,352 searches in 2.0 s: p50 1.404 ms against the settled p50 1.386 ms, 1% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:27:16.700Z to 2026-10-05T03:27:36.700Z (20.0 s), 13,982 searches, 0 failed, p50 1.380 ms, mean 1.428 ms, p99 2.083 ms, 699.1 QPS (1000/QPS 1.430 ms).
Pass default@8 after default@1: 2026-10-05T03:27:36.724Z to 2026-10-05T03:27:56.727Z (20.0 s), 41,275 searches, 0 failed, p50 3.709 ms, mean 3.874 ms, p99 7.510 ms, 2063.4 QPS (1000/QPS 0.485 ms).
Pass exact after default@8: 2026-10-05T03:27:56.764Z to 2026-10-05T03:28:56.764Z (60.0 s), 48,020 searches, 0 failed, p50 1.226 ms, mean 1.247 ms, p99 1.763 ms, 800.3 QPS (1000/QPS 1.249 ms).
Passes in the order run: default@1, default@8, exact; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 12,853 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (index status READY, queryable True; mongot holds 524 of 524 documents in 4 segment(s), 4 searched through the HNSW graph (Approximate)).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-mongodb (55a23265ddaf) on network gvb-mongodb_default at container-ip:27017, not through docker-proxy localhost:27017. Open after the passes: container-ip:27017 x10 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-mongodb: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-mongodb: 208 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.17 before the warm-up, 0.26 during, client CPU 0.315 ms per search; default@8 3492/3492 MHz, performance, outside load 0.21 before the warm-up, 0.18 during, client CPU 0.284 ms per search; exact 3492/3492 MHz, performance, outside load 0.20 before the warm-up, 0.21 during, client CPU 0.307 ms per search.

Vespa vespa

Engine: Vespa 8.754.14 (tensor attribute + HNSW) (compose)
Index: HNSW float32 tensor, prenormalized-angular (cosine), max-links-per-node=16, neighbors-to-explore-at-insert=128; search targetHits=top, ef=100 via exploreAdditionalHits; exact mode = approximate:false; vectors held in memory
Load: 524 rows in batches of 1000, 1.8 s of upserts (297 rows/s); count matched 0.0 s after the last upsert; index step 0.1 s (nothing to build, Vespa inserts into the HNSW graph while writing; ready after 0.1 s: HNSW graph returns 524 of 524 vectors: totalCount 524, coverage full True, nearestNeighbor approximate:true with targetHits above the count: has_index True, algorithm "index top k", top_k_hits 524; the graph is updated while each write is applied, so there is no later build step)
Search: 10320 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.96 ms, 8 searchers 0.95 ms
Exact mode: 30,680 searches, p50 1.88 ms, p95 2.38 ms, recall 1.000
RAM: 2.74 GiB (docker stats); disk: 2.01 MiB added by this load (1.76 GiB (whole engine data folder), 1.75 GiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started vespa.compose.yaml with every container created on CPUs 2-3,6-7: gvb-vespa cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (HNSW graph returns 524 of 524 vectors: totalCount 524, coverage full True, nearestNeighbor approximate:true with targetHits above the count: has_index True, algorithm "index top k", top_k_hits 524; the graph is updated while each write is applied, so there is no later build step). Durability: Vespa's transaction log server fsyncs after each commit: searchlib.translogserver usefsync=true, and an operation is searchable when it is acknowledged: proton documentdb visibilitydelay=0. Neither is overridden by this sink or by the services.xml it deploys; VespaReadinessTests reads both from the live config server. After a crash the node replays the transaction log over its last flushed data and rebuilds the in-memory HNSW graph. By those settings an acknowledged write survives a crash; this is read from the settings, not shown by pulling power. One node and min-redundancy 1, so a lost disk loses the data..
Load average 5.10 2.95 2.80 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@8 1,512 searches in 5.0 s, exact 977 searches in 5.0 s, default@1 1,437 searches in 5.0 s.
Settle: settled after 1.5 s and 500 searches (0 failed); p50 of the last windows of 100: 2.66, 2.60, 2.72 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 681 searches in 2.0 s: p50 2.817 ms against the settled p50 2.659 ms, 6% apart (limit 15%).
Pass default@8 after settle: 2026-10-05T03:31:10.589Z to 2026-10-05T03:31:30.594Z (20.0 s), 18,298 searches, 0 failed, p50 8.332 ms, mean 8.743 ms, p99 18.099 ms, 914.6 QPS (1000/QPS 1.093 ms).
Pass exact after default@8: 2026-10-05T03:31:30.671Z to 2026-10-05T03:32:30.672Z (60.0 s), 30,680 searches, 0 failed, p50 1.884 ms, mean 1.953 ms, p99 2.802 ms, 511.3 QPS (1000/QPS 1.956 ms).
Pass default@1 after exact: 2026-10-05T03:32:30.738Z to 2026-10-05T03:32:50.738Z (20.0 s), 10,320 searches, 0 failed, p50 1.882 ms, mean 1.935 ms, p99 2.603 ms, 516.0 QPS (1000/QPS 1.938 ms).
Passes in the order run: default@8, exact, default@1; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 5,167 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (HNSW graph returns 524 of 524 vectors: totalCount 524, coverage full True, nearestNeighbor approximate:true with targetHits above the count: has_index True, algorithm "index top k", top_k_hits 524; the graph is updated while each write is applied, so there is no later build step).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-vespa (7957d927b8f3) on network engines_default at container-ip:8080, not through docker-proxy localhost:8090; container gvb-vespa (7957d927b8f3) on network engines_default at container-ip:19071, not through docker-proxy localhost:19071. Open after the passes: container-ip:8080 x1 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-vespa: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-vespa: 214 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@8 3501/3497 MHz, performance, outside load 0.14 before the warm-up, 0.16 during, client CPU 0.950 ms per search; exact 3516/3496 MHz, performance, outside load 0.15 before the warm-up, 0.08 during, client CPU 0.967 ms per search; default@1 3510/3495 MHz, performance, outside load 0.08 before the warm-up, 0.08 during, client CPU 0.959 ms per search.

Qdrant (HNSW) qdrant-hnsw

Engine: Qdrant 1.17.0 in container gvb-qdrant (image qdrant/qdrant:v1.17.0@sha256:f1c7272cdac52b38c1a0e89313922d940ba50afd90d593a1605dbbc214e66ffb; cpuset 2-3,6-7 from its creation; 3 search thread(s)) (compose)
Index: HNSW m=16 ef_construct=100, hnsw_ef=server default, cosine; indexing_threshold_kb 1 and full_scan_threshold_kb 10 (server defaults are 10,000 each) so a small collection builds and walks its graph
Load: 524 rows in batches of 1000, 0.1 s of upserts (6,667 rows/s); count matched 0.0 s after the last upsert; index step 2.0 s (indexing_threshold_kb 1, full_scan_threshold_kb 10; status Green, 524 of 524 vectors in HNSW segments (2 segments), waited 2.0 s)
Search: 21578 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.74 ms, 8 searchers 0.52 ms
Exact mode: 66,473 searches, p50 0.89 ms, p95 1.00 ms, recall 1.000
RAM: 38.14 MiB (docker stats); disk: 164.1 MiB (collection folder)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started qdrant.compose.yaml with every container created on CPUs 2-3,6-7: gvb-qdrant cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (status Green, optimizer ok, indexed_vectors_count 524 of 524 points, 2 segments, indexing_threshold_kb 1, full_scan_threshold_kb 10; every one of 1 non-empty segments has a complete HNSW graph above its full-scan threshold; no search has run yet, so the walk is proven by the segment settings only; searches counted since the collection was created: unfiltered_hnsw 0, unfiltered_plain 0, unfiltered_exact 0). Durability: What was measured (strace -f on the Qdrant server process, 30 single-point REST upserts per setting, every sync call timed against the request that caused it): with wait=true each upsert had exactly one msync(MS_SYNC) of the write-ahead-log segment inside the request, before the reply (30 of 30); with wait=false the 30 upserts were acknowledged within 0.26 s with no sync call, and the first WAL msync (one call covering all 30 records) came 2.7 s after the last reply, followed by the segment-file flushes. So the log is flushed to disk under both settings, but with wait=false the flush comes after the acknowledgement: an operating-system crash or power cut in that gap loses acknowledged writes, while a crash of the Qdrant process alone should not, because the bytes are already in the kernel's page cache (inferred, not tested). Every upsert here is sent with wait=true in batches of 256 over gRPC; the strace used one point per request, so one flush per batch is inferred, not measured. Segment files are flushed every 5 s; log segments 32 MB, 0 created ahead. /qdrant/config/config.yaml in container gvb-qdrant (the image's own file; its storage keys are listed) sets: storage.collection.quantization = null, storage.collection.replication_factor = 1, storage.collection.vectors.on_disk = null, storage.collection.write_consistency_factor = 1, storage.hnsw_index.ef_construct = 100, storage.hnsw_index.full_scan_threshold_kb = 10000, storage.hnsw_index.m = 16, storage.hnsw_index.max_indexing_threads = 0, storage.hnsw_index.on_disk = false, storage.hnsw_index.payload_m = null, storage.max_collections = null, storage.node_type = Normal, storage.on_disk_payload = true, storage.optimizers.default_segment_number = 0, storage.optimizers.deleted_threshold = 0.2, storage.optimizers.flush_interval_sec = 5, storage.optimizers.indexing_threshold_kb = 10000, storage.optimizers.max_optimization_threads = null, storage.optimizers.max_segment_size_kb = null, storage.optimizers.vacuum_min_vector_number = 1000, storage.performance.max_search_threads = 0, storage.performance.optimizer_cpu_budget = 0, storage.performance.update_rate_limit = null, storage.shard_transfer_method = null, storage.snapshots_config.snapshots_storage = local, storage.snapshots_path = ./snapshots, storage.storage_path = ./storage, storage.temp_path = null, storage.update_concurrency = null, storage.wal.wal_capacity_mb = 32, storage.wal.wal_segments_ahead = 0; no QDRANT__ environment overrides in the server process. Not tested by cutting power; whether the disk's own write cache reaches the media was not checked..
Load average 2.64 3.14 2.92 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 5,364 searches in 5.0 s, exact 5,496 searches in 5.0 s, default@8 17,385 searches in 5.0 s.
Settle: settled after 0.3 s and 300 searches (0 failed); p50 of the last windows of 100: 0.92, 0.89, 0.92 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 2,148 searches in 2.0 s: p50 0.918 ms against the settled p50 0.920 ms, 0% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:33:26.568Z to 2026-10-05T03:33:46.568Z (20.0 s), 21,578 searches, 0 failed, p50 0.916 ms, mean 0.925 ms, p99 1.460 ms, 1078.9 QPS (1000/QPS 0.927 ms).
Pass exact after default@1: 2026-10-05T03:33:46.607Z to 2026-10-05T03:34:46.607Z (60.0 s), 66,473 searches, 0 failed, p50 0.891 ms, mean 0.901 ms, p99 1.435 ms, 1107.9 QPS (1000/QPS 0.903 ms).
Pass default@8 after exact: 2026-10-05T03:34:46.677Z to 2026-10-05T03:35:06.679Z (20.0 s), 69,142 searches, 0 failed, p50 2.226 ms, mean 2.312 ms, p99 4.029 ms, 3456.8 QPS (1000/QPS 0.289 ms).
Passes in the order run: default@1, exact, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 30,753 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (status Green, optimizer ok, indexed_vectors_count 524 of 524 points, 2 segments, indexing_threshold_kb 1, full_scan_threshold_kb 10; every one of 1 non-empty segments has a complete HNSW graph above its full-scan threshold; 115,957 segment searches walked the graph and none scanned; searches counted since the collection was created: unfiltered_hnsw 115,957, unfiltered_plain 0, unfiltered_exact 71,989).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-qdrant (82613f71f1d7) on network gvb-qdrant_default at container-ip:6334, not through docker-proxy localhost:16334; container gvb-qdrant (82613f71f1d7) on network gvb-qdrant_default at container-ip:6333, not through docker-proxy localhost:16333. Open after the passes: container-ip:6334 x1 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-qdrant: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-qdrant: 24 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.09 before the warm-up, 0.06 during, client CPU 0.743 ms per search; exact 3492/3492 MHz, performance, outside load 0.08 before the warm-up, 0.08 during, client CPU 0.734 ms per search; default@8 3492/3492 MHz, performance, outside load 0.08 before the warm-up, 0.12 during, client CPU 0.521 ms per search.

Typesense typesense

Engine: Typesense 30.2 (vector search) (compose)
Index: HNSW float32 (hnswlib), m=16, ef_construction=128, cosine; search k=top, ef=100; exact mode = filter ordinal:>=0 with flat_search_cutoff; index held in memory
Load: 524 rows in batches of 1000, 1.1 s of upserts (498 rows/s); count matched 0.0 s after the last upsert; index step 0.7 s (nothing to build, Typesense inserts into the HNSW graph while writing; ready after 0.7 s: HNSW graph returns 524 of 524 vectors, no writes queued: num_documents 524, pending_write_batches 0, health ok, unfiltered vector query with k above the count returned 524; the graph is built in memory during each write, so there is no later build step)
Search: 4907 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.51 ms, 8 searchers 0.57 ms
Exact mode: 10,880 searches, p50 5.46 ms, p95 5.86 ms, recall 1.000
RAM: 118.1 MiB (docker stats); disk: 0 B added by this load (240.61 MiB (whole engine data folder), 635.8 MiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started typesense.compose.yaml with every container created on CPUs 2-3,6-7: gvb-typesense cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (HNSW graph returns 524 of 524 vectors, no writes queued: num_documents 524, pending_write_batches 0, health ok, unfiltered vector query with k above the count returned 524; the graph is built in memory during each write, so there is no later build step). Durability: Every acknowledged write is appended to Typesense's raft log and fsynced before the answer: braft raft_sync=true with raft_sync_policy=0 (sync immediately), read from the running container's brpc /flags page on 2026-10-04. A restart replays the log from the last snapshot (typesense.compose.yaml sets TYPESENSE_SNAPSHOT_INTERVAL_SECONDS=300) and rebuilds the in-memory HNSW graph, so by those settings a crash loses no acknowledged write, but the restart is slow after a big load. This is read from the settings, not shown by pulling power. One node and no replicas, so a lost disk loses the data..
Load average 3.46 3.06 2.91 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: exact 904 searches in 5.0 s, default@1 1,227 searches in 5.0 s, default@8 2,942 searches in 5.0 s.
Settle: settled after 1.2 s and 300 searches (0 failed); p50 of the last windows of 100: 4.02, 4.03, 4.04 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 485 searches in 2.0 s: p50 4.043 ms against the settled p50 4.029 ms, 0% apart (limit 15%).
Pass exact after settle: 2026-10-05T03:35:35.727Z to 2026-10-05T03:36:35.728Z (60.0 s), 10,880 searches, 0 failed, p50 5.462 ms, mean 5.513 ms, p99 6.307 ms, 181.3 QPS (1000/QPS 5.515 ms).
Pass default@1 after exact: 2026-10-05T03:36:35.817Z to 2026-10-05T03:36:55.819Z (20.0 s), 4,907 searches, 0 failed, p50 4.032 ms, mean 4.074 ms, p99 4.729 ms, 245.3 QPS (1000/QPS 4.076 ms).
Pass default@8 after default@1: 2026-10-05T03:36:55.859Z to 2026-10-05T03:37:15.870Z (20.0 s), 11,770 searches, 0 failed, p50 13.055 ms, mean 13.597 ms, p99 25.460 ms, 588.2 QPS (1000/QPS 1.700 ms).
Passes in the order run: exact, default@1, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 5,918 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (HNSW graph returns 524 of 524 vectors, no writes queued: num_documents 524, pending_write_batches 0, health ok, unfiltered vector query with k above the count returned 524; the graph is built in memory during each write, so there is no later build step).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-typesense (5d83a5073e5d) on network engines_default at container-ip:8108, not through docker-proxy localhost:8108. Open after the passes: container-ip:8108 x8 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-typesense: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-typesense: 303 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): exact 3592/3592 MHz, performance, outside load 0.07 before the warm-up, 0.12 during, client CPU 0.524 ms per search; default@1 3592/3592 MHz, performance, outside load 0.12 before the warm-up, 0.12 during, client CPU 0.512 ms per search; default@8 3592/3592 MHz, performance, outside load 0.12 before the warm-up, -0.06 during, client CPU 0.575 ms per search.

Chroma chroma

Engine: Chroma 1.4.4 (single node, REST API v2) (compose)
Index: HNSW M=16 ef_construction=128, ef_search=100 (Chroma default), cosine; approximate only (no exact mode)
Load: 524 rows in batches of 1000, 0.6 s of upserts (920 rows/s); count matched 0.0 s after the last upsert; index step 0.0 s (Chroma has no index build to wait for and exposes no index status; checked in 0.0 s: Chroma exposes no index status (indexing_status endpoint: HTTP 500 {"error":"InternalError","message":"Method scout_logs is not implemented"}), so indexed vectors are not reported and ready only means the two counts agree to within 1 percent: count endpoint 524, a vector search asking for 524 results returned 524)
Search: 9758 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.46 ms, 8 searchers 0.46 ms
RAM: 44.77 MiB (docker stats); disk: 414.16 KiB added by this load (2.01 GiB (whole engine data folder), 2 GiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started chroma.compose.yaml with every container created on CPUs 2-3,6-7: gvb-chroma cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, ? of 524 indexed (Chroma exposes no index status (indexing_status endpoint: HTTP 500 {"error":"InternalError","message":"Method scout_logs is not implemented"}), so indexed vectors are not reported and ready only means the two counts agree to within 1 percent: count endpoint 524, a vector search asking for 524 results returned 524). Durability: SQLite rollback journal with its default synchronous=FULL under the data directory (chroma.compose.yaml sets IS_PERSISTENT=1 and PERSIST_DIRECTORY=/data and no sync setting): every write is committed to chroma.sqlite3 with fsync of the journal, the directory and the database file before the call returns (strace: 15 database fsyncs and 38 journal fsyncs for one create, four 500-vector upserts and one delete), and the HNSW files are written every sync_threshold=1000 vectors and rebuilt from the SQLite log after a crash; measured with kill -9 and a restart: all 50, 300 and 2,000 vectors were still stored and searchable.
Load average 2.55 2.76 2.81 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@8 4,009 searches in 5.0 s, default@1 2,428 searches in 5.0 s.
Settle: settled after 0.6 s and 300 searches (0 failed); p50 of the last windows of 100: 2.11, 2.01, 2.04 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 972 searches in 2.0 s: p50 2.035 ms against the settled p50 2.038 ms, 0% apart (limit 15%).
Pass default@8 after settle: 2026-10-05T03:37:38.069Z to 2026-10-05T03:37:58.076Z (20.0 s), 16,106 searches, 0 failed, p50 9.878 ms, mean 9.934 ms, p99 11.509 ms, 805.0 QPS (1000/QPS 1.242 ms).
Pass default@1 after default@8: 2026-10-05T03:37:58.123Z to 2026-10-05T03:38:18.123Z (20.0 s), 9,758 searches, 0 failed, p50 2.030 ms, mean 2.048 ms, p99 2.553 ms, 487.9 QPS (1000/QPS 2.050 ms).
Passes in the order run: default@8, default@1; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 7,749 sent, 0 failed (warmupErrors). Index after the searches: ready, ? of 524 indexed (Chroma exposes no index status (indexing_status endpoint: HTTP 500 {"error":"InternalError","message":"Method scout_logs is not implemented"}), so indexed vectors are not reported and ready only means the two counts agree to within 1 percent: count endpoint 524, a vector search asking for 524 results returned 524).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-chroma (df84d63d7e2b) on network gvb-chroma_default at container-ip:8000, not through docker-proxy localhost:8000. Open after the passes: container-ip:8000 x8 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-chroma: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-chroma: 9 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@8 3592/3592 MHz, performance, outside load 0.09 before the warm-up, 0.07 during, client CPU 0.459 ms per search; default@1 3592/3592 MHz, performance, outside load 0.07 before the warm-up, 0.07 during, client CPU 0.462 ms per search.

DuckDB duckdb

Engine: DuckDB 1.5.6 + vss b833341 (HNSW, embedded, in process) (embedded)
Index: HNSW (vss extension) FLOAT[n] metric=cosine m=16 ef_construction=128, ef_search=100 per connection, persistent (hnsw_enable_experimental_persistence=true, checkpoint_threshold=256MB); exact mode = array_cosine_similarity sequential scan; score = 1 - cosine distance
Load: 524 rows in batches of 1000, 0.3 s of upserts (1,526 rows/s); count matched 0.0 s after the last upsert; index step 0.0 s (HNSW is maintained inside every transaction, nothing to build; confirmed in 0.01 s: duckdb_indexes() lists gvb_gvbbench_eshoponweb_hnsw, pragma_hnsw_index_info() counts 524 vectors of 524 rows, EXPLAIN of the default search shows HNSW_INDEX_SCAN on it = True)
Search: 5678 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 4.81 ms, 8 searchers 4.95 ms
Exact mode: 14,672 searches, p50 4.01 ms, p95 4.74 ms, recall 1.000
RAM: in this process, not measured; disk: 2.9 MiB added by this load (413.83 MiB (engine data folder), 410.93 MiB before)
Index after the load: ready, 524 of 524 indexed (duckdb_indexes() lists gvb_gvbbench_eshoponweb_hnsw, pragma_hnsw_index_info() counts 524 vectors of 524 rows, EXPLAIN of the default search shows HNSW_INDEX_SCAN on it = True). Durability: DuckDB's write-ahead log is fsynced at every commit and no DuckDbSink setting changes that (checkpoint_threshold=256MB only spaces out the checkpoints that write the database file; measured with strace: 42 WAL fsyncs for 40 single-record commits plus 2 setup statements), so an operating-system crash or power cut loses no committed row; measured with kill -9 right after the last commit and a reopen: all 50, 300 and 2,000 rows and an HNSW index that counted the same number were recovered from the log; not tested and documented by DuckDB: the HNSW index is file-backed only through hnsw_enable_experimental_persistence = true, which this sink turns on, and WAL recovery for such custom indexes is not complete, so a crash during a checkpoint or a later commit can damage the index while the rows survive.
Load average 2.47 2.70 2.79 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 1,434 searches in 5.0 s, default@8 1,442 searches in 5.0 s, exact 1,255 searches in 5.0 s.
Settle: settled after 1.1 s and 300 searches (0 failed); p50 of the last windows of 100: 3.51, 3.44, 3.44 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 571 searches in 2.0 s: p50 3.464 ms against the settled p50 3.440 ms, 1% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:38:38.457Z to 2026-10-05T03:38:58.460Z (20.0 s), 5,678 searches, 0 failed, p50 3.491 ms, mean 3.520 ms, p99 5.040 ms, 283.9 QPS (1000/QPS 3.523 ms).
Pass default@8 after default@1: 2026-10-05T03:38:58.541Z to 2026-10-05T03:39:18.570Z (20.0 s), 5,597 searches, 0 failed, p50 28.395 ms, mean 28.606 ms, p99 31.587 ms, 279.4 QPS (1000/QPS 3.579 ms).
Pass exact after default@8: 2026-10-05T03:39:18.657Z to 2026-10-05T03:40:18.659Z (60.0 s), 14,672 searches, 0 failed, p50 4.012 ms, mean 4.085 ms, p99 5.657 ms, 244.5 QPS (1000/QPS 4.090 ms).
Passes in the order run: default@1, default@8, exact; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 5,062 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (duckdb_indexes() lists gvb_gvbbench_eshoponweb_hnsw, pragma_hnsw_index_info() counts 524 vectors of 524 rows, EXPLAIN of the default search shows HNSW_INDEX_SCAN on it = True).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: in this process (embedded), no network: no network address. No open connection seen (no open TCP connection was found).
CPU pinning: none: an embedded engine runs inside the benchmark client process, so it shares the client CPUs, CPUs 0-1,4-5.
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3593/3592 MHz, performance, outside load 0.10 before the warm-up, 0.09 during, client CPU 4.810 ms per search; default@8 3597/3592 MHz, performance, outside load 0.10 before the warm-up, 0.08 during, client CPU 4.945 ms per search; exact 3593/3592 MHz, performance, outside load 0.09 before the warm-up, 0.12 during, client CPU 6.036 ms per search.

Elasticsearch elasticsearch

Engine: Elasticsearch 9.5.3 (dense_vector) (compose)
Index: HNSW float32, no quantization, m=16, ef_construction=128, cosine; search k=top, num_candidates=100; 1 shard, 0 replicas; force-merged to one segment after the load (at 1,024 dimensions a segment under 1,043 vectors gets no graph)
Load: 524 rows in batches of 1000, 1.1 s of upserts (468 rows/s); count matched 0.1 s after the last upsert; index step 0.4 s (FAILED after 0.4 s: NO HNSW GRAPH, searches scan all 524 vectors: 1 segment(s), 524 vectors, total_vex_size_bytes 0 (_stats dense_vector), index_options hnsw m=16 ef_construction=128; Lucene builds no graph for a segment this small (measured at 1,024 dimensions: 1,042 vectors none, 1,043 vectors a graph), so default search equals exact search)
Search: 14320 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.47 ms, 8 searchers 0.49 ms
Exact mode: 47,574 searches, p50 1.24 ms, p95 1.44 ms, recall 1.000
RAM: 2.5 GiB (docker stats); disk: 2.39 MiB added by this load (2.59 MiB (whole engine data folder), 209.91 KiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started elasticsearch.compose.yaml with every container created on CPUs 2-3,6-7: gvb-elasticsearch cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
WARNING: the index step after the load FAILED (NO HNSW GRAPH, searches scan all 524 vectors: 1 segment(s), 524 vectors, total_vex_size_bytes 0 (_stats dense_vector), index_options hnsw m=16 ef_construction=128; Lucene builds no graph for a segment this small (measured at 1,024 dimensions: 1,042 vectors none, 1,043 vectors a graph), so default search equals exact search). Searched anyway; see the index state.
WARNING: index not ready after the load: NOT ready, 0 of 524 indexed (NO HNSW GRAPH, searches scan all 524 vectors: 1 segment(s), 524 vectors, total_vex_size_bytes 0 (_stats dense_vector), index_options hnsw m=16 ef_construction=128; Lucene builds no graph for a segment this small (measured at 1,024 dimensions: 1,042 vectors none, 1,043 vectors a graph), so default search equals exact search). Measured anyway, so its search numbers may come from a scan or a half-built index. Durability: Every acknowledged bulk request is fsynced to the translog before the answer: index.translog.durability=request, the Elasticsearch default, which neither this sink nor elasticsearch.compose.yaml overrides (ElasticsearchReadinessTests reads it back from the live index). By that setting a process crash or power loss loses no acknowledged write; this is read from the setting, not shown by pulling power. One node and no replicas, so a lost disk loses the data..
Load average 2.30 2.41 2.65 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 1,009 searches in 5.0 s, default@8 4,838 searches in 5.0 s, exact 1,973 searches in 5.0 s.
Settle: settled after 1.4 s and 700 searches (0 failed); p50 of the last windows of 100: 1.54, 1.54, 1.50 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 1,101 searches in 2.0 s: p50 1.687 ms against the settled p50 1.536 ms, 9% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:41:10.855Z to 2026-10-05T03:41:30.856Z (20.0 s), 14,320 searches, 0 failed, p50 1.335 ms, mean 1.395 ms, p99 2.158 ms, 716.0 QPS (1000/QPS 1.397 ms).
Pass default@8 after default@1: 2026-10-05T03:41:30.878Z to 2026-10-05T03:41:50.880Z (20.0 s), 53,064 searches, 0 failed, p50 2.846 ms, mean 3.013 ms, p99 5.480 ms, 2652.9 QPS (1000/QPS 0.377 ms).
Pass exact after default@8: 2026-10-05T03:41:50.922Z to 2026-10-05T03:42:50.923Z (60.0 s), 47,574 searches, 0 failed, p50 1.238 ms, mean 1.259 ms, p99 1.744 ms, 792.9 QPS (1000/QPS 1.261 ms).
Passes in the order run: default@1, default@8, exact; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 9,681 sent, 0 failed (warmupErrors). Index after the searches: NOT ready, 0 of 524 indexed (NO HNSW GRAPH, searches scan all 524 vectors: 1 segment(s), 524 vectors, total_vex_size_bytes 0 (_stats dense_vector), index_options hnsw m=16 ef_construction=128; Lucene builds no graph for a segment this small (measured at 1,024 dimensions: 1,042 vectors none, 1,043 vectors a graph), so default search equals exact search).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-elasticsearch (a4082cc82c30) on network engines_default at container-ip:9200, not through docker-proxy localhost:9200. Open after the passes: container-ip:9200 x8 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-elasticsearch: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-elasticsearch: 74 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.11 during, client CPU 0.466 ms per search; default@8 3492/3492 MHz, performance, outside load 0.11 before the warm-up, 0.11 during, client CPU 0.490 ms per search; exact 3492/3492 MHz, performance, outside load 0.11 before the warm-up, 0.11 during, client CPU 0.461 ms per search.

SQL Server 2025 + DiskANN sql-diskann

Engine: Microsoft SQL Server 2025 (RTM-CU9) (KB5122048) - 17.0.5005.3 (X64), Enterprise Developer Edition (64-bit), in container gvb-mssql (image mcr.microsoft.com/mssql/server:2025-CU9-ubuntu-24.04@sha256:2b5b581621126574f3d1f75e78d3eebe8d05aedb59ad0cfdf9aa42cb0634d726; cpuset 2-3,6-7 from its creation; SQL Server counts 4 CPU(s) and runs 4 visible scheduler(s), affinity AUTO) (compose)
Index: DiskANN (preview) via VECTOR_SEARCH, cosine, build {"StartId":"306", "L":"48", "M":"8", "R":"48"}; the exact mode scans the same table
Load: 524 rows in batches of 1000, 0.9 s of upserts (612 rows/s); count matched 0.0 s after the last upsert; index step 4.0 s (copied 524 rows to dbo.gvb_gvbbench_eshoponweb_ann (INT key) and built DiskANN, parameters {"StartId":"306", "L":"48", "M":"8", "R":"48"}, graph covers 524 rows)
Search: 5511 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 1.03 ms, 8 searchers 1.10 ms
Exact mode: 16,349 searches, p50 3.57 ms, p95 4.13 ms, recall 1.000
RAM: 530.2 MiB (docker stats); disk: 4.52 MiB (table and its indexes, reserved pages)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started mssql.compose.yaml with every container created on CPUs 2-3,6-7: gvb-mssql cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (DiskANN index built and used. sys.vector_indexes: vix_gvb_gvbbench_eshoponweb on dbo.gvb_gvbbench_eshoponweb_ann in GvbBenchDiskAnn, DiskANN, COSINE, enabled, build {"StartId":"306", "L":"48", "M":"8", "R":"48"}; graph table rows 524 of 524 table rows. Real VECTOR_SEARCH plan: Vector Index Seek on index vix_gvb_gvbbench_eshoponweb of GvbBenchDiskAnn.gvb_gvbbench_eshoponweb_ann (IndexKind DiskANN), 10 rows returned, 10 hits. The exact mode searches the SAME table (dbo.gvb_gvbbench_eshoponweb_ann, database GvbBenchDiskAnn) and its real plan is: Clustered Index Scan of GvbBenchDiskAnn.gvb_gvbbench_eshoponweb_ann through PK_gvb_gvbbench_eshoponweb_ann (IndexKind Clustered), 524 rows read, no vector index operator, 10 hits). Durability: A commit returns after its transaction-log records are written to disk (SQL Server write-ahead logging; delayed durability is DISABLED); a database created here copies the model database: recovery model FULL, page_verify CHECKSUM; no global trace flags are enabled; mssql.conf of container gvb-mssql (/var/opt/mssql/mssql.conf, on the host at ~/gvb-data/engines/mssql/mssql.conf) does not exist, so it sets: nothing; it has no [control] or [traceflag] entry, so SQL Server's own Linux defaults for flushing writes apply (Microsoft's Linux performance guide names trace flag 3982 as that default; read from the guide, not tested here). Not tested by cutting power; whether the disk's own write cache reaches the media was not checked. Container settings from its environment (names only): MSSQL_AGENT_ENABLED, MSSQL_MEMORY_LIMIT_MB, MSSQL_PID, MSSQL_RPC_PORT, MSSQL_SA_PASSWORD..
Load average 2.14 2.51 2.67 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@8 3,083 searches in 5.0 s, exact 1,374 searches in 5.0 s, default@1 1,404 searches in 5.0 s.
Settle: settled after 1.1 s and 300 searches (0 failed); p50 of the last windows of 100: 3.51, 3.54, 3.54 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 560 searches in 2.0 s: p50 3.550 ms against the settled p50 3.537 ms, 0% apart (limit 15%).
Pass default@8 after settle: 2026-10-05T03:43:25.569Z to 2026-10-05T03:43:45.576Z (20.0 s), 13,901 searches, 0 failed, p50 11.305 ms, mean 11.509 ms, p99 19.009 ms, 694.8 QPS (1000/QPS 1.439 ms).
Pass exact after default@8: 2026-10-05T03:43:45.653Z to 2026-10-05T03:44:45.656Z (60.0 s), 16,349 searches, 0 failed, p50 3.571 ms, mean 3.667 ms, p99 5.349 ms, 272.5 QPS (1000/QPS 3.670 ms).
Pass default@1 after exact: 2026-10-05T03:44:45.742Z to 2026-10-05T03:45:05.742Z (20.0 s), 5,511 searches, 0 failed, p50 3.564 ms, mean 3.627 ms, p99 5.138 ms, 275.5 QPS (1000/QPS 3.629 ms).
Passes in the order run: default@8, exact, default@1; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 6,781 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (DiskANN index built and used. sys.vector_indexes: vix_gvb_gvbbench_eshoponweb on dbo.gvb_gvbbench_eshoponweb_ann in GvbBenchDiskAnn, DiskANN, COSINE, enabled, build {"StartId":"306", "L":"48", "M":"8", "R":"48"}; graph table rows 524 of 524 table rows. Real VECTOR_SEARCH plan: Vector Index Seek on index vix_gvb_gvbbench_eshoponweb of GvbBenchDiskAnn.gvb_gvbbench_eshoponweb_ann (IndexKind DiskANN), 10 rows returned, 10 hits. The exact mode searches the SAME table (dbo.gvb_gvbbench_eshoponweb_ann, database GvbBenchDiskAnn) and its real plan is: Clustered Index Scan of GvbBenchDiskAnn.gvb_gvbbench_eshoponweb_ann through PK_gvb_gvbbench_eshoponweb_ann (IndexKind Clustered), 524 rows read, no vector index operator, 10 hits).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-mssql (0149acfffd7d) on network gvb-mssql_default at container-ip:1433, not through docker-proxy localhost:14330. Open after the passes: container-ip:1433 x9 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-mssql: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-mssql: 85 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@8 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.09 during, client CPU 1.099 ms per search; exact 3503/3493 MHz, performance, outside load 0.10 before the warm-up, 0.12 during, client CPU 1.168 ms per search; default@1 3496/3494 MHz, performance, outside load 0.12 before the warm-up, 0.13 during, client CPU 1.029 ms per search.

pgvector

Engine: PostgreSQL 17 + pgvector 0.8.7 (compose)
Index: HNSW vector_cosine_ops m=16 ef_construction=128, hnsw.ef_search=100 per query, float32 vector(n), cosine; exact mode = same query with index scans off (sequential scan)
Load: 524 rows in batches of 1000, 0.9 s of upserts (611 rows/s); count matched 0.0 s after the last upsert; index step 0.0 s (HNSW is maintained inside every insert, nothing to build; confirmed in 0.0 s: pg_indexes lists gvb_gvbbench_eshoponweb_hnsw (USING hnsw (embedding vector_cosine_ops) WITH (m='16', ef_construction='128')), pg_index valid and ready = True, EXPLAIN of the default search uses Index Scan on it = True, that search returned 10 of 10 rows; PostgreSQL keeps no entry count for an HNSW index, so indexed vectors are not reported)
Search: 23165 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.68 ms, 8 searchers 0.54 ms
Exact mode: 26,830 searches, p50 2.19 ms, p95 2.44 ms, recall 1.000
RAM: 100.7 MiB (docker stats); disk: 7.59 MiB added by this load (454.6 MiB (whole engine data folder), 447.01 MiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started pgvector.compose.yaml with every container created on CPUs 2-3,6-7: gvb-pgvector cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, ? of 524 indexed (pg_indexes lists gvb_gvbbench_eshoponweb_hnsw (USING hnsw (embedding vector_cosine_ops) WITH (m='16', ef_construction='128')), pg_index valid and ready = True, EXPLAIN of the default search uses Index Scan on it = True, that search returned 10 of 10 rows; PostgreSQL keeps no entry count for an HNSW index, so indexed vectors are not reported). Durability: fsync on, synchronous_commit on, full_page_writes on, wal_sync_method fdatasync (PostgreSQL defaults; pgvector.compose.yaml sets only shared_buffers, maintenance_work_mem and max_wal_size): every commit is flushed to the write-ahead log before it returns and HNSW index changes are WAL-logged, so a crash loses no committed row (max_wal_size 4GB only spaces out checkpoints; measured with docker kill, which is SIGKILL, right after a 2,000-vector load and a restart: all 2,000 rows were there and the HNSW index was valid and used by the default search).
Load average 1.71 2.36 2.60 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@8 19,668 searches in 5.0 s, default@1 5,899 searches in 5.0 s, exact 2,229 searches in 5.0 s.
Settle: settled after 0.2 s and 300 searches (0 failed); p50 of the last windows of 100: 0.83, 0.81, 0.80 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 2,357 searches in 2.0 s: p50 0.832 ms against the settled p50 0.811 ms, 3% apart (limit 15%).
Pass default@8 after settle: 2026-10-05T03:45:32.507Z to 2026-10-05T03:45:52.508Z (20.0 s), 82,047 searches, 0 failed, p50 1.905 ms, mean 1.948 ms, p99 3.448 ms, 4102.0 QPS (1000/QPS 0.244 ms).
Pass default@1 after default@8: 2026-10-05T03:45:52.567Z to 2026-10-05T03:46:12.568Z (20.0 s), 23,165 searches, 0 failed, p50 0.846 ms, mean 0.861 ms, p99 1.270 ms, 1158.2 QPS (1000/QPS 0.863 ms).
Pass exact after default@1: 2026-10-05T03:46:12.634Z to 2026-10-05T03:47:12.636Z (60.0 s), 26,830 searches, 0 failed, p50 2.192 ms, mean 2.234 ms, p99 3.529 ms, 447.2 QPS (1000/QPS 2.236 ms).
Passes in the order run: default@8, default@1, exact; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 30,513 sent, 0 failed (warmupErrors). Index after the searches: ready, ? of 524 indexed (pg_indexes lists gvb_gvbbench_eshoponweb_hnsw (USING hnsw (embedding vector_cosine_ops) WITH (m='16', ef_construction='128')), pg_index valid and ready = True, EXPLAIN of the default search uses Index Scan on it = True, that search returned 10 of 10 rows; PostgreSQL keeps no entry count for an HNSW index, so indexed vectors are not reported).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-pgvector (4c5c52ca06c5) on network gvb-pgvector_default at container-ip:5432, not through docker-proxy localhost:5432. Open after the passes: container-ip:5432 x8 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-pgvector: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-pgvector: 6 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@8 3492/3492 MHz, performance, outside load 0.13 before the warm-up, 0.12 during, client CPU 0.543 ms per search; default@1 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.11 during, client CPU 0.683 ms per search; exact 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.11 during, client CPU 0.693 ms per search.

SQL Server 2025 sql

Engine: Microsoft SQL Server 2025 (RTM-CU9) (KB5122048) - 17.0.5005.3 (X64), Enterprise Developer Edition (64-bit), in container gvb-mssql (image mcr.microsoft.com/mssql/server:2025-CU9-ubuntu-24.04@sha256:2b5b581621126574f3d1f75e78d3eebe8d05aedb59ad0cfdf9aa42cb0634d726; cpuset 2-3,6-7 from its creation; SQL Server counts 4 CPU(s) and runs 4 visible scheduler(s), affinity AUTO) (compose)
Index: exact VECTOR_DISTANCE cosine, no vector index (full scan)
Load: 524 rows in batches of 1000, 0.8 s of upserts (637 rows/s); count matched 0.0 s after the last upsert; index step n/a
Search: 5070 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 1.22 ms, 8 searchers 1.21 ms
RAM: 527.3 MiB (docker stats); disk: 5.15 MiB (table and its indexes, reserved pages)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started mssql.compose.yaml with every container created on CPUs 2-3,6-7: gvb-mssql cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 0 of 524 indexed (no index used, exact scan by design: dbo.gvb_gvbbench_eshoponweb in GvbBench holds 524 rows; sys.vector_indexes lists no index on the table; indexes: PK_gvb_gvbbench_eshoponweb CLUSTERED, IX_gvb_gvbbench_eshoponweb_DocKey NONCLUSTERED; a real search under SET STATISTICS XML ON ran: Clustered Index Scan of GvbBench.gvb_gvbbench_eshoponweb through PK_gvb_gvbbench_eshoponweb (IndexKind Clustered), 524 rows read, no vector index operator, 10 hits). Durability: A commit returns after its transaction-log records are written to disk (SQL Server write-ahead logging; delayed durability is DISABLED); a database created here copies the model database: recovery model FULL, page_verify CHECKSUM; no global trace flags are enabled; mssql.conf of container gvb-mssql (/var/opt/mssql/mssql.conf, on the host at ~/gvb-data/engines/mssql/mssql.conf) does not exist, so it sets: nothing; it has no [control] or [traceflag] entry, so SQL Server's own Linux defaults for flushing writes apply (Microsoft's Linux performance guide names trace flag 3982 as that default; read from the guide, not tested here). Not tested by cutting power; whether the disk's own write cache reaches the media was not checked. Container settings from its environment (names only): MSSQL_AGENT_ENABLED, MSSQL_MEMORY_LIMIT_MB, MSSQL_PID, MSSQL_RPC_PORT, MSSQL_SA_PASSWORD..
Load average 1.77 2.47 2.63 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 1,278 searches in 5.0 s, default@8 2,813 searches in 5.0 s.
Settle: settled after 1.2 s and 300 searches (0 failed); p50 of the last windows of 100: 3.82, 3.85, 3.88 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 511 searches in 2.0 s: p50 3.847 ms against the settled p50 3.846 ms, 0% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:47:37.978Z to 2026-10-05T03:47:57.982Z (20.0 s), 5,070 searches, 0 failed, p50 3.854 ms, mean 3.942 ms, p99 5.807 ms, 253.5 QPS (1000/QPS 3.945 ms).
Pass default@8 after default@1: 2026-10-05T03:47:58.020Z to 2026-10-05T03:48:18.031Z (20.0 s), 12,371 searches, 0 failed, p50 12.371 ms, mean 12.934 ms, p99 25.341 ms, 618.2 QPS (1000/QPS 1.618 ms).
Passes in the order run: default@1, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 4,942 sent, 0 failed (warmupErrors). Index after the searches: ready, 0 of 524 indexed (no index used, exact scan by design: dbo.gvb_gvbbench_eshoponweb in GvbBench holds 524 rows; sys.vector_indexes lists no index on the table; indexes: PK_gvb_gvbbench_eshoponweb CLUSTERED, IX_gvb_gvbbench_eshoponweb_DocKey NONCLUSTERED; a real search under SET STATISTICS XML ON ran: Clustered Index Scan of GvbBench.gvb_gvbbench_eshoponweb through PK_gvb_gvbbench_eshoponweb (IndexKind Clustered), 524 rows read, no vector index operator, 10 hits).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-mssql (7ac14f562e0d) on network gvb-mssql_default at container-ip:1433, not through docker-proxy localhost:14330. Open after the passes: container-ip:1433 x9 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-mssql: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-mssql: 85 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3510/3494 MHz, performance, outside load 0.13 before the warm-up, 0.13 during, client CPU 1.225 ms per search; default@8 3492/3492 MHz, performance, outside load 0.13 before the warm-up, 0.11 during, client CPU 1.209 ms per search.

Milvus milvus

Engine: Milvus 2.6.25 (standalone, embedded etcd, local storage, REST API v2) (compose)
Index: HNSW M=16 efConstruction=128, ef=100, metric COSINE, Strong consistency searches; approximate only (no exact mode)
Load: 524 rows in batches of 1000, 0.4 s of upserts (1,181 rows/s); count matched 1.7 s after the last upsert; index step 138.8 s (index Finished, type HNSW (COSINE, {"M":16,"efConstruction":128}), indexedRows 524 of 524 sealed rows, pendingRows 0; stored rows 524; LoadStateLoaded; query node: 1 sealed segment(s) with the index loaded covering 524 rows against 524 stored rows, 0 sealed without it, 0 rows in growing segments; datacoord: 1 live segment(s), 1 flushed and indexed covering 524 rows, 0 delete-log (L0) segment(s) waiting for a compaction, 3 segment(s) compacted away so far; flush, index build and load took 14.7 s, then compaction: 1 job(s) accepted by Milvus, layout ready and unchanged for 75 s, 124.1 s for the whole step; search ledger started, later state reads count the searches against the query node's own counters)
Search: 8633 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.54 ms, 8 searchers 0.63 ms
RAM: 222.2 MiB (docker stats); disk: 10.86 MiB added by this load (157.93 MiB (whole engine data folder), 147.06 MiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started milvus.compose.yaml with every container created on CPUs 2-3,6-7: gvb-milvus cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (index Finished, type HNSW (COSINE, {"M":16,"efConstruction":128}), indexedRows 524 of 524 sealed rows, pendingRows 0; stored rows 524; LoadStateLoaded; query node: 1 sealed segment(s) with the index loaded covering 524 rows against 524 stored rows, 0 sealed without it, 0 rows in growing segments; datacoord: 1 live segment(s), 1 flushed and indexed covering 524 rows, 0 delete-log (L0) segment(s) waiting for a compaction, 3 segment(s) compacted away so far; search ledger since the index finished: the sink sent 0 searches (searchParams.params.ef=100, Strong consistency), the query node counted 0 search requests for this collection, segment searches Sealed +0 and Growing +0, the same sealed segments with the same loaded index builds at both readings, segments compacted away +0). Durability: Writes are not fsynced. Standalone uses the default message queue rocksmq (RocksDB, /var/lib/milvus/rdb_data, mq.type default) and flushed segments go to local-disk object storage (COMMON_STORAGETYPE=local in milvus.compose.yaml). Measured 2026-10-04 with strace over 30 acknowledged single-row upserts and one flush: fdatasync ran only on the embedded etcd files (member/wal, member/snap/db), never on rdb_data or the segment files. A host power loss or kernel crash can lose acknowledged rows that are still in the OS page cache; a Milvus process crash alone should not (inferred, not tested). Metadata in embedded etcd is fdatasynced on every commit..
Load average 0.52 1.72 2.33 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 2,119 searches in 5.0 s, default@8 6,311 searches in 5.0 s.
Settle: settled after 0.7 s and 300 searches (0 failed); p50 of the last windows of 100: 2.21, 2.20, 2.20 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 864 searches in 2.0 s: p50 2.210 ms against the settled p50 2.199 ms, 1% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:51:02.727Z to 2026-10-05T03:51:22.729Z (20.0 s), 8,633 searches, 0 failed, p50 2.210 ms, mean 2.314 ms, p99 3.590 ms, 431.6 QPS (1000/QPS 2.317 ms).
Pass default@8 after default@1: 2026-10-05T03:51:22.753Z to 2026-10-05T03:51:42.755Z (20.0 s), 25,517 searches, 0 failed, p50 5.740 ms, mean 6.268 ms, p99 14.261 ms, 1275.7 QPS (1000/QPS 0.784 ms).
Passes in the order run: default@1, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 9,634 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (index Finished, type HNSW (COSINE, {"M":16,"efConstruction":128}), indexedRows 524 of 524 sealed rows, pendingRows 0; stored rows 524; LoadStateLoaded; query node: 1 sealed segment(s) with the index loaded covering 524 rows against 524 stored rows, 0 sealed without it, 0 rows in growing segments; datacoord: 1 live segment(s), 1 flushed and indexed covering 524 rows, 0 delete-log (L0) segment(s) waiting for a compaction, 3 segment(s) compacted away so far; search ledger since the index finished: the sink sent 43784 searches (searchParams.params.ef=100, Strong consistency), the query node counted 43784 search requests for this collection, segment searches Sealed +43011 and Growing +0, the same sealed segments with the same loaded index builds at both readings, segments compacted away +0).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-milvus (c5d1652f4efe) on network gvb-milvus_default at container-ip:19530, not through docker-proxy localhost:19530; container gvb-milvus (c5d1652f4efe) on network gvb-milvus_default at container-ip:9091, not through docker-proxy localhost:9091. Open after the passes: container-ip:19530 x8 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-milvus: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-milvus: 24 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3541/3504 MHz, performance, outside load 0.16 before the warm-up, 0.10 during, client CPU 0.544 ms per search; default@8 3493/3493 MHz, performance, outside load 0.14 before the warm-up, 0.17 during, client CPU 0.633 ms per search.

ClickHouse clickhouse

Engine: ClickHouse 26.3.39.7 (MergeTree + vector_similarity index) (compose)
Index: vector_similarity HNSW cosineDistance, quantization bf16, M=16 ef_construction=128, hnsw_candidate_list_size_for_search=256, rescoring off; exact mode = full scan with skip indexes off
Load: 524 rows in batches of 1000, 0.2 s of upserts (2,348 rows/s); count matched 0.0 s after the last upsert; index step 6.2 s (1 data part(s), index files on 1 of them, 524 of 524 live rows in indexed parts; 0 merge(s) running, 0 unfinished mutation(s); plan of the default search uses the Skip index vec_idx on 1 of 1 parts; wait took 6.2 s)
Search: 4083 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.83 ms, 8 searchers 1.05 ms
Exact mode: 8,954 searches, p50 6.43 ms, p95 9.23 ms, recall 1.000
RAM: 728.2 MiB (docker stats); disk: 906.61 MiB added by this load [Correction 2] (3.52 GiB (whole engine data folder), 2.64 GiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started clickhouse.compose.yaml with every container created on CPUs 2-3,6-7: gvb-clickhouse cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (1 data part(s), index files on 1 of them, 524 of 524 live rows in indexed parts; 0 merge(s) running, 0 unfinished mutation(s); plan of the default search uses the Skip index vec_idx on 1 of 1 parts). Durability: Acknowledged inserts are not fsynced. The sink creates plain MergeTree tables, so the MergeTree settings are the defaults: fsync_after_insert 0 and fsync_part_directory 0 (system.merge_tree_settings), and async_insert 1 with wait_for_async_insert 1 is the server default for the gvb login (system.settings), so an insert is acknowledged once its part is written, not once it is on disk. Measured 2026-10-04 with strace over 30 acknowledged single-row inserts (30 Ok rows in system.asynchronous_insert_log): zero fsync, fdatasync or sync_file_range calls, while the control, a table created with fsync_after_insert=1, made 61 fdatasync calls for 5 inserts. A host power loss or kernel crash can lose acknowledged rows that are still in the OS page cache; a ClickHouse process crash alone should not (inferred, not tested)..
Load average 3.93 2.55 2.57 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@8 2,231 searches in 5.0 s, exact 773 searches in 5.0 s, default@1 935 searches in 5.0 s.
Settle: settled after 1.4 s and 300 searches (0 failed); p50 of the last windows of 100: 4.68, 4.66, 4.68 ms, within 5% across 3 windows; confirmed by a trial right before the first timed pass of 412 searches in 2.0 s: p50 4.719 ms against the settled p50 4.675 ms, 1% apart (limit 15%).
Pass default@8 after settle: 2026-10-05T03:52:20.574Z to 2026-10-05T03:52:40.593Z (20.0 s), 8,551 searches, 0 failed, p50 18.084 ms, mean 18.716 ms, p99 35.495 ms, 427.2 QPS (1000/QPS 2.341 ms).
Pass exact after default@8: 2026-10-05T03:52:40.802Z to 2026-10-05T03:53:40.807Z (60.0 s), 8,954 searches, 0 failed, p50 6.426 ms, mean 6.697 ms, p99 10.047 ms, 149.2 QPS (1000/QPS 6.701 ms).
Pass default@1 after exact: 2026-10-05T03:53:40.909Z to 2026-10-05T03:54:00.913Z (20.0 s), 4,083 searches, 0 failed, p50 4.728 ms, mean 4.896 ms, p99 7.413 ms, 204.1 QPS (1000/QPS 4.899 ms).
Passes in the order run: default@8, exact, default@1; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 4,711 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (1 data part(s), index files on 1 of them, 524 of 524 live rows in indexed parts; 0 merge(s) running, 0 unfinished mutation(s); plan of the default search uses the Skip index vec_idx on 1 of 1 parts).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-clickhouse (e462fe3eb825) on network gvb-clickhouse_default at container-ip:8123, not through docker-proxy localhost:8123. Open after the passes: container-ip:8123 x1 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-clickhouse: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-clickhouse: 723 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@8 3523/3551 MHz, performance, outside load 0.15 before the warm-up, 0.12 during, client CPU 1.050 ms per search; exact 3592/3592 MHz, performance, outside load 0.13 before the warm-up, 0.13 during, client CPU 0.867 ms per search; default@1 3591/3591 MHz, performance, outside load 0.13 before the warm-up, 0.15 during, client CPU 0.827 ms per search.

OpenSearch opensearch

Engine: OpenSearch 3.9.0 (k-NN plugin, faiss) (compose)
Index: faiss HNSW float32, no compression, m=16, ef_construction=128, cosinesimil; search k=top, ef_search=100; 1 shard, 0 replicas; graph built at any segment size (approximate_threshold=0); force-merged to one segment after the load
Load: 524 rows in batches of 1000, 1.3 s of upserts (409 rows/s); count matched 0.1 s after the last upsert; index step 0.5 s (force-merged to one segment, graph ready after 0.5 s: every segment searched through its HNSW graph, covering 524 of 524 vectors: 1 segment(s), 0 merge(s) running, profiled probe search: ann_search_count 1 (segments tried through a graph), exact_search_count 0 (of those, scanned instead), approximate_threshold 0; force-merged to one segment on purpose, so one graph answers every search)
Search: 9726 latency samples, target held 524 rows, 0 errors
Client CPU per search: 1 searcher 0.47 ms, 8 searchers 0.50 ms
Exact mode: 22,691 searches, p50 2.60 ms, p95 2.94 ms, recall 1.000
RAM: 2.6 GiB (docker stats); disk: 9.47 MiB added by this load (10.2 MiB (whole engine data folder), 739.68 KiB before)
Started by run-all for this measurement with every container created on CPUs 2-3,6-7 (started opensearch.compose.yaml with every container created on CPUs 2-3,6-7: gvb-opensearch cpuset 2-3,6-7 (read back from docker inspect)); stopped afterwards.
Index after the load: ready, 524 of 524 indexed (every segment searched through its HNSW graph, covering 524 of 524 vectors: 1 segment(s), 0 merge(s) running, profiled probe search: ann_search_count 1 (segments tried through a graph), exact_search_count 0 (of those, scanned instead), approximate_threshold 0; force-merged to one segment on purpose, so one graph answers every search). Durability: Every acknowledged bulk request is fsynced to the translog before the answer: index.translog.durability=request, the OpenSearch default, which neither this sink nor opensearch.compose.yaml overrides (OpenSearchReadinessTests reads it back from the live index). By that setting a process crash or power loss loses no acknowledged write; this is read from the setting, not shown by pulling power. One node and no replicas, so a lost disk loses the data..
Load average 3.40 3.28 2.88 (1/5/15 min) when searching began.
Rehearsal before any timed pass, untimed, every pass type for at least 5 s through the same code the timed passes use: default@1 1,049 searches in 5.0 s, exact 1,266 searches in 5.0 s, default@8 4,044 searches in 5.0 s.
Settle: settled after the one extension. First settle 1.2 s and 300 searches (0 failed); p50 of the last windows of 100: 4.15, 4.19, 4.13 ms, within 5% across 3 windows; trial right before the first timed pass of 675 searches in 2.0 s: p50 2.747 ms against the settled p50 4.152 ms, 51% apart (limit 15%), so the settle was extended once (30.0 s and 13,697 searches (0 failed); p50 of the last windows of 100: 2.03, 2.00, 2.00 ms); second trial of 959 searches in 2.0 s: p50 2.020 ms against the settled p50 1.999 ms, 1% apart (limit 15%).
Pass default@1 after settle: 2026-10-05T03:55:27.312Z to 2026-10-05T03:55:47.314Z (20.0 s), 9,726 searches, 0 failed, p50 2.016 ms, mean 2.055 ms, p99 2.710 ms, 486.3 QPS (1000/QPS 2.056 ms).
Pass exact after default@1: 2026-10-05T03:55:47.379Z to 2026-10-05T03:56:47.381Z (60.0 s), 22,691 searches, 0 failed, p50 2.600 ms, mean 2.642 ms, p99 3.539 ms, 378.2 QPS (1000/QPS 2.644 ms).
Pass default@8 after exact: 2026-10-05T03:56:47.416Z to 2026-10-05T03:57:07.418Z (20.0 s), 29,587 searches, 0 failed, p50 5.207 ms, mean 5.406 ms, p99 10.577 ms, 1479.2 QPS (1000/QPS 0.676 ms).
Passes in the order run: default@1, exact, default@8; each after its own warm-up. Untimed searches (rehearsal, settle, settle check and per-pass warm-ups): 22,070 sent, 0 failed (warmupErrors). Index after the searches: ready, 524 of 524 indexed (every segment searched through its HNSW graph, covering 524 of 524 vectors: 1 segment(s), 0 merge(s) running, profiled probe search: ann_search_count 1 (segments tried through a graph), exact_search_count 0 (of those, scanned instead), approximate_threshold 0; force-merged to one segment on purpose, so one graph answers every search).
Benchmark copy gvbbench_eshoponweb dropped afterwards.
Connection: container address on its Docker network, not the published port (no docker-proxy): container gvb-opensearch (b26c4fc723bd) on network engines_default at container-ip:9200, not through docker-proxy localhost:9201. Open after the passes: container-ip:9200 x8 (this target).
CPU pinning: cpuset from the container's creation when run-all started it on the engine CPUs, else docker update --cpuset-cpus (each container's change line says which), CPUs 2-3,6-7. Changed: container gvb-opensearch: already on CPUs 2-3,6-7 (its cpuset since creation), not changed. Read back: container gvb-opensearch: 55 thread(s) on CPUs 2-3,6-7 (every thread of the container).
Clock per pass (median MHz of engine CPUs / client CPUs, governor, CPUs busy outside the benchmark, client CPU per search): default@1 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.12 during, client CPU 0.468 ms per search; exact 3492/3492 MHz, performance, outside load 0.12 before the warm-up, 0.11 during, client CPU 0.466 ms per search; default@8 3492/3492 MHz, performance, outside load 0.11 before the warm-up, 0.08 during, client CPU 0.504 ms per search.

Notes

Order: targets ran one at a time in a random order from seed 502 (runSeed; --seed 502 repeats it, targetOrder lists it). Inside each target the timed passes also ran in a random order from the same seed and the target's name (passOrder): default@1 is one searcher for 20 s (every search's latency gives p50/p95/p99, the completed searches give QPS@1, its first answer to each query gives recall and nDCG), default@N is N searchers for 20 s (QPS@N), exact is the engine's exact mode, one searcher for 60 s cycling the queries.
Preparation, untimed, before any timed pass: a rehearsal of every pass type for 5 s each through the same code the passes use, then a settle (default searches one at a time until the p50s of 3 windows of 100 agree within 5%, at most 120 s). Right before the first timed pass a 2 s trial of default searches must agree with the settled p50 within 15%; if it does not, or the settle did not settle, the settle is extended once (at least 30 s, at most 120 s more) and a second trial taken. Each target's notes give the result; a target still disagreeing is marked NOT settled.
Warm-up: every timed pass started with its own untimed warm-up of 20 searches in the same search mode and with the same number of searchers, stopped early after 60 s; with machine control on, the check for a quiet box comes right before the warm-up, so warm-up and timed pass run back to back. Failed untimed searches are counted per target (warmupErrors) and are not in the timed error counts.
Load rows/s counts only time inside each target's upsert calls: one writer, batches of 1000, rows already in memory, the collection dropped and created fresh first. Engines that build or finish their index after the writes do it in a separate timed index step (the load's index seconds), and the run waits for it before searching.
Index proof: each engine's own report of its index (indexState) is read after the load and again after the last pass. A target whose index was not ready after the load was still measured and carries a WARNING; an engine that reports nothing counts as not ready.
Durability: each target's crash-safety setting as configured here (durability). Engines that do not force writes to disk on every commit load faster for that reason.
Latency is client-side wall time around each search (network and driver included), every search of the default@1 window, one searcher, the queries cycled; a window with fewer than 200 searches, a p50 above 1.25 x its mean, or a mean above its p99 is flagged.
QPS: N searchers back to back for 20 s per level; completed searches divided by the window's elapsed time.
Recall@10: share of the exact top 10 (brute force in memory) that the engine returned. A hit whose exact similarity ties the 10th best (within 1e-5) also counts, because duplicate rows embed to identical vectors.
Routes: a container engine (the benchmark's own SQL Server and Qdrant containers included) is reached at its container's own address on its Docker network, never through the published localhost port (docker-proxy); the native comparison targets (sql-native, qdrant-native) are native services reached directly over loopback. Each target's addresses and the connections the client held open after its passes are in its notes and in conditions.connections.
RAM of compose engines, the benchmark's own SQL Server and Qdrant containers (sql, sql-diskann, qdrant, qdrant-hnsw) included, is docker stats of the engine's containers; for the native comparison targets (sql-native, qdrant-native) it is the whole native process, including every other database or collection it serves. Disk is the table's reserved pages (SQL), the collection folder (Qdrant), or for other engines what the load added to the engine's data folder (engines that keep data in memory until a snapshot show almost nothing).
Engines: run-all starts an engine that is down and stops it afterwards only if it was not running when the run began; an engine that was already running is left running.
WARNING: the engine did not report a ready index after the load for: elasticsearch. They were measured anyway; their numbers may come from a scan or a half-built index (see each target's index state).
Machine control on: governor performance on every CPU during the run (before: schedutil; at the end: performance; after putting it back: schedutil). engine CPUs 2-3,6-7 (cores 2,6 and 3,7), client CPUs 0-1,4-5 (cores 0,4 and 1,5); the client process was pinned; each engine was pinned to the engine CPUs for its turn and put back after (conditions.engines); an engine run-all started (and stopped) was asked to be created on them, and its notes say whether the host did so or it was moved there after the start. Busy box: right before each pass's warm-up the run waits, up to 10 min, while processes outside the benchmark (everything but this client and the engine under test's cgroups) use more than 0.3 CPUs on average over the last 60 s or the last 5 s, neither window reaching back past the start of the target or of its engine (so the engine's own start-up is not outside work); if the box does not clear the pass runs anyway, flagged 'busy box', as is a pass whose own outside load is above the limit. Outside load counts busy = user + nice + system + irq + softirq + steal (guest time is already in user); CONFIG_IRQ_TIME_ACCOUNTING is not set, so task and cgroup run time include the interrupt and softirq time that hit them and it is added; CONFIG_PARAVIRT_TIME_ACCOUNTING is not set, so steal is added (/boot/config-6.8.0-142-generic) (conditions.cpuAccounting); each pass also records this client's own CPU time per search (conditions.passes[].clientCpuMsPerSearch). CPU clocks were sampled every 250 ms; each pass's min/median/max per CPU is in conditions.passes. CPU idle states, recorded and left as found: driver intel_idle, governor menu, intel_idle max_cstate 9; POLL on, C1 on, C1E on, C3 OFF on CPUs 0-7 (default disabled), C6 on (conditions.cpuIdle). How each target was reached: conditions.connections. Client build Release, .NET 10.0.12.
sqlitevec is embedded: it ran inside the client process on the client CPUs 0-1,4-5, sharing them with the client.
duckdb is embedded: it ran inside the client process on the client CPUs 0-1,4-5, sharing them with the client.
WARNING: accounting mismatch in typesense exact: outside load over the last few seconds before the warm-up was -0.057 CPUs, below -0.05; the kernel's busy time minus this process minus the engine's cgroups came out negative, so the outside-load figures of this pass cannot be trusted.
WARNING: accounting mismatch in typesense default@8: outside load during the pass was -0.060 CPUs, below -0.05; the kernel's busy time minus this process minus the engine's cgroups came out negative, so the outside-load figures of this pass cannot be trusted.

Raw files

results.md is kept unedited. It still holds the sentences this page leaves out of its copy. Count: 1

The raw files below hold the recorded statements that the corrections above refer to, as written.