Benchmark Results

These benchmarks cover a narrow set of v0.1 workloads. On the workloads covered here, the C#-native embedded path avoids client/server round trips and some runtime mapping overhead. The headline run shows DataVo LSM Relaxed sustaining roughly 1.2M operations per second in a single-thread thread-scaling workload, and the vector benchmark shows a large managed-allocation gap against document-oriented brute-force paths.

These are local benchmark results, not universal rankings. The primary measurements were generated by the repository benchmark host on July 3, 2026 with .NET 10.0.103 on macOS arm64 / Apple Silicon. The vector comparison used sqlite-vec through the checked-in SQLITE_VEC_PATH value. Different hardware, filesystem behavior, .NET versions, native extensions, data shapes, and durability settings will change the numbers.

The most important benchmark distinction is durability. DataVo (LSM Production) means strict WAL fsync before a write is acknowledged. DataVo (LSM Relaxed) means the write is appended through the OS-buffered path without a synchronous stable-storage wait. Relaxed mode is a useful throughput ceiling for caches, rebuildable data, and research, but it must not be described as having the same power-loss contract as strict mode.

Use this page to answer three questions:

• How fast can the current LSM write/read path go when durability is relaxed?
• How much managed allocation does DataVo avoid on selected CRUD and vector workloads?
• Where do the results still need careful caveats because DataVo is a v0.1 alpha engine?

The benchmark commands are reproducible from the repository root. For example, the thread-scaling run behind the 1.2M ops/s chart is launched through the benchmark host:

dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario thread-scaling --format markdown

The units are consistent across the page: elapsed time and latency are milliseconds (ms), throughput is operations per second (ops/s), GC allocation is megabytes allocated by the managed runtime (MB), disk footprint is megabytes on disk (MB), and derived comparisons are multiplicative ratios (x). Vector P50 and P99 values describe the query phase; vector total time includes insert/index-build work plus the query phase.

Charts use stable colors by engine family: DataVo blue, DataVo LSM Relaxed cyan, DataVo-Flat green, SQLite orange, LiteDB purple, and DuckDB red.

Workload Recipes

The full rerun was produced by demos/Research.Benchmark/src/Research.Benchmark.Host. These examples show the scenario commands and the representative DataVo schema/query shape. Several DataVo rows use typed APIs or prepared compiled queries after creating the schema; the SQL below documents the logical workload, not a claim that every operation is executed through ad-hoc SQL text.

dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario flat-crud --format markdown
dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario disk-crud-wal --records 20000 --format markdown
dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario vector-search --vectors 10000 --dimensions 1536 --queries 100 --topk 10 --format markdown
dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario thread-scaling --format markdown
dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario ycsb-mixed --records 100000 --format markdown
dotnet run -c Release --project demos/Research.Benchmark/src/Research.Benchmark.Host -- --scenario space-and-recovery --records 1000000 --format markdown

Flat CRUD, disk CRUD, concurrent ops, thread scaling, YCSB, and space/recovery use the same logical record shape:

CREATE TABLE Records (
    Id INT PRIMARY KEY,
    Name VARCHAR(40),
    Value INT,
    Score FLOAT
);

-- Point lookup shape used by prepared compiled reads:
SELECT Id, Name, Value, Score
FROM Records
WHERE Id = @id;

-- Disk/YCSB update shape:
UPDATE Records
SET Value = @value, Score = @score
WHERE Id = @id;

The vector workload creates a vector column and either an HNSW or FLAT vector index:

CREATE TABLE Vectors (
    Id INT PRIMARY KEY,
    Emb VECTOR(1536)
);

CREATE INDEX vidx ON Vectors (Emb) USING HNSW;
-- DataVo-Flat uses: CREATE INDEX vidx ON Vectors (Emb) USING FLAT;

The simple risk workload subscribes to reactive aggregate views over a single Orders table:

CREATE TABLE Orders (
    OrderId INT,
    MarketId INT,
    RunnerId INT,
    AccountId INT,
    Side VARCHAR(8),
    Price INT,
    Stake INT,
    IsOpen BIT
);

