Benchmarking HeliosDB vs PostgreSQL
Editor's note (2026-10-15): The figures in this November 2025 post are internal tests of a 2025 HeliosDB build. The post did not record the edition, version or fixture, the figures have not been reproduced on current releases, and the benchmark scripts it mentions are not published. Current figures, each with its edition, version and fixture, are on benchmarks.html; reproduce any comparison on your own hardware before relying on it.
Fair benchmarks are hard. Every database vendor publishes numbers that make their product look good, often by cherry-picking workloads, hardware, or configurations. Today we're sharing our benchmarking methodology and results, comparing HeliosDB against PostgreSQL 16 across OLTP, OLAP, vector search, and multi-tenant workloads on identical hardware.
Methodology
All benchmarks ran on the same hardware: bare-metal servers with 32 vCPU (AMD EPYC), 128 GB RAM, NVMe SSD storage. Both databases were tuned for the workload with recommended production settings. PostgreSQL used shared_buffers = 32GB, effective_cache_size = 96GB, work_mem = 256MB. HeliosDB used default settings (which auto-tune to available resources).
OLTP: Point Operations
Workload: YCSB-A (50% read, 50% update), 10M rows, 16 threads
| Metric | PostgreSQL 16 | HeliosDB | Difference |
|---------------------|--------------|--------------|------------|
| Throughput (ops/sec) | 125,000 | 340,000 | 2.7x |
| Read latency p50 | 0.4ms | 0.15ms | 2.7x |
| Read latency p99 | 2.1ms | 0.8ms | 2.6x |
| Update latency p50 | 0.6ms | 0.2ms | 3.0x |
| Update latency p99 | 3.8ms | 1.2ms | 3.2x |HeliosDB's advantage comes from two factors: (1) RocksDB's LSM-tree is optimized for write-heavy workloads with sequential I/O, and (2) our async I/O pipeline avoids the per-connection process overhead of PostgreSQL's process-per-connection model.
OLAP: Analytical Queries
Workload: TPC-H SF10 (10GB dataset), single-threaded
| Query | PostgreSQL 16 | HeliosDB | Speedup |
|-------|--------------|----------|---------|
| Q1 | 12.4s | 3.8s | 3.3x |
| Q3 | 8.7s | 2.1s | 4.1x |
| Q5 | 15.2s | 4.5s | 3.4x |
| Q6 | 4.1s | 0.9s | 4.6x |
| Q9 | 22.3s | 7.8s | 2.9x |
| Q13 | 6.8s | 1.9s | 3.6x |
| Total | 142s | 41s | 3.5x |HeliosDB's columnar storage engine (based on Apache Arrow) provides significant advantages for analytical queries that scan large amounts of data. The vectorized execution engine processes data in batches, maximizing CPU cache utilization.
Vector Search
Workload: 1M vectors, 768 dimensions (BERT embeddings), top-10 retrieval
| Metric | PostgreSQL + pgvector | HeliosDB (HNSW) | Difference |
|------------------|----------------------|------------------|------------|
| Index build time | 340s | 120s | 2.8x |
| Query latency p50| 4.2ms | 0.8ms | 5.3x |
| Query latency p99| 18ms | 8ms | 2.3x |
| Recall@10 | 92% | 95%+ | +3% |
| Memory usage | 6.2 GB | 2.1 GB (with PQ) | 3.0x |HeliosDB's native HNSW implementation with Product Quantization provides significantly lower latency and memory usage. Our PQ compression (about 16× less resident RAM at recall-safe defaults (internal tests, Nano 3.32.1 vs an unquantized index, see benchmarks.html)) allows much larger datasets to fit in memory, while pgvector stores vectors at full precision.
Multi-Tenant Performance
Workload: 1000 tenants, mixed OLTP, shared database
| Metric | PostgreSQL + RLS | HeliosDB Multi-Tenant | Difference |
|-----------------------|-----------------|----------------------|------------|
| Tenant registration | 500ms | < 100ms | 5x |
| RLS overhead | 12-15% | < 5% | 3x |
| Quota enforcement | N/A (manual) | < 1ms (built-in) | N/A |
| Concurrent tenants | ~5,000 | 100,000+ | 20x |
| Context switch | 200μs | < 50μs | 4x |
| Per-tenant QPS | 2,000 | 10,000+ | 5x |HeliosDB's built-in multi-tenancy with native RLS, resource quotas, and tenant isolation delivers significantly better performance than PostgreSQL's RLS policies, which add overhead to every query through policy evaluation.
Where PostgreSQL Wins
To be fair, PostgreSQL excels in areas where maturity and ecosystem matter most: extension ecosystem (PostGIS, TimescaleDB, Citus), tooling (pgAdmin, pg_dump, logical replication), and battle-tested reliability over 30+ years of production use. HeliosDB is newer and our ecosystem is still growing.
Reproducing These Benchmarks
The scripts behind these November 2025 figures are not published. Current figures, with the edition, version and fixture for each, are on benchmarks.html. We encourage you to measure on your own hardware and share results. Fair benchmarking requires community scrutiny.