Lane

Vectors

Dense and sparse vector search, with recall beside every latency.

Illustration for DBBench, an open benchmark of database engines

Results

Tasks and results.

Dense and sparse vectors are different problems with different engines behind them, so they get separate tables. Both report recall beside every latency. An approximate index can be made fast by returning worse answers, so a latency without the share of true neighbours it found is not a comparable number.

Recall is measured against an exact brute-force answer over the same corpus. For an approximate index, agreeing with the exact answer is a stronger check than agreeing with another engine.

Where an engine has the boundary, loading the data and building the index are timed separately. A search after inserting into a built index, and a search after deleting from one, are timed as well.

Dense search, and search after an insert and after a delete into the same built index, with recall beside each. Every row states what it stores, full precision or quantized, because a quantized index and a full-precision one are not the same measurement.

Dense vector search DEEP-10M (deep-image-96-angular) and SIFT-1M
Engine	Mode	Precision	Size	cold p50 ms ↓	cold p99 ms ↓	warm p50 ms ↓	warm p99 ms ↓	after insert p50 ms ↓	after delete p50 ms ↓	insert into index ms/vector	recall@10 after insert	delete from index ms/vector	recall@10 after delete	recall@10 ↑	ingest+index vectors/s ↑	ingest s ↓	index s ↓	ingest+index total s ↓	peak memory GiB ↓	disk GiB ↓
ArcadeDB	embedded	int8	1M vectors	1.36	2.26	0.75	1.12	0.95	0.78	0.044	0.98	4.64	0.98	0.98	6,874	16.2	129.3	145.5	7.79	0.93
ArcadeDB	embedded	fp32	1M vectors	1.96	4.20	0.74	1.12	0.91	0.78	0.037	0.99	4.72	0.99	0.99	6,320	16.0	142.0	158.2	7.63	0.80
ArcadeDB	server	int8	1M vectors	2.45	3.62	1.74	2.29	1.74	1.79	0.16	0.98	6.95	0.98	0.98	4,868	87.4	117.4	205.4	8.37	0.94
ArcadeDB	server	fp32	1M vectors	2.94	5.54	1.78	2.23	1.86	1.81	0.10	0.99	6.93	0.99	0.99	4,626	87.1	128.8	216.2	7.65	0.81
ArangoDB	server	fp32	1M vectors	5.85	7.55	5.67	7.52	5.62	5.63	0.069	0.99	0.056	0.99	0.99	11k	—	—	92.7	1.83	0.98
Chroma	embedded	fp32	1M vectors	0.65	0.85	0.66	0.89	0.66	0.67	0.52	0.98	0.47	0.98	0.97	6,820	—	—	146.6	1.15	0.78
DuckDB VSS	embedded	fp32	1M vectors	1.77	3.42	1.77	2.06	2.03	2.02	10.7	0.97	1.78	0.98	0.98	17k	—	—	58.4	2.83	1.38
LanceDB	embedded	int8	1M vectors	1.55	2.81	1.58	2.33	20.5	19.8	0.0040	0.97	0.025	0.97	0.97	35k	0.86	27.4	28.4	2.02	0.89
Milvus	server	int8	1M vectors	1.13	2.40	1.09	1.78	1.14	1.13	8.56	0.97	2.53	0.97	0.97	7,497	13.6	117.8	133.4	2.93	3.13
Milvus	server	fp32	1M vectors	1.17	2.01	1.10	1.93	1.15	1.12	8.55	0.98	1.53	0.98	0.98	7,738	13.6	113.9	129.2	4.24	4.14
MongoDB	server	fp32	1M vectors	6.37	19.6	4.01	4.98	4.30	4.54	1.07	0.98	0.023	0.98	0.98	17k	17.3	41.2	58.8	5.10	2.54
Neo4j	server	fp32	1M vectors	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run
pgvector	server	fp32	1M vectors	1.82	2.24	1.81	2.21	1.81	1.74	1.08	0.99	0.079	0.99	0.99	6,506	21.8	132.1	153.7	0.055	2.56
Qdrant	server	int8	1M vectors	0.93	1.17	0.93	1.16	0.93	0.92	0.054	1.00	0.013	1.00	1.00	32k	—	—	31.4	1.23	2.44
Qdrant	server	fp32	1M vectors	1.09	1.45	1.11	1.44	1.10	1.08	0.058	1.00	0.013	1.00	1.00	23k	—	—	43.1	0.92	0.69
sqlite-vec	embedded	fp32	1M vectors	124.9	127.4	124.8	127.1	125.5	124.9	0.038	1.00	0.13	1.00	1.00	156k	—	—	6.39	0.042	0.50
SurrealDB	embedded	—	1M vectors	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h	>2h
SurrealDB	server	fp32	1M vectors	6.25	8.57	4.00	5.43	4.44	4.52	0.17	0.98	8.03	0.98	0.98	551	159.8	1,654	1,814	13.6	0.74
ArcadeDB	embedded	int8	9.99M vectors	2.77	5.55	0.87	1.37	—	—	—	—	—	—	0.94	5,047	143.0	1,843	1,979	28.3	8.57
ArcadeDB	embedded	fp32	9.99M vectors	18.9	126.2	1.01	1.50	—	—	—	—	—	—	0.95	4,664	148.8	1,991	2,142	28.3	7.56
ArcadeDB	server	int8	9.99M vectors	3.77	7.83	2.00	2.45	—	—	—	—	—	—	0.94	3,622	1,004	1,755	2,758	28.4	8.59
ArcadeDB	server	fp32	9.99M vectors	23.8	133.5	2.13	2.68	—	—	—	—	—	—	0.95	3,387	1,001	1,961	2,949	28.5	7.60
ArangoDB	server	fp32	9.99M vectors	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c	n/c
Chroma	embedded	fp32	9.99M vectors	0.70	0.91	0.71	0.89	—	—	—	—	—	—	0.93	2,650	—	—	3,770	12.7	6.59
DuckDB VSS	embedded	fp32	9.99M vectors	2.58	7.32	2.58	3.05	—	—	—	—	—	—	0.93	12k	—	—	833	25.2	8.08
LanceDB	embedded	int8	9.99M vectors	1.92	2.37	1.94	2.39	—	—	—	—	—	—	0.94	34k	6.59	287.9	295.0	11.0	7.11
Milvus	server	int8	9.99M vectors	1.49	1.82	1.46	1.77	—	—	—	—	—	—	0.96	7,654	193.2	1,108	1,305	13.6	25.2
Milvus	server	fp32	9.99M vectors	1.56	1.84	1.50	1.74	—	—	—	—	—	—	0.98	8,056	195.9	1,043	1,240	16.9	33.2
MongoDB	server	fp32	9.99M vectors	13.7	39.0	6.76	9.89	—	—	—	—	—	—	0.95	13k	135.5	642.0	777.2	22.0	22.9
Neo4j	server	fp32	9.99M vectors	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run	re-run
pgvector	server	fp32	9.99M vectors	2.84	3.78	2.52	3.33	—	—	—	—	—	—	0.95	5,153	272.6	1,665	1,939	3.73	17.1
Qdrant	server	int8	9.99M vectors	1.06	1.49	1.08	1.39	—	—	—	—	—	—	0.98	24k	—	—	412.6	7.10	5.34
Qdrant	server	fp32	9.99M vectors	1.35	1.88	1.26	1.75	—	—	—	—	—	—	0.98	18k	—	—	546.5	6.02	4.42
sqlite-vec	embedded	int8	9.99M vectors	671.0	680.6	671.0	678.6	—	—	—	—	—	—	0.92	174k	—	—	57.3	3.77	1.12
sqlite-vec	embedded	fp32	9.99M vectors	897.7	915.7	896.5	912.9	—	—	—	—	—	—	1	169k	—	—	59.0	3.61	3.80
SurrealDB	embedded	—	9.99M vectors	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h	>8h
SurrealDB	server	—	9.99M vectors	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM	OOM