SELECT MarketId, RunnerId, MAX(Price) AS BestBack, MIN(Price) AS BestLay, SUM(Stake) AS OpenExposure
FROM Orders
WHERE IsOpen = true
GROUP BY MarketId, RunnerId;

The complex VIP workload measures reactive maintenance over a join and aggregate:

CREATE TABLE Accounts (Id INT, IsVip BIT);
CREATE TABLE Markets (Id INT, Category VARCHAR(40));
CREATE TABLE Orders (Id INT, AccountId INT, MarketId INT, Stake INT);

SELECT m.Category, SUM(o.Stake) AS TotalExposure
FROM Orders o
JOIN Accounts a ON o.AccountId = a.Id
JOIN Markets m ON o.MarketId = m.Id
WHERE a.IsVip = true
GROUP BY m.Category;

The deep-document workload intentionally normalizes an order across three tables, then reconstructs the object through indexed child lookups:

CREATE TABLE Orders (Id INT PRIMARY KEY, Customer VARCHAR(40), Total FLOAT);
CREATE TABLE OrderItems (Id INT PRIMARY KEY, OrderId INT, Sku INT, Name VARCHAR(40), Quantity INT, UnitPrice FLOAT);
CREATE TABLE Addresses (Id INT PRIMARY KEY, OrderId INT, Kind VARCHAR(10), Street VARCHAR(40), City VARCHAR(40), PostalCode VARCHAR(12));

CREATE INDEX ix_OrderItems_OrderId ON OrderItems (OrderId);
CREATE INDEX ix_Addresses_OrderId ON Addresses (OrderId);

Headline Charts

The fallback tables below use the same July 3, 2026 macOS arm64 / Apple Silicon measurements described above. They are included so the raw Markdown and AI export show the exact chart data even when interactive Vue charts are not rendered.

LSM relaxed thread scaling

Workload: preload 100,000 records, then run 100,000 reads and 10,000 updates at 1, 2, 4, 8, 16, and 32 threads.

Threads	DataVo LSM Relaxed ops/s	SQLite WAL normal ops/s	LiteDB ops/s
1	1,215,413.207	318,474.934	52,043.089
2	1,192,483.021	515,803.275	63,226.160
4	1,044,648.267	541,284.774	63,082.810
8	1,025,016.936	586,604.721	59,112.129
16	1,041,723.883	582,041.070	63,418.034
32	1,022,364.692	514,214.285	61,971.122

Thread scaling throughputPreload 100,000 records, then run 100,000 reads and 10,000 updates.linear scale

DataVo LSM Relaxed SQLite WAL normal LiteDB

Linear scale keeps the 1M ops/s plateau visible while preserving SQLite and LiteDB trend shape.

YCSB mixed write tail

Workload: preload 100,000 records, then run 80,000 reads and 20,000 updates across 12 threads.

Engine	Write P99 (ms)	Ops/s
DataVo LSM Relaxed	1.333833	626,690.498
SQLite WAL normal	3.408333	233,778.627
LiteDB	3.785125	35,866.077

YCSB write P99 latency80,000 reads and 20,000 updates across 12 threads.linear scale

DataVo LSM Relaxed SQLite WAL normal LiteDB

SQLite WAL normal write P99 is 2.56x DataVo LSM relaxed in this run.

Vector allocation

Workload: insert 10,000 vectors with 1536 dimensions, then run 100 top-10 queries.

Engine	GC allocated (MB)	Notes
DataVo	157.246	HNSW build dominates total time.
DataVo-Flat	10.331	Flat SIMD path allocation floor.
LiteDB	208,915.002	Brute-force document allocation.
SQLite	63.427	sqlite-vec native extension.

1536-dim vector search GC allocationInsert 10,000 x 1536-dim vectors, then run 100 top-10 queries.log scale

DataVo DataVo-Flat LiteDB SQLite

Log scale is used because LiteDB allocation is four orders of magnitude above DataVo-Flat.

Disk CRUD total time

Workload: insert 20,000 records, then run 20,000 point updates under WAL.

Engine	Total time (ms)	Notes
DataVo LSM Production	501.870	Strict LSM fsync.
DataVo LSM Relaxed	247.080	Relaxed OS-buffered LSM.
SQLite WAL normal	842.914	SQLite WAL normal.
SQLite WAL full	84,638.110	SQLite WAL full.

