HeliosDB Full Performance Benchmarks & Metrics

Comprehensive Performance Analysis Across All Features

This document provides detailed performance metrics, benchmarks, cost analysis, and optimization guidelines for HeliosDB Full. The figures come from internal tests of an earlier HeliosDB Full release against the targets and baselines shown; several of the features measured here (scale-to-zero, autoscaling, sharding, multi-node storage) are planned for the current release, which runs as a single server.

Executive Summary

All Performance Targets Met or Exceeded

Git Branching: 58x faster than target (555μs vs 100ms)
Scale-to-Zero: 43% faster resume (170ms vs 300ms)
Autoscaling: 5-20x faster scale-up (600-2,100ms vs 10s)
Query-from-Any-Node: 3-5x throughput improvement (met target)
Shard Rebalancing: 2x better write spike (<5ms vs <10ms target)
HCC v2 Compression: 10-15x ratio (met 8-12x target)
Schema Sharding: 5x faster routing (0.1-0.4ms vs 2ms)
Distributed FKs: 5x faster co-located (<1ms vs <5ms)
3-Tier Storage: 6% better cost reduction (85% vs 80% target)
Safekeeper: 50% write latency reduction (met target)
Online Sharding: 10x faster cutover (<100ms vs <1s)
Multi-Tenant Quotas: 100x faster checks (<1μs vs <100μs)

Major Features Performance
PostgreSQL Compatibility Performance
Oracle Compatibility Performance
HTAP Workload Performance
Infrastructure Cost Examples
Optimization Guidelines

Major Features Performance

Tier 1: Developer Experience

1. Git-Style Database Branching

Metric	Target	Achieved	Result
Branch creation time	<100ms	555μs	58x faster
Storage overhead (empty branch)	<1%	0%	Zero overhead
Read overhead	<5%	<1%	5x better
Write overhead	<20%	~10%	2x better

Benchmark Details:

Branch from timestamp: 555μs
Branch from LSN: 623μs
Branch checkout: <1ms
Branch delete (async): Background process

Storage Efficiency:

Empty branch: 0 bytes
1000 row changes: ~50KB delta SSTable
1M row changes: ~45MB delta SSTable
Compression ratio: Same as HCC v2 (10-15x)

2. Scale-to-Zero Serverless Compute

Metric	Target	Achieved	Result
Suspend time	<1s	~820ms	18% faster
Resume time	<300ms	170ms	43% faster
State size	<20MB	<10MB	50% smaller
Billing accuracy	<5% error	<1% error	5x better

Suspend Breakdown:

Checkpoint transactions: ~300ms
Flush buffer cache: ~400ms
Persist connection state: ~100ms
Stop compute process: ~20ms
Total: ~820ms

Resume Breakdown:

Start compute process: ~50ms
Restore connection state: ~30ms
Warm up buffer cache (lazy): ~90ms
Total: ~170ms

Illustrative compute cost (2 CU compute node at an assumed $0.20/CU-hour):

Traditional (always-on): 730 hours/month = 1,460 CU-hours = $292/month
Dev (4 hrs/day): 120 hours/month = 240 CU-hours = $48/month (84% savings)
Staging (8 hrs/day): 240 hours/month = 480 CU-hours = $96/month (67% savings)

3. Dynamic Autoscaling

Metric	Target	Achieved	Result
Scale-up latency	<10s	600-2,100ms	5-20x faster
Scale-down latency	<60s	<60s	Met target
Oscillation prevention	>90%	98.4%	Exceeded
Cost savings vs. static	>20%	28.75%	44% better

Scaling Performance by Trigger:

CPU > 80%: +0.5 CU in 600-1,200ms
Queue > 10: +1.0 CU in 800-2,100ms
CPU < 30% (5min): -0.5 CU in <60s
Idle (5min): Scale to 0 in <5s

Real-World Example (E-Commerce Site):

Peak hours (9am-9pm): 4 CUs × 12 hours = 48 CU-hours/day
Off-peak (9pm-9am): 1 CU × 12 hours = 12 CU-hours/day
Idle weekends: 0 CUs × 48 hours = 0 CU-hours
Monthly: 1,320 CU-hours (vs. 1,460 always-on) = 10% savings
With weekday variations: 28.75% average savings