↑ higher is better, ↓ lower is better; the best value in each column, within one size, is bold

Measured rows: benchmarks/experiments/results/runs_paper_oct.csv, benchmarks/experiments/results/dense_mp5_<pin or 2681>

Exact builds measured

arcadedb 26.10.1-dev · 417314c18
arangodb 3.12.11
chroma 1.5.9
duckdb vss 1.5.4
lancedb 0.39.0
milvus 3.0.1
mongodb 8.2.12 + MongoDb Search Community Version 1.70.4
pgvector 0.8.6
qdrant 1.19.1
sqlite-vec 0.1.9
surrealdb 3.2.4

ingest s and index s are two timers where the engine has the boundary: inserting the vectors, then building the index. ArangoDB (fp32), Chroma (fp32), DuckDB VSS (fp32), Qdrant (fp32), Qdrant (int8), sqlite-vec (fp32), and sqlite-vec (int8) record one timer only, because the index is built while ingesting or the adapter times no boundary, so their ingest s and index s are blank. ingest+index total s is one timer around both, and ingest+index vectors/s divides the vector count by it.
Disk is what the workload left on disk, in GiB: the engine's writable layer plus its volumes after the cell, minus the same engine's empty footprint.
Neo4j's row is marked `re-run`: its vector index ran at Neo4j's default quantization, binary with a three-fold search expansion, which our index definition did not override, while the row recorded it as unquantized. The next measurement sets the quantization explicitly, unquantized here and as a separate scalar-quantized row.
The insert and delete into a built index, the search after each, and the recall after each are measured at 1M vectors only. At 9.99M vectors those columns are blank because the pass is not run there, not because an engine failed it. These engines do not all maintain an index the same way: ArcadeDB (embedded, fp32) and ArcadeDB (embedded, int8) left 1,000 vectors in their delta buffers, to be merged by a later full rebuild this cell does not pay for. A full rebuild touches every vector in the index and an incremental insert touches only the new ones, so the per-vector costs here price different amounts of work and are not a straight speed comparison.
Cold p50 and p99 are the first timed pass over the query set after the index is built; a short untimed warm-up on held-out queries runs before it, so cold means an index that has not yet answered the timed queries, not a process that has done nothing. Warm columns, where present, are the passes after it.
Every engine searches this corpus with the same distance, squared Euclidean, although the corpus is one whose published neighbours were computed by angle. The two agree here: every vector and every query is scaled to unit length before anything is indexed, and once they are, ordering by Euclidean distance and ordering by angle produce the same list. So the recall column is measured against the dataset's own published neighbours, unchanged, while every engine runs one metric rather than each running its own -- which is what makes the latencies comparable at all.
ArcadeDB's maxConnections is a Vamana per-layer degree, not hnswlib's M. Matching the parameter names would compare a half-degree graph against a full-degree one, so the graphs are matched by effect instead.
ArangoDB's vector index is FAISS IVF (inverted lists over trained centroids), not HNSW, so the degree match above does not apply to it, and its rows record its operating point instead. Its number of lists is four times the square root of the vector count, the low end of the range FAISS's own guidelines give, which makes 4,000 lists at 1M vectors. The number of lists each query probes is calibrated, not set: after the build and before any timed pass, the benchmark picks the smallest number whose recall@10 on 200 queries held out from the timed ones reaches the median recall@10 of ArcadeDB (embedded, fp32) at the same size in the previous published measurement. At 1M vectors that target is 0.9886 and the calibration chose 90 to 119 lists across five builds.
Milvus's dense rows run with segments sealed at 50% of the maximum segment size, where the image default is 12%, so a large ingest lands in the few-large-segments layout that Milvus's own compaction otherwise reaches at an unpredictable moment. One line changed from the image's configuration; sparse rows are at the default.
ArcadeDB (embedded, fp32), ArcadeDB (embedded, int8), ArcadeDB (server, fp32), and ArcadeDB (server, int8) run on a JVM, and for them this column is close to the heap they were given rather than the memory the work needed: ArcadeDB (server, fp32)'s 28.50 GiB here is about 119 per cent of its 24g heap. Every engine on a table gets the same memory envelope; how much of it a JVM takes is a property of the runtime, so read these cells against each other rather than against an engine that manages its own memory.
Each pass answers 1,000 queries; cold is the first pass after the build and warm pools the four passes after it, over five builds.
`ingest+index total s` is the whole of building this corpus. `ingest s` and `index s` are the two phases timed inside it -- writing the data, then building whatever index the engine was given -- and they are not a division of it: each engine's ingest clock starts after the setup it does first, creating a schema or a collection, which neither phase counts. How much is left over depends on the engine: nothing on some of the ones here, up to about 1 per cent on others. Read the two as what each phase cost, and the total as what the whole of it cost.
SurrealDB (embedded) at 1M vectors: the search cell exceeded its 2 hour budget, the same budget every engine on this table had, on its first attempt and was not retried; there is no row. It was still in the index build when the budget ran out.
SurrealDB (embedded) at 9.99M vectors: the search cell exceeded its 8 hour budget, the same budget every engine on this table had, on its first attempt and was not retried; there is no row. It was still in the index build when the budget ran out.
SurrealDB (server) at 9.99M vectors: the search cell reached the 36g memory envelope (peak 36,864 MiB) and was killed by the kernel, the same envelope every engine on this table had; it did not run out of time, and there is no row.
ArangoDB at 9.99M vectors is not comparable. On the release measured here, 3.12.11, an IVF index with 10,000 or more lists answers every query from one fixed list. The index at this size has 12,643 lists, so the search returned none of the true neighbours, and the cell is not a measurement of ArangoDB's search. The next measurement runs ArangoDB at its latest stable release.
sqlite-vec (int8) at 1M vectors is withheld: its search answered with a recall@10 of 0.0229 across 5 repetition(s), which is not a measurement of search but of a broken index, so its latency is not printed beside engines answering correctly. The cause is investigated on the benchmark machine before anything is claimed about it.
In the cells: `>2h` and `>8h` mean the cell ran past its tier's cap and was not retried; each tier has its own cap, the same for every engine on it. `OOM` means killed at the cell's memory envelope rather than running out of time. `n/c` means not comparable, because a defect in the engine's release decided the cell's result; none of its numbers is printed, and the note names the defect. `re-run` means the cell was measured before a fix to our harness and stays off the table until it is measured again; the note says what was wrong. A dash is an operation the engine cannot express, never a slow one.
Ingest paths: ArcadeDB embedded issues INSERT per vector in 10,000-row transactions through the Python package, then CREATE INDEX ... LSM_VECTOR; served sends 500-statement sqlscript batches over HTTP with each vector spelled out as text, then the same CREATE INDEX; Chroma add() in batches of 5,000; LanceDB an Arrow table then create_index; Qdrant and Milvus upsert in batches; DuckDB VSS and sqlite-vec executemany; pgvector COPY FROM STDIN then CREATE INDEX; Neo4j loads then builds its vector index; MongoDB insert_many then its vector search index; ArangoDB import_bulk then its FAISS IVF index; SurrealDB inserts through its Python SDK under the HNSW index it defines first; the server builds that index in the background, so the served build time includes waiting until a query probe shows the index has caught up.