Disk CRUD WAL total timeInsert 20,000 records, then run 20,000 point updates.log scale

DataVo LSM Production DataVo LSM Relaxed SQLite WAL normal SQLite WAL full

Log scale keeps SQLite full visible without flattening the lower-latency modes.

Streamed Risk Profile A: Simple Exposure

Workload: preload 10,000 baseline orders, then measure 50,000 insert+read iterations.

Simple exposure total time50,000 insert+read iterations after 10,000 baseline orders.log scale

DataVo DuckDB SQLite

Log scale is used because DuckDB total time is over two orders of magnitude above DataVo in this harness.

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	585.771	0.008708	0.025667	355.569
DuckDB	95,492.897	1.106084	10.157792	208.316
SQLite	2,820.346	0.039625	0.250750	198.906

Streamed Risk Profile B: Complex VIP

Workload: preload 10,000 orders, 1,000 accounts, and 50 markets, then measure 50,000 complex JOIN + GROUP BY insert+read iterations.

Complex VIP total time50,000 complex JOIN + GROUP BY insert+read iterations.log scale

DataVo DuckDB SQLite

Log scale is used because SQLite total time is hundreds of times larger than DataVo in this workload.

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	485.525	0.003459	0.036292	97.467
DuckDB	42,996.154	0.707916	3.744333	131.245
SQLite	401,777.617	6.616708	24.384834	115.598

Flat CRUD

Workload: insert 50,000 records, then run 50,000 point lookups.

Flat CRUD total time50,000 inserts followed by 50,000 point lookups.linear scale

DataVo LiteDB SQLite

Linear scale is retained here because the spread is readable and absolute elapsed time is the comparison.

Engine	Total time (ms)	P50 (ms)	P99 (ms)	Insert GC (MB)	Lookup GC (MB)	Total GC (MB)
DataVo	404.367	0.002459	0.016208	19.390	2.290	21.680
LiteDB	4,830.481	0.048000	0.558208	634.700	1,838.313	2,473.012
SQLite	689.475	0.005750	0.019791	31.286	30.824	62.110

Disk CRUD With WAL

Workload: insert 20,000 records, then run 20,000 point updates.

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo (LSM Production)	501.870	0.000042	0.000125	23.074
DataVo (LSM Relaxed)	247.080	0.000083	0.000208	17.782
SQLite (WAL,normal)	842.914	0.028625	0.127875	23.190
SQLite (WAL,full)	84,638.110	4.019917	7.945500	21.371

The retained figure calculations also include a separate SQLite full+fullfsync run, with 209,282.571 ms total time. It is kept in the derived ratios below, but it is not part of the main v2 benchmark table.

Deep Document

Workload: save 5,000 nested orders, each with 5 items and 2 addresses, then load 5,000 orders.

Deep document total timeSave and load 5,000 nested orders.linear scale

DataVo LiteDB SQLite

Linear scale keeps the elapsed-time differences directly comparable.

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	312.708	0.011958	0.153083	23.051
LiteDB	2,027.271	0.160916	1.013833	332.302
SQLite	777.268	0.046792	0.145958	46.050

Concurrent Ops

Workload: preload 100,000 records, then run 8 readers and 2 writers for 5 seconds.

Concurrent workload throughput8 readers and 2 writers for 5 seconds after 100,000-row preload.linear scale

DataVo SQLite

Throughput is plotted separately from latency because the units are different.

Concurrent workload write tailSame run, write P99 latency.log scale

DataVo SQLite

Log scale is used because SQLite write P99 is over three orders of magnitude larger in this concurrent run.

Engine	Total time (ms)	Ops/s	Read P99 (ms)	Write P99 (ms)	GC allocated (MB)
DataVo	5,084.770	511,827.704	0.038875	4.466542	626.927
SQLite	5,312.498	191,068.481	0.321750	5,306.753000	566.248

Vector Search

Workload: insert 10,000 vectors with 1536 dimensions, then run 100 top-10 queries.

Vector query P99 latency100 top-10 vector queries after inserting 10,000 x 1536-dim vectors.log scale

DataVo DataVo-Flat LiteDB SQLite

