perf: SPARQL hexastore index crossover analysis (hydrate+N3 vs direct indexed queries)

[EthanThatOneKid]

Migrated from a closed issue. Benchmark conclusions are stable; track follow-up work in new issues if needed.

Original issue: https://github.com/wazootech/worlds-client-ts/issues/8

---

Hexastore SPARQL crossover benchmark

This issue documents the performance crossover analysis between two SPARQL query strategies on the hexastore branch:

• Hydrate→N3.Store: Load all quads from LibSQL into an in-memory N3.Store, then query via Comunica
• Direct hexastore: Query directly against LibsqlStore using hexastore covering indexes, no hydration needed

Methodology

• Runtime: Deno 2.7.14 (x86_64-pc-windows-msvc), all tests on :memory: SQLite
• Isolation: Each benchmark iteration creates a fresh DB, seeds N synthetic quads, and measures only the timed segment
• Patterns tested:
  • Subject-bound (selective): SELECT ?p ?o WHERE { <urn:entity:0> ?p ?o } — returns ~10 rows at any scale
  • Full-scan: SELECT ?s ?p ?o WHERE { ?s ?p ?o } LIMIT 100 — touches all rows

---

Results: Subject-bound query (hexastore sweet spot)

Dataset Size	N3 (hydrate+query) avg	Hexastore (direct) avg	Hexastore p75	Crossover
1,000 Quads	21.7 ms	14.6 ms	3.4 ms	Hexastore (1.5x avg)
5,000 Quads	92.5 ms	113.7 ms	3.1 ms	Tie (p75: 30x hexastore)
10,000 Quads	277.2 ms	90.4 ms	7.5 ms	Crossover — Hexastore (3x)
25,000 Quads	785.5 ms	293.8 ms	9.1 ms	Hexastore (2.7x avg)
50,000 Quads	2.2 s	2.2 s	22.9 ms	Hexastore (p75: 96x)

Crossover point: ~5k–10k quads for cold-start average latency. Beyond 10k, hexastore pull-away widens dramatically (3–96x faster).

Results: Full-scan query (LIMIT 100)

Dataset Size	N3 (hydrate+query)	Hexastore (direct)	Winner
1,000 Quads	20.4 ms	22.5 ms	N3 (1.1x)
5,000 Quads	74.1 ms	116.4 ms	N3 (1.6x)
10,000 Quads	220.4 ms	325.1 ms	N3 (1.5x)
25,000 Quads	1.0 s	1.1 s	N3 (1.1x)

For full scans, N3 consistently wins by ~1.1–1.6x — both approaches touch all data, but N3 avoids SQL deserialization overhead.

Key takeaways

Property	N3 Store	Hexastore
Cold-start latency	O(N) hydration	O(1) — zero upfront cost
Memory footprint	O(N) entire dataset	O(result set)
Selective query (p75)	~1 ms (no hydration)	3–23 ms (flat, any scale)
Full-scan query	O(N) hydrate + O(N) scan	O(N) SQL scan
Scales past RAM	No	Yes
Cold-start + 1 query (50k)	2.2 s	22.9 ms

Recommendation: Use hexastore for selective SPARQL queries on datasets >10k quads where hydration cost dominates, or when memory is constrained. Use N3.Store for repeatedly queried datasets <10k quads where the one-time hydration is amortized.

Related benchmarks

• perf: Scientific Client Pressure Benchmarks & Architectural Performance Boundaries #2 — LibSQL Client Pressure Test (write, hydration, FTS search)
• perf: Search Performance Analysis (RDFJS Naive Stream vs LibSQL FTS Index) #3 — RDFJS vs LibSQL FTS Search Performance Analysis

[EthanThatOneKid]

Post-preload SPARQL crossover (execute only, Deno 2.7.14 Windows)

Benchmarks now preload datasets and engines at module load; timed slices measure query execution only. See PR #67 and benchmarks/README.md post-preload table.

