Benchmarks

All numbers on this page are measured on real hardware against real datasets with --release builds. Random-vector HNSW benchmarks are not reported - only SIFT-1M or equivalent ANN-benchmarks datasets. Source of truth: docs/BENCHMARKS.md.

Note

Every number below is reproducible with the command shown beneath it. No synthetic or estimated numbers are published.

Hardware

The HNSW, test suite, and encryption benchmarks run on AWS c6id.4xlarge:

CPU: Intel Xeon Platinum 8375C (Ice Lake), 16 vCPU
RAM: 32 GiB
Storage: 884 GB instance-store NVMe
OS: Ubuntu 24.04, io_uring backend
Build: cargo build --release
Commit: 871bd99 (v0.7.0)

HNSW on SIFT-1M

Dataset: SIFT-1M - 1,000,000 × 128-dim float32 vectors, 10,000 queries, pre-computed ground truth.

Source: ftp://ftp.irisa.fr/local/texmex/corpus/sift.tar.gz
SHA256: 92f1270c5e3a0cb46b89983e72b0511e4df065c31a9fa0276d8c9b1fca5bc81a

Build: M=16, ef_construction=200 → 65.4 s (15,295 vec/sec)

ef_search	recall@10	mean latency	p99 latency
10	0.756	57.7 µs	105 µs
50	0.959	156.7 µs	229 µs
100	0.983	266.7 µs	364 µs
200	0.990	458.9 µs	612 µs

bash

cargo build --release -p galaxdb-benchmarks
./target/release/galaxdb-sift-bench \
    --dataset /path/to/sift \
    --ef-search 10,50,100,200 \
    --commit-sha "$(git rev-parse HEAD)" \
    --instance-type c6id.4xlarge \
    --dataset-sha256 92f1270c5e3a0cb46b89983e72b0511e4df065c31a9fa0276d8c9b1fca5bc81a \
    --timestamp-utc "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
    --output bench-results/sift_bench.json

The HNSW path is unchanged by later SQL/durability fixes, so these numbers hold for v0.7.0.

RGABH Adaptive Buffer Pool

Skewed-workload hit-rate benchmark (deterministic Zipfian trace, ~80% of accesses hit a 1,500-key hot set, 50,000-key cold tail):

Policy	HotSet hit rate
LRU/clock baseline	0.6391
RGABH adaptive	0.8030
Delta	+16.39 pp

Hardware: Intel Core i7-7820HQ, macOS 13.7.8, rustc 1.97.0, --release. Reproducible: cargo run --release -p galaxdb-storage --example rgabh_hitrate

DiskANN Recall

Recall verified against exact brute-force ground truth on real clustered data (--release, cargo test --release -p galaxdb-vector diskann):

Metric	Dimension	Result
recall@10 (cosine)	32-dim	>= 0.90
recall@10 (L2)	12-dim	>= 0.85

SIFT-1M full-scale numbers to follow once the AWS benchmark run completes. Harness: cargo run --release -p galaxdb-vector --example diskann_sift_recall

Test Suite

Confirmed on the same hardware as the vector benchmarks, release build, cargo test --release --lib across 10 crates:

Rust tests (common, crypto, storage, sql, embedded, vector, wire, query, …)	823 passed / 0 failed
Credential-gated cloud-KMS / Vault integration tests	skipped cleanly (no creds)

bash

cargo test --release --lib

Storage Write Path

GalaxDB and PostgreSQL 16.14 run on the same instance-store NVMe (PostgreSQL's data directory relocated onto it) with fsync=on. Both use prepared statements - an apples-to-apples comparison.

Concurrent INSERT vs PostgreSQL 16

Clients	GalaxDB	PostgreSQL 16
1	10,450 rows/s	11,891 rows/s
4	30,468 rows/s	34,298 rows/s
8	36,632 rows/s	54,432 rows/s
16	37,448 rows/s	84,747 rows/s

GalaxDB is competitive at low concurrency (0.88× PostgreSQL at 1 client, 0.89× at 4 clients); PostgreSQL's process-per-connection model scales better past 8 clients (GalaxDB 0.44× at 16). The remaining gap is the async server's per-query spawn_blocking hand-off, not the storage engine.

bash

TMPDIR=/mnt/nvme/tmp ./target/release/concurrent-insert-bench \
    --rows 5000 --clients 1,4,8,16 --pg-port 5432

Bulk load and engine write path

Path	Throughput	What it measures
COPY FROM STDIN (wire)	190,287 rows/s, 17.1 MiB/s	bulk ingest, chunked group commit (25.97× vs row INSERT)
single-row INSERT (wire)	~8,525 rows/s	per-row roundtrip over the PostgreSQL protocol
put_sync (engine, 1 fsync/row)	~26,500 rows/s (37.7 µs/row)	strict per-row durability
put_batch_sync (engine, 1 fsync/batch)	~1.4–2.1M rows/s (0.5–0.7 µs/row)	in-memory path, amortized fsync

bash

TMPDIR=/mnt/nvme/tmp ./target/release/copy-bench --rows 200000
TMPDIR=/mnt/nvme/tmp ./target/release/single-row-insert-bench --rows 20000
TMPDIR=/mnt/nvme/tmp ./target/release/engine-microbench --max 200000

NVMe fsync ceiling on the same instance (pg_test_fsync): open_datasync 1,611 ops/s, fdatasync 1,091 ops/s, fsync 366 ops/s. Single-client strict-durability write throughput is bounded by this fsync latency on both engines.

Encryption

Measured with cargo bench -p galaxdb-crypto on the same hardware.

Operation	Latency	Throughput
AEGIS-256 decrypt 1 MB	151 µs	6.63 GB/s
AEGIS-256 encrypt 64 KB	9.75 µs	6.56 GB/s
AES-256-GCM decrypt 1 MB	701 µs	1.43 GB/s
XXH3-64 checksum 1 MB	-	34.1 GB/s
ART lookup (1M keys)	168 ns/op	-

Crash Safety

All 7 chaos scenarios pass in <30 s total:

Scenario	Result	Time
Kill mid-flush → WAL replay	✅ 1,000 rows recovered, zero loss	8.79 s
Kill mid-compaction → old blocks intact	✅ 4,000 keys readable	0.02 s
Corrupt WAL record → replay stops	✅ Partial recovery, no corrupt data	1.81 s
Disk full → clean checkpoint	✅ Reserve freed, reads continue	0.01 s
Kill sidecar → backlog preserved	✅ 50 requests queued, drained on recovery	0.00 s
100 concurrent writers	✅ 100K writes, 0 duplicates, 0 missing	0.13 s
OLAP scan during OLTP	✅ 0 HotSet evictions, OLTP p99 unaffected	0.15 s

bash

cargo run --release -p galaxdb-chaos-tests

Docker Compose

Contributing