Log scale is used because LiteDB query P99 is roughly three orders of magnitude above DataVo and SQLite.

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	160,508.529	2.337125	3.015500	157.246
DataVo-Flat	580.608	2.124417	10.488584	10.331
LiteDB	95,716.480	881.466417	2,989.564083	208,915.002
SQLite	463.904	2.386333	3.106291	63.427

The vector result needs two separate interpretations. The HNSW-backed DataVo row shows low query latency but high build time in this 10k-vector run. DataVo-Flat shows the allocation win: 10.331 MB allocated versus LiteDB's 208,915.002 MB, while keeping per-query latency in the same millisecond class as SQLite sqlite-vec.

Thread Scaling

Threads	DataVo LSM Production ops/s	DataVo LSM Relaxed ops/s	SQLite WAL normal ops/s	LiteDB ops/s
1	2,478.648	1,215,413.207	318,474.934	52,043.089
2	2,962.324	1,192,483.021	515,803.275	63,226.160
4	4,788.347	1,044,648.267	541,284.774	63,082.810
8	7,274.764	1,025,016.936	586,604.721	59,112.129
16	7,480.346	1,041,723.883	582,041.070	63,418.034
32	9,110.373	1,022,364.692	514,214.285	61,971.122

YCSB Mixed

Workload: preload 100,000 records, then run 80,000 reads and 20,000 updates across 12 threads.

YCSB mixed throughput80,000 reads and 20,000 updates across 12 threads.log scale

DataVo LSM Production DataVo LSM Relaxed SQLite WAL normal LiteDB

Log scale is used because strict LSM fsync throughput is intentionally much lower than relaxed LSM throughput.

Engine	Total time (ms)	Ops/s	Read P99 (ms)	Write P99 (ms)	GC allocated (MB)
DataVo (LSM Production)	24,885.506	4,018.403	0.013458	50.721583	26.222
DataVo (LSM Relaxed)	159.568	626,690.498	0.000917	1.333833	23.268
SQLite (WAL,normal)	427.755	233,778.627	0.010500	3.408333	57.405
LiteDB	2,788.150	35,866.077	3.274250	3.785125	4,304.721

Space And Recovery

Workload: insert 1,000,000 records, measure disk footprint, then measure cold-open recovery time.

Disk footprint after 1M insertsInsert 1,000,000 records, then measure cold-open recovery.linear scale

DataVo LSM Relaxed SQLite WAL normal LiteDB

Linear scale is appropriate here; SQLite is 13.76% smaller than DataVo relaxed, while LiteDB is 2.32x DataVo.

Engine	Insert time (ms)	Disk size (MB)	Recovery time (ms)	GC allocated (MB)
DataVo (LSM Production)	972.018	66.443	0.609	286.966
DataVo (LSM Relaxed)	447.237	66.443	0.500	206.688
SQLite (WAL,normal)	714.776	58.405	0.386	631.917
LiteDB	2,979.232	154.461	0.674	15,158.872

SQLite is smaller than DataVo in this run by 13.76 percent. LiteDB uses 2.32x the DataVo relaxed footprint.

Derived Calculations

Derived benchmark ratiosDerived comparison ratios.log scale

Derived ratio

Log scale makes the 417x fullfsync ratio readable without hiding the smaller 2x-11x ratios.

Metric	Formula	Result
SQLite full+fullfsync disk CRUD time vs DataVo LSM Production	209282.571 / 501.870	417.01x
SQLite WAL normal disk CRUD time vs DataVo LSM Relaxed	842.914 / 247.080	3.41x
DataVo LSM Relaxed 1-thread ops/s vs SQLite WAL normal	1215413.207 / 318474.934	3.82x
SQLite WAL normal YCSB write P99 vs DataVo LSM Relaxed	3.408333 / 1.333833	2.56x
SQLite WAL normal YCSB read P99 vs DataVo LSM Relaxed	0.010500 / 0.000917	11.45x
DataVo LSM Relaxed ingest GC	verified fixed rerun GC MB	206.688 MB
SQLite space over DataVo space	(58.405 - 66.443) / 58.405 * 100	-13.76%
LiteDB space vs DataVo space	154.461 / 66.443	2.32x

