Benchmarking HeliosDB vs PostgreSQL
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 (384x) 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
All benchmark scripts, configurations, and raw results are available in our benchmarks/ directory on GitHub. We encourage you to run them on your own hardware and share results. Fair benchmarking requires community scrutiny.