Open-source connection router, rate limiter, and intelligent query cache.
PgBouncer++ on steroids — 24 feature modules in a single component.
HeliosProxy transforms HeliosDB into a production-ready platform with connection pooling, intelligent caching, rate limiting, and enterprise resilience — all in one component.
| Challenge | Without Proxy | With HeliosProxy |
|---|---|---|
| Connection limits | App manages pools | Automatic pooling |
| Query caching | Manual Redis / Memcached | Built-in 3-tier cache |
| Rate limiting | External service | Native support |
| Multi-tenancy routing | App logic | Automatic routing |
| Circuit breaking | Manual implementation | Built-in resilience |
| GraphQL API | Separate gateway | Auto-generated |
| Authentication | Custom middleware | JWT, OAuth, LDAP, API Keys |
Three modes to match your workload. Achieve up to 100:1 connection multiplexing, turning 5,000 client connections into just 50 server connections. Eliminate connection storms, reduce database load, and scale your application layer independently.
# Session mode: 1:1 mapping
[pool]
mode = "session"
max_connections = 500
# Transaction mode: 10:1 multiplexing
[pool]
mode = "transaction"
max_connections = 1000
server_connections = 100
# Statement mode: 100:1 multiplexing
[pool]
mode = "statement"
max_connections = 5000
server_connections = 50Intelligent 3-tier distributed caching system that automatically promotes hot data and evicts cold entries. Reduce database load by up to 95% with sub-millisecond cache hits.
Automatic cache invalidation on writes. Configurable exclusion patterns for INSERT, UPDATE, and DELETE statements.
-- This query hits L1 cache (sub-ms)
SELECT * FROM users
WHERE id = 42;
-- Similar query hits L3 semantic cache
SELECT * FROM users
WHERE user_id = 42;
# Cache configuration
[cache]
enabled = true
[cache.l1]
size = "1GB"
ttl = "60s"
eviction = "lru"
[cache.l2]
type = "redis"
hosts = ["redis-1:6379", "redis-2:6379"]
ttl = "5m"
[cache.semantic]
enabled = true
similarity_threshold = 0.95Automatic GraphQL schema generation from your database tables. No code generation step, no manual schema definitions — HeliosProxy introspects your database and generates a full GraphQL API in real time.
# Auto-generated from SQL schema
query {
users(where: { active: true }, limit: 10) {
id
email
orders(orderBy: { createdAt: DESC }) {
id
total
items {
product_name
quantity
}
}
}
}
# Enable in config:
# [graphql]
# enabled = true
# endpoint = "/graphql"
# introspection = true
# max_depth = 10Extend HeliosProxy with custom WebAssembly plugins. Write your logic in Rust, Go, or any language that compiles to WASM, and inject it into the query pipeline at any hook point.
use wasm_bindgen::prelude::*;
// Custom query rewriting plugin
#[wasm_bindgen]
pub fn rewrite_query(
query: &str,
context: &Context
) -> String {
// Add tenant filter to all queries
if !query.contains("tenant_id") {
query.replace(
"WHERE",
&format!(
"WHERE tenant_id = {} AND",
context.tenant_id
)
)
} else {
query.to_string()
}
}
# Plugin configuration
# [plugins.wasm]
# name = "tenant-filter"
# path = "/plugins/tenant_filter.wasm"
# hook = "query_rewrite"HeliosProxy automatically classifies and routes queries to the optimal backend. Lag-aware read replicas, circuit breaker protection, and workload-based routing ensure every query hits the best target.
# Workload-based routing
[routing]
schema_aware = true
[routing.workload]
enabled = true
# OLTP queries -> primary
oltp_patterns = [
"SELECT * FROM users WHERE id",
"INSERT INTO orders"
]
oltp_target = "primary"
# OLAP queries -> analytics replica
olap_patterns = [
"SELECT.*GROUP BY",
"SELECT.*ORDER BY.*LIMIT"
]
olap_target = "analytics"
# Vector queries -> vector node
vector_patterns = [
"ORDER BY.*<=>",
"embedding.*<->"
]
vector_target = "vector-node"
# Circuit breaker
[circuit_breaker]
enabled = true
failure_threshold = 5
reset_timeout = "30s"
half_open_requests = 3HeliosProxy inspects and optimizes queries before they reach the database. Automatic rewriting improves performance without any application code changes.
# AI workload optimization
[ai_cache]
enabled = true
# Conversation context cache
conversation_context_ttl = "30m"
conversation_context_size = "512MB"
# RAG chunk cache
rag_chunk_cache_size = "2GB"
rag_chunk_ttl = "1h"
# Semantic query cache
semantic_cache_enabled = true
similarity_threshold = 0.95
# Query cache control
[cache.query]
enabled = true
max_result_size = "10MB"
exclude_patterns = [
"INSERT",
"UPDATE",
"DELETE"
]Centralized authentication before database access. Support for JWT, OAuth 2.0, LDAP, and API keys — all validated at the proxy layer before any query reaches the database.
[auth]
enabled = true
# JWT validation
[auth.jwt]
enabled = true
issuer = "https://auth.example.com"
audience = "heliosdb"
jwks_url = "https://auth.example.com/.well-known/jwks.json"
# Extract tenant from JWT claims
tenant_claim = "org_id"
role_claim = "db_role"
# API key validation
[auth.api_key]
enabled = true
header = "X-API-Key"
# LDAP integration
[auth.ldap]
enabled = true
server = "ldap://ldap.example.com:389"
base_dn = "dc=example,dc=com"Flexible tenant isolation strategies to match your architecture. From shared-database with Row-Level Security to dedicated databases per tenant — HeliosProxy handles routing, resource limits, and isolation transparently.
[tenancy]
enabled = true
tenant_header = "X-Tenant-ID"
default_tenant = "public"
# Enterprise tenant: dedicated DB
[[tenancy.tenant]]
id = "enterprise-1"
database = "enterprise_1"
pool_size = 100
cache_size = "2GB"
# Startup tenant: shared DB
[[tenancy.tenant]]
id = "startup-tier"
database = "shared"
pool_size = 10
cache_size = "256MB"
rate_limit_qps = 100Track and analyze every query pattern flowing through HeliosProxy. Identify slow queries, monitor cache efficiency, and understand your workload — all with built-in analytics.
-- Top 20 slowest queries
SELECT query_pattern,
avg_duration,
call_count
FROM heliosproxy_query_stats
ORDER BY avg_duration DESC
LIMIT 20;
-- Most frequent queries + cache hits
SELECT query_pattern,
call_count,
cache_hit_rate
FROM heliosproxy_query_stats
ORDER BY call_count DESC
LIMIT 20;
-- Overall cache efficiency
SELECT
SUM(cache_hits) AS hits,
SUM(cache_misses) AS misses,
ROUND(
SUM(cache_hits)::float /
(SUM(cache_hits) + SUM(cache_misses)),
3
) AS hit_rate
FROM heliosproxy_cache_stats;Protect your database from overload with granular rate limiting at every level. Global limits, per-tenant quotas, per-user throttling, and per-query cost limits — all enforced at the proxy layer.
[rate_limit]
enabled = true
# Global limits
global_qps = 10000
global_connections = 5000
# Enterprise customer
[[rate_limit.tenant]]
id = "enterprise-customer"
qps = 2000
connections = 500
# Free tier
[[rate_limit.tenant]]
id = "free-tier"
qps = 100
connections = 10
burst = 20
# Client-side handling
try:
cursor.execute("SELECT * FROM users")
except HeliosError as e:
if e.code == "RATE_LIMIT_EXCEEDED":
time.sleep(e.retry_after)Oracle-grade TAF+TAC merged functionality for PostgreSQL. HeliosProxy journals all statements within a transaction and automatically replays them on a new node after failover, with full result verification to guarantee consistency.
# Transaction Replay configuration
[transaction_replay]
enabled = true
verify_results = true
statement_timeout_ms = 30000
retry_on_error = true
max_retries = 3
wait_for_wal_sync = true
max_wal_lag_bytes = 0
[transaction_replay.journal]
max_entries = 10000
max_size = "64MB"
-- Transaction replayed after failover
BEGIN;
INSERT INTO orders (user_id, total)
VALUES (42, 99.99);
SAVEPOINT sp1;
UPDATE inventory SET qty = qty - 1
WHERE product_id = 7;
COMMIT;
-- checksum verified: OK
-- rows matched: OKSaves and restores cursor state after failover, allowing seamless resumption of result set iteration without losing position. Applications iterating through large result sets survive node failures transparently.
-- Declare a cursor over a large table
DECLARE user_cursor CURSOR FOR
SELECT * FROM users
ORDER BY created_at;
-- Fetch first 500 rows
FETCH 500 FROM user_cursor;
-- position: 500
-- Node fails! HeliosProxy restores:
-- 1. Re-declare cursor on new node
DECLARE user_cursor CURSOR FOR
SELECT * FROM users
ORDER BY created_at;
-- 2. Skip to saved position
MOVE 500 IN user_cursor;
-- 3. App continues seamlessly
FETCH 100 FROM user_cursor;
-- returns rows 501-600Preserves and restores complete session state during failover, including SET parameters, prepared statements, and optionally temporary tables. Applications maintain their full session context when transparently moved to a new node.
# Session State Migration
[session_migration]
enabled = true
max_sessions = 10000
migrate_temp_tables = false
# Tracked session parameters
# (automatically captured on SET)
# - timezone
# - search_path
# - client_encoding
# - datestyle
# - intervalstyle
# - application_name
# - any custom SET variables
# Example: after failover, proxy runs:
# SET timezone TO 'America/New_York'
# SET search_path TO myapp, public
# SET client_encoding TO 'UTF8'
# SET datestyle TO 'ISO, MDY'
# SET app.tenant_id TO '42'
# PREPARE my_query (integer)
# AS SELECT * FROM users
# WHERE id = $1Connect to any node — primary or standby — and HeliosProxy automatically routes write operations to the current primary. Applications never need to track topology changes, enabling true connect-anywhere simplicity with zero client-side routing logic.
# Transparent Write Routing
[transparent_write_routing]
enabled = true
sync_mode = "sync"
forward_timeout_ms = 5000
[transparent_write_routing.pool]
max_connections = 50
idle_timeout_ms = 60000
health_check_interval_ms = 5000
-- App connects to ANY node (standby)
-- Reads stay local, writes auto-route
SELECT * FROM orders
WHERE user_id = 42;
-- → executes on standby (local)
INSERT INTO orders (user_id, total)
VALUES (42, 149.99);
-- → auto-forwarded to primary
-- → sync: confirmed on standbyEach module is independently activated via a compile-time feature flag. Enable only what your deployment requires — no unused code ships in your binary.
Session, Transaction, Statement modes with up to 100:1 multiplexing and prepared statement forwarding.
Round-robin, least-connections, or latency-based distribution. Automatic read/write splitting.
Configurable health-check queries, failure thresholds, and automatic node removal/recovery.
PostgreSQL extended query protocol pipelining. Batches Parse, Bind, Execute to reduce round trips.
Auto-coalesces individual INSERTs into multi-row batches for higher write throughput.
Automatic failover with promotion policies. Prefers sync standbys, ranks by replication lag.
Oracle-grade TAF+TAC. Journals and replays in-flight transactions on the new primary after failover.
Preserves SET parameters, prepared statements, search paths, and advisory locks across failover.
Saves cursor state and position, recreates on new nodes. FETCH NEXT continues seamlessly.
Buffers incoming queries during failover and drains to the new primary. Increased latency, not errors.
Pluggable topology discovery: PostgreSQL polling, HeliosDB native events, or manual via Admin API.
Write-ahead journal for in-flight transactions with statement-level granularity and parameter capture.
Three-tier result cache: L1 hot (sub-μs), L2 warm (TTL-based), L3 semantic (normalized matching).
Embed routing directives in SQL comments: /*+ route=primary */, /*+ route=nearest */.
Routes reads to replicas within a configurable lag threshold. Includes read-your-writes consistency.
Rule-based SQL transformations: add hints, inject filters, redirect tables, enforce naming conventions.
Fingerprinting, slow query log, intent classification (OLTP/analytics/vector), N+1 detection.
Data temperature classification (hot/warm/cold), workload-type detection, automatic schema discovery.
JWT, OAuth 2.0, LDAP, API key validation, and external identity claim-to-role mapping.
Token bucket, sliding window, and concurrency limiting. Per-tenant, per-user, per-IP, per-query cost.
Adaptive failure detection with closed/open/half-open states and automatic recovery probes.
Tenant identification, pool isolation, schema routing, and per-tenant resource quotas.
Extend with sandboxed WebAssembly plugins. Hot-reloadable, memory-limited, controlled host API.
Auto-generated GraphQL API from schema with DataLoader batching and query validation.
HeliosProxy adds minimal latency while dramatically improving throughput, caching, and availability.
vs. 8.2K direct connection. 5x throughput improvement from connection pooling alone.
L1 hot cache serves frequently accessed results in sub-microsecond time.
vs. 12ms direct connection establishment. 40x faster via connection pooling.
Automatic failover with Transaction Replay. Clients experience a brief pause, not an error.
HeliosProxy operates at the wire protocol level. All features work transparently with any PostgreSQL-wire-compatible database.
| Backend | Compatibility | Notes |
|---|---|---|
| PostgreSQL 12+ | Full | Including Amazon RDS, Aurora, Cloud SQL, Azure Database |
| HeliosDB Lite/Full | Full | Native topology integration for instant failover |
| CockroachDB | Full | PostgreSQL wire protocol compatible |
| YugabyteDB | Full | PostgreSQL wire protocol compatible |
| TimescaleDB | Full | Runs as PostgreSQL extension |
| Citus | Full | Runs as PostgreSQL extension |
| AlloyDB | Full | Google Cloud PostgreSQL-compatible |
HeliosProxy isn’t just a connection pooler — it’s an AI-native database platform layer. Here’s how it compares to every alternative in the market.
| Capability | PgBouncer | pgpool-II | PgCat | Odyssey | AWS RDS Proxy | HeliosProxy |
|---|---|---|---|---|---|---|
| Connection Pooling | 3 modes | Yes | Yes | Yes | Yes | 3 modes + AI-aware |
| Multi-threaded | ✗ | ✓ | ✓ (Rust) | ✓ (C99) | N/A | ✓ (Rust) |
| Query Caching | ✗ | Basic | ✗ | ✗ | ✗ | 3-tier distributed |
| Load Balancing | ✗ | ✓ | ✓ | ✗ | ✓ | ✓ + schema-aware |
| Auto Failover | ✗ | ✓ | ✓ | ✗ | ✓ | ✓ + circuit breaker |
| Rate Limiting | ✗ | ✗ | ✗ | ✗ | ✗ | Per-tenant, per-query |
| Multi-Tenancy | ✗ | ✗ | ✗ | ✗ | ✗ | Full isolation (4 modes) |
| Auth Proxy | Basic | Basic | Basic | Basic | IAM only | JWT/OAuth/LDAP/SAML |
| Query Analytics | ✗ | ✗ | ✗ | ✗ | CloudWatch | P50/P90/P99 + cost attr. |
| GraphQL Gateway | ✗ | ✗ | ✗ | ✗ | ✗ | Auto-generated |
| WASM Plugins | ✗ | ✗ | ✗ | ✗ | ✗ | ✓ (sandboxed) |
| Branch-Aware | ✗ | ✗ | ✗ | ✗ | ✗ | Git-like branching |
| AI/RAG Caching | ✗ | ✗ | ✗ | ✗ | ✗ | Semantic + conversation |
| Query Rewriting | ✗ | ✗ | ✗ | ✗ | ✗ | Tenant injection + optimization |
| Transaction Replay | ✗ | ✗ | ✗ | ✗ | ✗ | Oracle-grade TAF+TAC |
| Cursor Restore | ✗ | ✗ | ✗ | ✗ | ✗ | State + position preserved |
| Session Migration | ✗ | ✗ | ✗ | ✗ | ✗ | SET, prepared stmts, temp tables |
| Write Routing | ✗ | ✗ | ✗ | ✗ | ✗ | TWR (any-node connect) |
| Sharding | ✗ | ✗ | ✓ | ✗ | ✗ | Schema-aware routing |
| Vendor Lock-in | None | None | None | None | AWS only | None |
3-tier distributed cache (L1 local <100μs, L2 Redis <5ms, L3 DB) with 85% hit rate in production. No competitor offers multi-tier caching.
10,000 concurrent tenant connections served by 100 database connections. 73% infrastructure cost reduction vs. PgBouncer’s 10:1 ratio.
Deploy anywhere — Docker, Kubernetes, bare metal. Unlike AWS RDS Proxy, HeliosProxy works with any PostgreSQL-compatible database.
Semantic query cache, RAG chunk caching, conversation context, and tool result cache. Purpose-built for AI/Agent database workloads.
WASM plugins, GraphQL gateway, branch-aware caching, AI workload optimization, transaction replay, cursor restore, session migration, write routing, semantic caching, per-tenant analytics, query routing hints, batch coalescing, switchover buffer, transaction journal.
Replaces PgBouncer + Redis + rate limiter + auth proxy + GraphQL server + analytics. One binary, one config file, one deployment.
HeliosProxy is open source and works with all three HeliosDB editions — Nano, Lite, and Full — plus any PostgreSQL-compatible database.