Sparse search on real learned sparse vectors, with recall beside every latency. Loading and indexing are one timer on this table: the engines here build the index while ingesting, so the boundary the dense table splits does not exist.

Sparse vector search Big-ANN'23 Sparse (real SPLADE over MS MARCO)
Engine	Mode	Precision	Size	cold p50 ms ↓	cold p99 ms ↓	warm p50 ms ↓	warm p99 ms ↓	gain ↑	recall@10 ↑	ingest+index vectors/s ↑	ingest+index total s ↓	peak memory GiB ↓	disk GiB ↓
ArcadeDB	embedded	int8	100k vectors	3.94	9.57	3.63	7.59	1.12x	0.99	12k	8.61	3.03	0.15
ArcadeDB	embedded	fp32	100k vectors	4.03	11.9	3.97	7.94	1.11x	1	11k	8.83	3.20	0.19
ArcadeDB	server	int8	100k vectors	4.93	10.5	4.43	9.05	1.20x	0.99	4,014	24.9	4.38	0.19
ArcadeDB	server	fp32	100k vectors	4.92	13.0	4.50	9.11	1.13x	1	4,044	24.7	4.38	0.23
Elasticsearch	server	~9-bit	100k vectors	3.51	6.97	2.83	5.41	1.38x	1.00	2,672	37.4	4.79	0.094
Milvus	server	fp32	100k vectors	1.13	2.51	1.06	1.40	1.08x	1.00	8,530	11.7	1.30	0.30
pgvector	server	fp32	100k vectors	0.98	1.76	0.96	1.70	1.06x	0.82	1,544	64.8	0.14	0.48
Qdrant	server	fp32	100k vectors	0.89	1.20	0.87	1.11	1.07x	1	12k	8.14	0.86	0.44
ArcadeDB	embedded	int8	1M vectors	11.3	35.9	11.5	36.9	1.06x	0.99	11k	89.0	8.35	1.48
ArcadeDB	embedded	fp32	1M vectors	11.1	35.7	10.7	36.0	1.12x	1	11k	89.8	8.42	1.83
ArcadeDB	server	int8	1M vectors	12.7	40.3	11.9	37.1	1.14x	0.99	4,288	233.2	8.65	1.50
ArcadeDB	server	fp32	1M vectors	12.6	38.8	12.4	36.8	1.09x	1	4,287	233.3	8.59	1.86
Elasticsearch	server	~9-bit	1M vectors	9.93	21.1	9.09	19.3	1.13x	1.00	3,142	318.2	9.03	0.90
Milvus	server	fp32	1M vectors	8.06	23.2	8.37	20.8	1.02x	1.00	9,770	102.3	6.78	6.08
pgvector	server	fp32	1M vectors	1.29	2.42	1.08	2.40	1.22x	0.77	1,510	662.4	0.25	4.22
Qdrant	server	fp32	1M vectors	2.85	4.13	2.79	4.06	0.99x	1	11k	88.5	8.09	1.45
ArcadeDB	embedded	int8	8.84M vectors	84.3	305.2	83.8	306.5	1.02x	0.99	9,994	884.7	16.8	13.1
ArcadeDB	embedded	fp32	8.84M vectors	86.5	316.0	83.8	309.3	1.03x	1.00	10k	874.1	16.8	16.2
ArcadeDB	server	int8	8.84M vectors	86.9	310.1	85.8	310.5	1.04x	0.99	4,081	2,167	16.9	13.1
ArcadeDB	server	fp32	8.84M vectors	87.7	312.6	85.6	311.8	1.04x	1.00	4,102	2,156	16.9	16.3
Elasticsearch	server	~9-bit	8.84M vectors	54.4	128.3	52.3	125.5	1.04x	1.00	2,567	3,445	17.4	8.01
Milvus	server	fp32	8.84M vectors	20.7	52.3	21.6	52.7	0.96x	1.00	9,740	907.8	16.2	65.4
pgvector	server	fp32	8.84M vectors	13.1	34.6	1.28	2.62	7.83x	0.72	1,501	5,893	0.40	29.2
Qdrant	server	fp32	8.84M vectors	15.6	24.8	16.5	25.3	0.96x	1.00	5,346	1,654	19.6	12.3