4. Query-from-Any-Node Architecture

Metric	Target	Achieved	Result
Throughput gain	3-5x	3-5x	Met target
Routing latency	<5ms	<1ms	5x faster
Cache miss rate	<10%	<5%	2x better
Invalidation latency	<50ms	<10ms	5x faster

Throughput Comparison (10 compute nodes):

Coordinator-only: 1,000 queries/sec maximum
Query-from-any-node: 3,000-5,000 queries/sec
Improvement: 3-5x

Metadata Cache Performance:

Cache size: 512MB default (configurable)
Cache hit rate: >95%
Cache invalidation broadcast: <10ms
Automatic refresh: <50ms

Tier 2: Scalability

5. Zero-Downtime Shard Rebalancing

Metric	Target	Achieved	Result
Write latency spike	<10ms	<5ms	2x better
Cutover window	<1s	<100ms	10x faster
Migration throughput	1GB/min	Variable (throttled)	Throttled
Read impact	0ms	0ms	Zero impact

7-Step Rebalancing Process:

Select shards: ~1s
Create target shard: ~30s
Setup replication: ~1m
Bulk copy: Variable (hours for TB shards, >100MB/s)
Catch-up: Minutes (wait for lag < 1000 records)
Cutover: <100ms (lock + drain + update + unlock)
Cleanup: ~1m

Write Latency During Rebalancing:

Normal: <1ms
During bulk copy: <1.2ms (+20%)
During cutover: <5ms spike for <100ms window
After cutover: <1ms (back to normal)

6. Enhanced Columnar Compression (HCC v2)

Data Type	HCC v1	HCC v2	Improvement
Low-cardinality	6-8x	12-15x	2x better
High-cardinality	3-5x	8-10x	2x better
Sorted integers	8-10x	15-20x	2x better
Text (English)	4-6x	10-12x	2x better
JSON	3-4x	8-10x	2.5x better

Compression Algorithm Selection:

Algorithm	Use Case	Compression Ratio	CPU Overhead
Dictionary Encoding	Low-cardinality columns	12-15x	<2%
Delta Encoding	Sorted/sequential integers	15-20x	<1%
Run-Length Encoding	Repeated values	10-15x	<1%
ZSTD Level 3	General-purpose	8-10x	<5%
LZ4	Fast decompression	6-8x	<2%
Frame-of-Reference	Numeric ranges	12-15x	<2%
Bit-Packing	Small integers (0-255)	10-12x	<1%
Null Suppression	Sparse columns	Variable	<1%

Illustrative storage cost (100TB database at an assumed $0.15/GB-month):

HCC v1 @ 6x: 16.7TB actual storage = $2,500/month
HCC v2 @ 12x: 8.3TB actual storage = $1,250/month
Savings: $1,250/month = $15,000/year

7. Schema-Based Sharding

Metric	Target	Achieved	Result
Routing latency	<2ms	0.1-0.4ms	5x faster
Schema isolation	100%	100%	Perfect
FK validation	<5ms	<1ms	5x faster
Migration downtime	<1s	<100ms	10x faster

Routing Performance:

Schema lookup (cached): 0.1ms
Schema lookup (cache miss): 0.4ms
Query planning: <0.5ms
Total: 0.1-0.4ms routing latency

Multi-Tenant Scalability:

1,000 schemas: 0.1ms routing (cache hit)
10,000 schemas: 0.2ms routing (larger cache)
100,000 schemas: 0.4ms routing (cache overflow)

8. Distributed Foreign Key Validation

Metric	Target	Achieved	Result
Co-located FK	<5ms	<1ms	5x faster
Reference table FK	<5ms	<1ms	5x faster
Cross-shard FK	<20ms	<10ms	2x faster
Join speedup	10-20x	37.5x	2-4x better

Three Validation Strategies Performance:

Co-located FKs (same shard key):
- Local shard lookup: <0.5ms
- Index scan: <0.3ms
- Total: <1ms
Reference Tables (replicated):
- Local replica lookup: <0.5ms
- Index scan: <0.3ms
- Total: <1ms
Cross-Shard FKs (distributed):
- Remote node lookup: <5ms
- Index scan: <3ms
- Caching: -50% latency on repeat
- Total: <10ms (first lookup), <5ms (cached)

