Benchmarks¶

Measured performance data for Uni across ingestion, querying, graph traversal, vector search, and graph algorithms. All numbers come from the Criterion benchmark suite (cargo bench) and are reproducible.

Last updated: 2026-04-01

Executive Summary¶

Test Environment¶

All benchmarks run on a single machine using Criterion 0.5 with harness = false. Each measurement uses 10 samples (comprehensive/mutation/algo suites) or 100 samples (micro suite). Datasets use in-memory or temp-dir storage with auto_flush_threshold: 100_000.

Benchmark Configurations¶

Three dataset sizes used for scaling analysis:

Schema: Person label with name (String), age (Int32), embedding (Vector[128]). Edge type: KNOWS.

Ingestion Performance¶

Cypher INSERT Throughput¶

Per-statement ingestion via CREATE inside a transaction. Each vertex carries a name, age, and 128-dimensional embedding vector.

Parameterized queries are ~20% faster at 1K scale because the plan cache can reuse parsed/planned queries and only substitute parameter values. At 8K the gap narrows as L0 buffer pressure dominates.

Flush Performance (L0 to L1)¶

Flush converts the in-memory L0 buffer to persistent Lance columnar storage:

Flush time scales linearly with entity count. Throughput improves with batch size due to amortized Arrow serialization and Lance write overhead.

Mutation Performance¶

Benchmarked with in-memory Uni instances, 100-node operations per measurement:

Key observations:

• MERGE is ~2.4x slower than CREATE because each MERGE must first check existence (read + conditional write), while CREATE is write-only.
• SET and DELETE are fast because they operate on already-indexed vertices in the L0 buffer.
• Transaction overhead is included in all measurements (tx begin + commit).

Query Performance¶

Point Lookup¶

Single-vertex retrieval by string property after bulk insert + flush:

Point lookup scales approximately O(1) with dataset size — the query planner pushes the filter predicate into the Lance scan, enabling predicate pushdown at the storage layer.

Aggregation¶

Full-scan aggregations over all vertices:

COUNT and GROUP BY require a full table scan — 8x more data yields ~7x more time. AVG uses columnar statistics and returns in constant time regardless of dataset size.

Indexed Queries¶

Queries using BTree, HNSW, or fulltext indexes created via Cypher DDL:

BTree and fulltext indexes deliver nearly constant-time lookups. Vector KNN scales sub-linearly (O(log n)) due to the HNSW graph structure.

Index Creation¶

Time to build an index on an already-populated and flushed dataset:

Index creation scales linearly with dataset size. All three index types have comparable build times at these scales.

Order By + Limit¶

MATCH (n:Person) RETURN n.name, n.age ORDER BY ... LIMIT 10:

Sub-linear scaling thanks to the LIMIT 10 clause — the engine uses a top-N heap instead of a full sort.

Graph Traversal Performance¶

Cypher Traversal (via Comprehensive Suite)¶

Starting from a single vertex (Person_0), following KNOWS edges:

Traversal from a single start vertex stays flat regardless of total graph size — the working set (reachable neighbors) is determined by local topology, not total vertex count.

Low-Level Traversal (via Micro Suite)¶

Direct storage-layer traversal benchmarks, bypassing the Cypher parser/planner:

The CSR adjacency structure provides near-zero-cost neighbor access — a single slice lookup followed by sequential memory reads.

SimpleGraph Construction¶

In-memory graph building performance (10K vertices, 50K edges):

Pre-allocation saves ~23% by avoiding hash map resizing.

Vector Search Performance¶

Raw Vector Search (via Micro Suite)¶

Direct storage-layer vector search, bypassing Cypher:

Cypher Vector Search (via Comprehensive Suite)¶

Vector similarity filter via Cypher (WHERE vector_similarity(...) > 0.8):

Indexed KNN¶

CALL uni.vector.query('Person', 'embedding', $vec, 10) with HNSW index:

Hybrid Query Performance¶

Combined vector similarity + graph traversal query:

MATCH (a:Person)-[:KNOWS]->(b:Person)
WHERE vector_similarity(a.embedding, $vec) > 0.8 AND b.age >= 1
RETURN b.name

Hybrid queries show super-linear growth with edge density. At 8K/12K, the vector filter matches more start vertices (8x more nodes) and each has more outgoing edges (1.5x density), multiplying the traversal fan-out. This is the most edge-density-sensitive workload.

Graph Algorithm Performance¶

All algorithms benchmarked on random graphs with 1,000 nodes and 5 edges per node (avg degree = 5). Execution includes Cypher parsing, planning, graph projection, and algorithm execution.

At 1K nodes / 5K edges, most algorithms complete in 6-12 ms including full Cypher overhead (parse → plan → project → execute → collect). The graph projection step (loading CSR from storage) is amortized across the algorithm execution.

Scaling Analysis¶

What Scales Linearly (Full-Scan Bound)¶

These operations must touch every row and scale proportionally with data size:

What Stays Constant (Index/Cache Bound)¶

These operations use indexes or local graph structure and are independent of total data size:

What Scales Sub-Linearly (O(log n))¶

What Scales Super-Linearly (Edge-Density Sensitive)¶

The hybrid query is sensitive to both node count (more vector matches) and edge density (more traversal fan-out per match). This is expected and can be mitigated with tighter vector thresholds or earlier LIMIT clauses.

Running Benchmarks¶

Benchmark Suites¶

Running¶

# Run all benchmarks
cargo bench

# Run a specific suite
cargo bench --bench comprehensive
cargo bench --bench algo_benchmarks
cargo bench --bench mutation_benchmarks
cargo bench --bench micro_benchmarks

# Run with custom dataset size (comprehensive suite)
BENCH_NODES=5000 BENCH_EDGES=2500 cargo bench --bench comprehensive

# Run only matching benchmarks
BENCH_NODES=1000 cargo bench --bench comprehensive -- traversal

# Algorithm benchmarks with custom graph size
BENCH_NODES=2000 BENCH_EDGES_PER_NODE=10 cargo bench --bench algo_benchmarks

# Save baseline and compare
cargo bench -- --save-baseline main
# ... make changes ...
cargo bench -- --baseline main

# View HTML reports
open target/criterion/report/index.html

Profiling¶

# CPU profiling with perf
perf record cargo bench --bench comprehensive -- traversal
perf report

# Flame graphs
cargo flamegraph --bench comprehensive -- --bench

Next Steps¶

• Vectorized Execution — Execution engine details
• Storage Engine — Storage layer internals