↑ higher is better, ↓ lower is better; the best value in each column, within one size, is bold

Measured rows: benchmarks/experiments/results/runs_paper_oct.csv

Exact builds measured

arcadedb 26.10.1-dev · 417314c18 (in-process)
arcadedb 26.10.1-dev · 417314c18 arcadedb-c25:417314c18
elasticsearch 9.5.4 docker.elastic.co/elasticsearch/elasticsearch@33178ff49e06…
milvus 3.0.1 milvusdb/milvus@2b2fc2cf499a…
pgvector 0.8.6 pgvector/pgvector@1d50c689b0a6…
qdrant 1.19.1 qdrant/qdrant@0699e7733a6f…

Cold p50 and p99 are the first timed pass after the build, median of five builds. Warm and gain come from a separate run of the same arms: one build per engine, then five more passes over a different half of the query set, so a warm number cannot be explained by the engine having already answered that exact query; gain is that run's cold over its warm.
Disk is what the workload left on disk, in GiB: the engine's writable layer plus its volumes after the cell, minus the same engine's empty footprint.
On this table each ArcadeDB search returns every hit's whole record, while every other engine returns the ids of its hits, not the records. The next measurement has ArcadeDB return ids as well.
Durability is matched at the relaxed end: on every engine that has the setting, a commit returns without waiting for the disk and the log is flushed by the engine's own background policy, which is ArcadeDB's engine default and a documented production mode for each of the others. Each row records what it ran as `durability`, and the setting was read out of the engine rather than assumed on every engine except Elasticsearch, Milvus, and Qdrant. Elasticsearch, Milvus, and Qdrant run at their defaults, and their rows say so without reading a setting back, because this table times no transactional write.
Recall is reported beside every latency: ArcadeDB quantizes posting weights to int8 by default, so a latency number without its recall is not comparable.
ingest+index total s is one timer around inserting the documents and building the index; on this lane every engine builds its sparse index as it ingests, so there is no boundary to time separately. ingest+index vectors/s divides the document count by it.
Elasticsearch runs with index-time token pruning disabled. Its 9.x default prunes on thresholds tuned for a different model's vectors and costs recall on this corpus, which would have printed a quality gap belonging to that default rather than to the engine, and printed it in our favour.
ArangoDB has no row on this table. Its index types are the primary, edge, vertex-centric, persistent, inverted, TTL, geo, and vector indexes and the deprecated fulltext index (https://docs.arango.ai/arangodb/stable/indexes-and-search/indexing/basics/), and the vector index is FAISS IVF over one attribute that holds an array of numbers of a fixed dimension (https://docs.arango.ai/arangodb/stable/indexes-and-search/indexing/working-with-indexes/vector-indexes/); its sparse option means an index that skips documents missing the attribute. Nothing indexes a sparse vector, so the sparse nearest-neighbour search this table times cannot be expressed.
MongoDB has no row on this table. Its index types are single field, compound, multikey, wildcard, geospatial, hashed, text, clustered, and unique (https://www.mongodb.com/docs/manual/indexes/), and a Vector Search index's vector field must hold an array of numbers, as doubles or as a BinData vector of floats or small integers, with a fixed number of dimensions (https://www.mongodb.com/docs/vector-search/indexes/vector-search-type/); the field types an index accepts are vector, filter, and autoEmbed, and none is a sparse or token-and-weight form. Nothing indexes a sparse vector, so the sparse nearest-neighbour search this table times cannot be expressed.
SurrealDB has no row on this table. Its index types are the standard, unique, composite, count, full-text, HNSW, and DISKANN indexes, with brute force for an unindexed field and the MTREE index the embedded core also accepts, and every vector form is declared with a DIMENSION over one field that holds an array of numbers (https://surrealdb.com/docs/surrealql/statements/define/indexes); the nearest-neighbour operator takes one dense array (https://surrealdb.com/docs/surrealql/operators). Nothing indexes a sparse vector, so the sparse nearest-neighbour search this table times cannot be expressed.
ArcadeDB (embedded, fp32), ArcadeDB (embedded, int8), ArcadeDB (server, fp32), ArcadeDB (server, int8), and Elasticsearch run on a JVM, and for them this column is close to the heap they were given rather than the memory the work needed: Elasticsearch's 17.37 GiB here is about 109 per cent of its 16g heap. Every engine on a table gets the same memory envelope; how much of it a JVM takes is a property of the runtime, so read these cells against each other rather than against an engine that manages its own memory.
Each timed pass on this table answers 1,000 queries, and its p50 and p99 leave out the first 5 as warm-up; the second-pass run answers 500 of them in its cold pass and the other 500 in each warm pass.
Ingest paths: ArcadeDB embedded loads through the Java API (newDocument with int and float arrays) in 500-record transactions, then COMPACT INDEX; served sends INSERT statements as sqlscript batches over HTTP; Qdrant, Milvus, and Elasticsearch upsert or bulk-index in batches, then settle (Elasticsearch refresh and force-merge, Milvus flush and load); pgvector COPY FROM STDIN in sparsevec text form, then CREATE INDEX.

The rules every result follows are in the methodology. The settings for each engine are on the engines page. If one is wrong, tell us.

DBBench

The other lanes.

Tables: Documents and structured query language (SQL) analytics.
Graphs: Interactive and analytical queries on a social network graph.
Time series: Monitoring-style queries over timestamped readings.
Cross-model: One operation across a vector, a graph edge, and a document.
Lifecycle: Opening, closing, deployment boundaries, and what waiting for the disk costs.

Resources

Rules and code.

All DBBench lanesOpen MethodologyOpen Engine settingsOpen Report a wrong settingOpen