Linux CI Snapshot - July 4, 2026

These measurements were produced by the GitHub Actions Linux benchmark workflow on July 4, 2026 at 2026-07-04T19:39:29Z. Environment: Ubuntu 24.04 hosted runner on Azure, Linux kernel 6.17.0-1018-azure, x64, .NET SDK 10.0.301, .NET host 10.0.9.

This is appended as a separate Linux snapshot. It does not replace the July 3, 2026 macOS arm64 measurements above. SQLite vector search reported n/a in this run because SQLITE_VEC_PATH was not set on the runner; the workflow now downloads and exports the pinned sqlite-vec Linux x86_64 loadable extension so this scenario should be rerun.

Linux simple exposure

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	1,225.539	0.016190	0.110096	355.567
DuckDB	174,377.097	3.428554	4.678679	208.302
SQLite	1,402.745	0.022312	0.061395	199.203

Linux complex VIP

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	467.431	0.007534	0.022161	97.468
DuckDB	113,237.819	2.236863	2.901818	131.237
SQLite	231,680.353	4.580272	8.061315	115.604

Linux flat CRUD

Engine	Total time (ms)	P50 (ms)	P99 (ms)	Insert GC (MB)	Lookup GC (MB)	Total GC (MB)
DataVo	146.317	0.001263	0.002044	19.390	2.290	21.680
LiteDB	2,856.804	0.022432	0.110727	635.949	1,832.855	2,468.804
SQLite	340.635	0.003286	0.004408	31.285	30.824	62.109

Linux disk CRUD WAL

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo (LSM Production)	473.281	0.000090	0.000120	44.468
DataVo (LSM Relaxed)	212.502	0.000091	0.000121	31.751
SQLite (WAL,normal)	1,057.520	0.013816	0.029355	57.196
SQLite (WAL,full)	7,792.303	0.108022	0.489026	53.414

Linux deep document

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	156.755	0.009928	0.022952	23.056
LiteDB	1,458.141	0.187492	0.260218	332.249
SQLite	373.122	0.020168	0.033212	46.048

Linux concurrent ops

Engine	Total time (ms)	Ops/s	Read P99 (ms)	Write P99 (ms)	GC allocated (MB)
DataVo	9,020.001	2,368,026.931	0.005630	0.000000	1,716.644
SQLite	5,107.857	199,916.321	0.185317	3,303.239339	570.333

Linux vector search

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	84,798.703	2.602106	3.020380	157.245
DataVo-Flat	616.448	3.012895	10.734534	10.327
LiteDB	168,891.495	1,657.344904	1,700.552233	208,915.187
SQLite	n/a	n/a	n/a	n/a

Linux thread scaling

Engine	Threads	Total time (ms)	Ops/s	GC allocated (MB)
DataVo (LSM Production)	1	3,478.492	31,622.901	23.676
DataVo (LSM Production)	2	2,818.404	39,029.178	21.620
DataVo (LSM Production)	4	1,629.282	67,514.394	20.040
DataVo (LSM Production)	8	1,404.683	78,309.461	18.860
DataVo (LSM Production)	16	1,406.291	78,219.964	19.889
DataVo (LSM Production)	32	1,358.683	80,960.778	19.873
DataVo (LSM Relaxed)	1	190.012	578,911.110	20.154
DataVo (LSM Relaxed)	2	189.798	579,564.757	17.704
DataVo (LSM Relaxed)	4	211.100	521,080.797	17.704
DataVo (LSM Relaxed)	8	211.885	519,149.784	17.705
DataVo (LSM Relaxed)	16	211.247	520,718.193	17.705
DataVo (LSM Relaxed)	32	215.962	509,349.810	17.706
SQLite (WAL,normal)	1	895.974	122,771.379	62.036
SQLite (WAL,normal)	2	589.814	186,499.346	62.036
SQLite (WAL,normal)	4	531.915	206,800.075	62.041
SQLite (WAL,normal)	8	500.144	219,936.790	62.037
SQLite (WAL,normal)	16	499.692	220,135.471	62.033
SQLite (WAL,normal)	32	440.481	249,726.720	62.070
LiteDB	1	4,561.652	24,114.071	4,365.008
LiteDB	2	4,940.175	22,266.418	4,350.736
LiteDB	4	5,168.339	21,283.434	4,350.736
LiteDB	8	5,184.349	21,217.708	4,350.608
LiteDB	16	5,198.950	21,158.117	4,350.882
LiteDB	32	5,289.057	20,797.658	4,350.565