Join Performance (1M row table):

Co-located join: 2.4s (local execution on each shard)
Broadcast join (small table): 5.2s (replicate small table)
Repartition join: 18.5s (repartition large table)
No optimization: 90s (cross-shard shuffle)
Speedup: 37.5x (co-located vs. no optimization)

Tier 3: Cloud-Native

9. 3-Tier Storage (Hot/Warm/Cold)

Tier	Medium	Latency Target	Achieved	Result
Hot	NVMe SSD	<1ms	<1ms	Met
Warm	SATA SSD	1-5ms	1-5ms	Met
Cold	S3	10-50ms	10-50ms	Met

Migration Throughput:

Hot → Warm: 500MB/s (local disk)
Warm → Cold: 100MB/s (throttled, S3 upload)
Cold → Warm: 150MB/s (S3 download)

Illustrative storage cost (100TB database; assumed per-GB prices, infrastructure only):

Tier	Data Volume	Cost/GB/Month	Monthly Cost
All Hot (Baseline)	100TB	$0.15	$15,000
3-Tier Distribution
- Hot (1TB)	1,000 GB	$0.15	$150
- Warm (5TB)	5,000 GB	$0.04	$200
- Cold (94TB)	94,000 GB	$0.02	$1,880
Total	100TB	-	$2,230
Difference	-	-	$12,770/month (85%)

10. Safekeeper Consensus Layer

Metric	Target	Achieved	Result
Write latency reduction	50%	50%	Met
Durability copies	3	3	Met
Recovery time	<10s	<5s	2x faster
WAL replication lag	<100ms	<50ms	2x faster

Write Path Latency:

Traditional (2 RTT): Primary → Sync Mirror → ACK = 2 × Network RTT
Safekeeper (1 RTT): Primary → Safekeeper Quorum (2/3) → ACK = 1 × Network RTT
Reduction: 50%

Example (5ms network RTT):

Traditional: 2 × 5ms = 10ms write latency
Safekeeper: 1 × 5ms = 5ms write latency
Improvement: 5ms faster (50% reduction)

Recovery Performance:

Traditional: Replay WAL from disk (~10s for 1GB WAL)
Safekeeper: WAL already in memory (~5s for 1GB WAL)
Improvement: 2x faster recovery

11. Online Table Sharding Migration

Metric	Target	Achieved	Result
Cutover window	<1s	<100ms	10x faster
Migration throughput	50K rows/s	>100K rows/s	2x faster
Write impact	<5%	<3%	40% better
Read impact	0%	0%	Zero

7-Phase Process Timing (10B row table, 5TB):

Validation: ~5s
Shard creation: ~30s
Replication setup: ~1m
Bulk data copy: ~14 hours (>100K rows/s, ~100MB/s)
Replication catch-up: ~10m (wait for lag < 1000 rows)
Cutover: <100ms (lock + drain + update + unlock)
Cleanup: ~1m Total: ~14.2 hours (mostly bulk copy in background)

Write Latency During Migration:

Normal: <1ms
During migration: <1.03ms (+3%)
During cutover: <5ms spike for <100ms
After migration: <1ms

12. Multi-Tenant Resource Quotas

Metric	Target	Achieved	Result
Quota check latency	<100μs	<1μs	100x faster
Enforcement accuracy	>99%	99.9%	10x better
Priority scheduling	Works	Works	Met
Tenant isolation	100%	100%	Perfect

QoS Tier Performance (1,000 tenants):

Bronze (700 tenants): 2 CU each = 1,400 CUs total
Silver (250 tenants): 8 CU each = 2,000 CUs total
Gold (50 tenants): 32 CU each = 1,600 CUs total
Total: 5,000 CUs with fair allocation

Quota Enforcement Latency:

In-memory quota check: <1μs
Quota update (on change): <10μs
Violation detection: <5μs
Total overhead: <1μs per query

PostgreSQL Compatibility Performance

Wire Protocol Performance

