Measured 2026-08-16 on one machine (darwin/arm64, Apple silicon). Both sides built from
the same feeds in the same session, minutes apart, and produced
identical row counts (cve_data_count 1,324,712 / cve_index_count
1,324,661), so the size and time deltas below are implementation, not
different data.
master @ 8e660b9 (6.7.2), built in a pinned worktree.release/7.0.x @ 1393288 (task 8.1 merged), built in a pinned
worktree so concurrent agent work could not contaminate it. Verified
git diff 1393288 -- vdb/ empty before and after.python -m vdb.cli --cache --only-osv
(v7 with --no-split, split timed separately). No --include-metadata.VDB_HOME directories
with the command above, then timing a fixed purl corpus against each.
test/data/match_set_corpus/ (29,316 real purls) is a reasonable query
workload; the figures below sample 5,000 of them with a fixed seed.| v6.7.2 | v7.0.x | delta | |
|---|---|---|---|
| Full build (OSV only) | 1,051 s | 425 s | 2.47x faster (−60%) |
| Post-build shard split | n/a | 33 s | +8% on the v7 build |
| v7 build including split | n/a | 458 s | still 2.29x faster than v6 |
| v6.7.2 | v7.0.x | delta | |
|---|---|---|---|
data |
7,993,556,992 B (7.44 GiB) | 3,086,082,048 B (2.87 GiB) | 2.59x smaller |
index |
791,375,872 B (755 MiB) | 621,821,952 B (593 MiB) | 1.27x smaller |
| total | 8.18 GiB | 3.45 GiB | 2.37x smaller (−58%) |
The win is concentrated in the data DB, which matches the known v6 defect: blobs were duplicated ~18.5x. The index shrinks only modestly because it was never the duplicated part.
Corpus: 5,000 purls sampled deterministically (seed 7) from
test/data/match_set_corpus (29,316 purls, real dep-scan shapes). Warm
page cache, warm connection.
| v6.7.2 | v7.0.x | |
|---|---|---|
Bulk search_packages (5,000 purls) |
205.3 ms | 203.8 ms |
| maven, per query | 0.109 ms | 0.118 ms |
| npm, per query | 0.0372 ms | 0.0373 ms |
| deb, per query | 0.0462 ms | 0.0464 ms |
| pypi, per query | 0.0901 ms | 0.0915 ms |
| apk, per query | 0.160 ms | 0.162 ms |
Query latency is unchanged: every per-type figure is within run-to-run noise, and hit counts are identical type by type. v7’s storage and build wins did not cost query speed, and did not buy any either. Anyone hoping 7.0 is “faster to scan” on a full local database should be told plainly that it is not; it is smaller and faster to produce.
A Java-only workload (1,500 maven purls), answered from the full v7 database vs from the maven shard alone:
| full v7 DB | maven shard | |
|---|---|---|
| On disk | 3,707,904,000 B (3.45 GiB) | 36,880,384 B (35 MiB), 100x less |
| Hits | 2,370 | 2,370 (identical) |
| Per query | 0.081 ms | 0.140 ms |
| Max RSS | 51.2 MB | 51.0 MB |
So: 100x less data to download, store and keep current, for identical answers, at roughly +0.06 ms per query of fan-out overhead (coverage resolution per call in shard mode). At 1,500 packages that is 88 ms of extra CPU against gigabytes of avoided transfer. Memory is unchanged, as expected: SQLite is mmap/page-cache bound, not load-the-DB-into-RAM.
Shard sizes from the same build (total 4.7 GiB vs 3.45 GiB for the full DB, a ~1.36x duplication cost for the partitioning, paid by the publisher, not by any single consumer):
| shard | size | shard | size | |
|---|---|---|---|---|
| app | 1.6 GiB | deb | 399 MiB | |
| npm | 1.1 GiB | pypi | 99 MiB | |
| apk | 833 MiB | cpe | 50 MiB | |
| rpm | 617 MiB | maven | 35 MiB | |
| golang | 34 MiB |
--include-metadata off on both sides.