Quads	Query shape	Backend	Avg
1000	selective	hydrate+N3	511 µs
1000	selective	libsqlStore	1.0 ms
1000	fullScan	hydrate+N3	3.0 ms
1000	fullScan	libsqlStore	20.1 ms
5000	selective	hydrate+N3	362 µs
5000	selective	libsqlStore	2.3 ms
5000	fullScan	hydrate+N3	4.0 ms
5000	fullScan	libsqlStore	87.2 ms
10000	selective	hydrate+N3	274 µs
10000	selective	libsqlStore	3.1 ms
10000	fullScan	hydrate+N3	5.5 ms
10000	fullScan	libsqlStore	211 ms
25000	selective	hydrate+N3	462 µs
25000	selective	libsqlStore	9.5 ms
25000	fullScan	hydrate+N3	12.3 ms
25000	fullScan	libsqlStore	509 ms
50000	selective	hydrate+N3	357 µs
50000	selective	libsqlStore	15.2 ms
50000	fullScan	hydrate+N3	24.4 ms
50000	fullScan	libsqlStore	1.1 s

Notes: Fair timing requires module preload (or equivalent warm containers). hydrate+N3 wins on selective patterns when the graph is already in memory; libsqlStore is the scale path without mirroring the full graph into N3. Prior multi-second p99 outliers were largely per-iteration dynamic import and GC between bench slices, not raw SPARQL engine cost alone.

[EthanThatOneKid]

Follow-up (May 2026): Large-scale crossover methodology moved to discussion #69.

Post-PR #85: standard bench (1k–50k) still compares hydrate+N3 vs libsqlStore; 100k–1M is libsqlStore only, quads-only preload (searchIndexOnImport: false), optional BENCH_REUSE_DB=1 file cache for dev reruns. Pre-preload numbers in this thread are not comparable to current harness.

[EthanThatOneKid]

Post-preload SPARQL crossover through 1M (execute only, Deno 2.8.0 Windows)

Extended from the 1k–50k table above with large-scale captures after PR #85. Benchmarks preload datasets and engines at module load; timed slices measure sparqlEngine.execute() only. See discussion #69 for harness details and benchmarks/README.md.

100k–1M: libsqlStore only (createLibsqlClient) — production hexastore path without mirroring the full graph into N3 (#68). Preload uses searchIndexOnImport: false (quads only; no FTS/chunk build during import).

Quads	Query shape	Backend	Avg
1000	selective	hydrate+N3	1.4 ms
1000	selective	libsqlStore	2.5 ms
1000	fullScan	hydrate+N3	5.3 ms
1000	fullScan	libsqlStore	27.5 ms
5000	selective	hydrate+N3	806 µs
5000	selective	libsqlStore	4.5 ms
5000	fullScan	hydrate+N3	7.8 ms
5000	fullScan	libsqlStore	50.1 ms
10000	selective	hydrate+N3	683 µs
10000	selective	libsqlStore	7.5 ms
10000	fullScan	hydrate+N3	11.9 ms
10000	fullScan	libsqlStore	68.1 ms
25000	selective	hydrate+N3	671 µs
25000	selective	libsqlStore	19.1 ms
25000	fullScan	hydrate+N3	23.6 ms
25000	fullScan	libsqlStore	123 ms
50000	selective	hydrate+N3	638 µs
50000	selective	libsqlStore	39.4 ms
50000	fullScan	hydrate+N3	44.3 ms
50000	fullScan	libsqlStore	215 ms
100000	selective	libsqlStore	38.2 ms
100000	fullScan	libsqlStore	232 ms
250000	selective	libsqlStore	101 ms
250000	fullScan	libsqlStore	539 ms
500000	selective	libsqlStore	179 ms
500000	fullScan	libsqlStore	1.1 s
1000000	selective	libsqlStore	373 ms
1000000	fullScan	libsqlStore	2.2 s

Module preload (console.time, not in Deno.bench; :memory: libsqlStore, quads-only): ~20 s @ 100k, ~63 s @ 250k, ~130 s @ 500k, ~279 s @ 1M.

Notes:

• Selective (<urn:entity:0> ?p ?o): hydrate+N3 stays sub-millisecond through 50k when the graph is already in memory; libsqlStore scales roughly linearly to ~373 ms @ 1M without an N3 mirror.
• fullScan (?s ?p ?o LIMIT 100): hydrate+N3 still wins through 50k; libsqlStore reaches ~2.2 s @ 1M — avoid unbound triple patterns at production scale.
• Reproduce (standard): deno bench --allow-all benchmarks/sparql-hexastore-crossover.bench.ts
• Reproduce (large): deno task bench:crossover-large (opt-in; --v8-flags=--max-old-space-size=8192, 16 GB+ RAM recommended for 1M preload).