Operation	PostgreSQL 17 Native	HeliosDB Full	Ratio
Simple SELECT	Baseline	85-90%	0.85-0.90x
Complex JOIN (3 tables)	Baseline	80-85%	0.80-0.85x
INSERT (single)	Baseline	90-95%	0.90-0.95x
INSERT (bulk 1000 rows)	Baseline	75-80%	0.75-0.80x
UPDATE (indexed column)	Baseline	85-90%	0.85-0.90x
DELETE (indexed row)	Baseline	85-90%	0.85-0.90x
B-tree Index Scan	Baseline	90-95%	0.90-0.95x
Full Table Scan	Baseline	95-100%	0.95-1.00x
Aggregate (COUNT, SUM)	Baseline	80-85%	0.80-0.85x
Window Functions	Baseline	75-80%	0.75-0.80x

Performance Goal: 95% parity with native PostgreSQL (on track)

Benchmark Setup:

PostgreSQL 17.0 on Ubuntu 22.04
HeliosDB Full on Ubuntu 22.04
Hardware: 8 cores, 32GB RAM, NVMe SSD
Dataset: 10M rows, 100 tables, 50GB total

Oracle Compatibility Performance

PL/SQL execution through the Oracle listener — procedures, functions, anonymous blocks and common DBMS_ packages — is on the roadmap. PL/SQL performance figures will be published once PL/SQL runs through the Oracle protocol. Today, port PL/SQL to PL/pgSQL functions and run them through the PostgreSQL interface, or move the logic into the application tier.

HTAP Workload Performance

OLTP Performance (TPC-C)

Metric	Earlier baseline	Measured	Improvement
Transactions/sec	125K TPS	162.5K TPS	+30% (query-from-any-node)
Average latency	8ms	6ms	+25%
95th percentile	15ms	12ms	+20%

Improvement Breakdown:

Query-from-any-node: +30%
HCC v2 compression (less I/O): +5%
Metadata service optimization: +10%

OLAP Performance (TPC-H Q6)

Metric	Earlier baseline	Measured	Improvement
Exact query (scan 100M rows)	12s	11s	+8%
Approximate query (1% sample)	0.3s	0.28s	+7%

Improvement Breakdown:

HCC v2 compression (less I/O): +8%
Query optimization: +5%
3-tier storage (hot tier): +3%

Time-Series Ingestion

Metric	Earlier baseline	Measured	Improvement
Rows/sec	500K/s	650K/s	+30%
Write latency (p99)	5ms	4ms	+20%

Improvement Breakdown:

HCC v2 compression (faster writes): +15%
Safekeeper (1 RTT vs 2 RTT): +10%
Autoscaling (more resources during spikes): +10%

Other Workloads

Workload	Earlier baseline	Measured	Improvement
Full-Text Search	10ms	9ms	+10%
Geospatial KNN	20ms	18ms	+10%
ML Inference	<5ms	<4ms	+20%
Cross-Region Replication	<100ms	<95ms	+5%

Infrastructure Cost Examples

The examples below are illustrative infrastructure calculations using the assumed unit prices shown (compute at $0.20/CU-hour; storage at the per-GB prices listed). They cover compute and storage only and do not include HeliosDB licence costs; substitute your own provider prices and usage.

Development + Staging Databases

Scenario: 10 dev databases + 5 staging databases, each 2 CUs

Traditional (Always-On):

10 dev: 2 CU × 730 hours = 14,600 CU-hours/month ($2,920/month)
5 staging: 2 CU × 730 hours = 7,300 CU-hours/month ($1,460/month)
Total: $4,380/month ($52,560/year)

HeliosDB Full (Scale-to-Zero):

10 dev (4 hrs/day): 2 CU × 120 hours = 2,400 CU-hours/month ($480/month)
5 staging (8 hrs/day): 2 CU × 240 hours = 2,400 CU-hours/month ($480/month)
Total: $960/month ($11,520/year)

Difference: $41,040/year (78% fewer compute hours)

Storage Costs (100TB Database)

Traditional (All NVMe):

100,000 GB × $0.15/GB = $15,000/month

HeliosDB Full (3-Tier):

Hot (1TB NVMe): 1,000 GB × $0.15/GB = $150/month
Warm (5TB SATA): 5,000 GB × $0.04/GB = $200/month
Cold (94TB S3): 94,000 GB × $0.02/GB = $1,880/month
Total: $2,230/month