Linux YCSB mixed

Engine	Total time (ms)	Ops/s	Read P99 (ms)	Write P99 (ms)	GC allocated (MB)
DataVo (LSM Production)	3,366.275	29,706.430	0.010640	2.293357	26.502
DataVo (LSM Relaxed)	397.577	251,523.667	0.002796	0.418472	21.002
SQLite (WAL,normal)	1,284.695	77,839.469	0.043291	3.223290	55.510
LiteDB	6,660.995	15,012.772	0.134983	0.276738	4,276.401

Linux space and recovery

Engine	Insert time (ms)	Disk size (MB)	Recovery time (ms)	GC allocated (MB)
DataVo (LSM Production)	1,608.832	66.444	0.967	286.389
DataVo (LSM Relaxed)	1,054.688	66.444	0.819	205.669
SQLite (WAL,normal)	1,794.018	58.405	0.685	629.097
LiteDB	7,416.158	154.461	1.425	15,158.757

Linux CI Snapshot - July 4, 2026 sqlite-vec rerun

These measurements were produced by the GitHub Actions Linux benchmark workflow on July 4, 2026 at 2026-07-04T20:13:44Z, after the workflow began downloading the pinned sqlite-vec loadable extension. Environment: Ubuntu 24.04 hosted runner on Azure, Linux kernel 6.17.0-1018-azure, x64, .NET SDK 10.0.301, .NET host 10.0.9, sqlite-vec 0.1.9 from sqlite-vec-0.1.9-loadable-linux-x86_64.tar.gz with SHA256 b959baa1d8dc88861b1edb337b8587178cdcb12d60b4998f9d10b6a82052d5d7.

This is appended as a separate sqlite-vec-enabled Linux snapshot. SQLite vector search now reports measured results instead of n/a.

Linux rerun headline charts

The charts below summarize the sqlite-vec-enabled Linux rerun: vector total time, vector query P99, and thread-scaling throughput. The raw tables that follow retain the exact values.

Linux vector search total time10,000 x 1536-dim vectors, then 100 top-10 queries.log scale

DataVo DataVo-Flat LiteDB SQLite/sqlite-vec

Linux CI now loads sqlite-vec; SQLite total time includes native vec0 insert/build and query work.

Linux vector search query P99Query-phase P99 latency for 100 top-10 searches.log scale

DataVo DataVo-Flat LiteDB SQLite/sqlite-vec

DataVo HNSW has the lowest query P99 in this run; DataVo-Flat has the lowest total time.

Linux thread scaling throughputPreload 100,000 records, then run 100,000 reads and 10,000 updates.linear scale

DataVo LSM Relaxed SQLite WAL normal LiteDB

This is the Linux CI rerun, not the macOS arm64 headline chart above.

Linux rerun simple exposure

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	1,241.747	0.016241	0.110366	355.567
DuckDB	170,289.722	3.362646	4.548743	208.302
SQLite	1,430.825	0.022482	0.062748	199.715

Linux rerun complex VIP

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	471.420	0.007934	0.021069	97.473
DuckDB	110,489.423	2.190414	2.623444	131.237
SQLite	233,819.490	4.589164	8.130840	115.601

Linux rerun flat CRUD

Engine	Total time (ms)	P50 (ms)	P99 (ms)	Insert GC (MB)	Lookup GC (MB)	Total GC (MB)
DataVo	148.330	0.001252	0.002034	19.396	2.290	21.686
LiteDB	2,815.603	0.022832	0.103844	635.945	1,833.159	2,469.104
SQLite	341.896	0.003206	0.004849	31.285	30.824	62.109

Linux rerun disk CRUD WAL

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo (LSM Production)	480.493	0.000090	0.000111	49.339
DataVo (LSM Relaxed)	213.726	0.000090	0.000120	36.613
SQLite (WAL,normal)	1,136.952	0.013726	0.029305	57.003
SQLite (WAL,full)	9,058.913	0.119884	0.590714	53.414