Difference: $153,240/year (85% lower storage cost)

Optimization Guidelines

1. Use Git-Style Branching for Testing

Best Practice:

Create branch per pull request
Test schema migrations on branch
Delete branch after merge

Benefits:

Zero risk to production
Fast branch creation (555μs)
No storage overhead

2. Enable Scale-to-Zero for Dev/Staging

Configuration:

autoscaling:
  enabled: true
  min_cu: 0.0
  scale_to_zero_after: 300s  # 5 minutes

Benefits:

84% cost reduction for dev databases
67% cost reduction for staging databases

3. Configure Autoscaling for Production

Configuration:

autoscaling:
  enabled: true
  min_cu: 2.0                # Always have 2 CUs minimum
  max_cu: 16.0               # Scale up to 16 CUs
  target_cpu: 70             # Target 70% CPU utilization
  scale_up_threshold: 80     # Scale up at 80%
  scale_down_threshold: 30   # Scale down at 30%

Benefits:

Handle traffic spikes automatically
28.75% cost savings vs. static provisioning
Better performance during peaks

4. Use 3-Tier Storage for Large Datasets

Configuration:

tiered_storage:
  enabled: true
  policies:
    hot_to_warm: 7d
    warm_to_cold: 30d

Benefits:

85% cost reduction for 100TB database
Automatic tiering (no manual intervention)
Performance maintained for hot data

5. Use Schema-Based Sharding for Multi-Tenancy

SQL:

-- Shard entire schema (simpler than column-based sharding)
CREATE SCHEMA tenant_1234 DISTRIBUTED;

Benefits:

Zero application changes
Natural isolation boundaries
Simplified foreign keys

6. Enable HCC v2 Compression

SQL:

CREATE TABLE events (
    ...
) WITH (
    compression = 'hcc_v2',
    compression_level = 'high'
);

Benefits:

10-15x compression ratio
50% storage cost reduction vs. HCC v1
Adaptive algorithm selection

SQL:

-- Shard both tables by same key
CREATE TABLE users (...) SHARD BY (tenant_id);
CREATE TABLE orders (...) SHARD BY (tenant_id);

-- Result: 37.5x faster joins

Benefits:

<1ms FK validation
37.5x join speedup
Local execution on each shard

Summary

All Performance Targets Met or Exceeded:

Key Achievements:

58x faster Git branching (555μs)
Scale-to-zero for dev/staging (84% fewer compute hours in the example above)
3-tier storage (85% lower storage cost in the example above)
3-5x query throughput (query-from-any-node)
10-15x compression (HCC v2)
37.5x join speedup (distributed FKs)

HeliosDB Full Performance Benchmarks & Metrics

Executive Summary

Table of Contents

Major Features Performance

Tier 1: Developer Experience

1. Git-Style Database Branching

2. Scale-to-Zero Serverless Compute

3. Dynamic Autoscaling

4. Query-from-Any-Node Architecture

Tier 2: Scalability

5. Zero-Downtime Shard Rebalancing

6. Enhanced Columnar Compression (HCC v2)

7. Schema-Based Sharding

8. Distributed Foreign Key Validation

Tier 3: Cloud-Native

9. 3-Tier Storage (Hot/Warm/Cold)

10. Safekeeper Consensus Layer

11. Online Table Sharding Migration

12. Multi-Tenant Resource Quotas

PostgreSQL Compatibility Performance

Wire Protocol Performance

Oracle Compatibility Performance

HTAP Workload Performance

OLTP Performance (TPC-C)

OLAP Performance (TPC-H Q6)

Time-Series Ingestion

Other Workloads

Infrastructure Cost Examples

Development + Staging Databases

Storage Costs (100TB Database)

Optimization Guidelines

1. Use Git-Style Branching for Testing

2. Enable Scale-to-Zero for Dev/Staging

3. Configure Autoscaling for Production

4. Use 3-Tier Storage for Large Datasets

5. Use Schema-Based Sharding for Multi-Tenancy

6. Enable HCC v2 Compression

7. Co-locate Related Tables for Best Join Performance

Summary