Linux rerun deep document

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	155.220	0.010309	0.022883	23.061
LiteDB	1,410.523	0.185899	0.284583	332.249
SQLite	366.910	0.020088	0.032731	46.048

Linux rerun concurrent ops

Engine	Total time (ms)	Ops/s	Read P99 (ms)	Write P99 (ms)	GC allocated (MB)
DataVo	9,009.968	2,765,510.729	0.005290	0.000000	1,906.625
SQLite	5,107.601	212,973.762	0.172972	5,104.352643	606.056

Linux rerun vector search

Engine	Total time (ms)	P50 (ms)	P99 (ms)	GC allocated (MB)
DataVo	79,536.809	2.316313	2.557093	157.246
DataVo-Flat	602.778	2.881425	10.595424	10.327
LiteDB	164,640.254	1,614.703016	1,663.416067	208,915.221
SQLite	2,186.128	18.414207	19.589254	63.279

Linux rerun thread scaling

Engine	Threads	Total time (ms)	Ops/s	GC allocated (MB)
DataVo (LSM Production)	1	4,018.153	27,375.762	23.509
DataVo (LSM Production)	2	3,196.829	34,409.095	21.619
DataVo (LSM Production)	4	1,793.892	61,319.188	20.033
DataVo (LSM Production)	8	1,575.778	69,806.783	18.875
DataVo (LSM Production)	16	1,675.560	65,649.697	19.914
DataVo (LSM Production)	32	1,563.815	70,340.792	19.863
DataVo (LSM Relaxed)	1	164.316	669,441.400	20.064
DataVo (LSM Relaxed)	2	158.874	692,373.008	17.704
DataVo (LSM Relaxed)	4	197.305	557,513.046	17.704
DataVo (LSM Relaxed)	8	198.395	554,449.457	17.705
DataVo (LSM Relaxed)	16	198.810	553,293.479	17.705
DataVo (LSM Relaxed)	32	199.483	551,425.988	17.706
SQLite (WAL,normal)	1	879.018	125,139.630	62.036
SQLite (WAL,normal)	2	584.524	188,187.215	62.036
SQLite (WAL,normal)	4	532.204	206,687.661	62.041
SQLite (WAL,normal)	8	453.247	242,693.117	62.056
SQLite (WAL,normal)	16	435.627	252,509.775	62.045
SQLite (WAL,normal)	32	451.444	243,662.720	62.041
LiteDB	1	4,488.734	24,505.799	4,367.394
LiteDB	2	4,487.832	24,510.724	4,350.557
LiteDB	4	4,962.193	22,167.619	4,350.839
LiteDB	8	5,190.497	21,192.578	4,350.763
LiteDB	16	4,966.148	22,149.964	4,350.672
LiteDB	32	4,937.013	22,280.677	4,350.705

Linux rerun YCSB mixed

Engine	Total time (ms)	Ops/s	Read P99 (ms)	Write P99 (ms)	GC allocated (MB)
DataVo (LSM Production)	3,773.362	26,501.563	0.010309	2.506526	26.132
DataVo (LSM Relaxed)	370.689	269,767.991	0.002445	0.384078	21.123
SQLite (WAL,normal)	1,331.577	75,098.930	0.045144	3.219948	55.506
LiteDB	6,546.631	15,275.033	0.131846	0.245650	4,276.233

Linux rerun space and recovery

Engine	Insert time (ms)	Disk size (MB)	Recovery time (ms)	GC allocated (MB)
DataVo (LSM Production)	1,597.586	66.444	0.929	286.401
DataVo (LSM Relaxed)	1,036.807	66.444	0.802	205.669
SQLite (WAL,normal)	1,779.351	58.405	0.633	629.039
LiteDB	6,891.179	154.461	1.342	15,158.796

Responsible Interpretation

DataVo's strongest current evidence is workload-specific: allocation-controlled typed rows, source-generated access paths, LSM write paths, and vector allocation behavior. The relaxed LSM results should not be presented as equivalent to strict fsync durability. SQLite and DuckDB remain mature engines with broad SQL support, sophisticated optimizers, and production hardening far beyond a v0.1 alpha embedded engine.