HeliosDB Full v8.3.0 — Durable-by-Default WAL, Request-Path Hardening, and a Concurrency Jump
HeliosDB Full v8.3.0 is a durability and hardening release for the PostgreSQL request path. The headline is a default change — the write-ahead log is now fsync-durable on acknowledgement — alongside three classes of remotely-triggerable failure closed, two correctness fixes, and a substantially faster concurrent hot path.
Durable by default
Acknowledged writes are now persisted to disk before the client sees success: the same contract PostgreSQL makes with synchronous_commit = on. A dedicated writer implements real group commit — all writes queued concurrently are flushed with a single write and a single fdatasync — so durable throughput scales with client concurrency instead of collapsing under one fsync per write.
This is a behavior change worth planning for. Single-connection, autocommit write latency now includes the disk's fsync cost: roughly sub-millisecond on NVMe, higher on rotational storage. Three ways to keep the old latency profile:
- Batch writes inside a transaction.
- Run concurrent writers — group commit amortizes the fsync across them.
- Opt into fast mode, which acknowledges after write and flushes on a short interval:
HELIOSDB_SYNCHRONOUS_COMMIT=off # bounded crash-loss window (5 ms default)Even fast mode is strictly safer than the previous never-fsync behavior. The on-disk WAL is now an unpadded sequential record stream and recovery is a deterministic forward scan.
Request-path hardening
Three changes make a public PostgreSQL endpoint safer to expose:
- No request-path panics. Truncated wire-protocol messages and multi-byte SQL that previously tripped a byte-boundary edge case now return a clean error instead of dropping the connection.
- Startup handshake timeout. A client must finish the startup and authentication handshake within a configurable window (
HELIOSDB_STARTUP_TIMEOUT_SECS, default 30). Stalled pre-auth connections are dropped rather than pinning resources — a direct slowloris mitigation. Established connections are unaffected. - Connection cap. Total client connections across all protocols are bounded by
HELIOSDB_MAX_CONNECTIONS(default 10000); past the cap, new connections are refused instead of spawning unbounded work.
Correctness
Two data-integrity fixes: PRIMARY KEY uniqueness is now enforced against rows written in previous server sessions (duplicates could slip in after a restart), and an abnormal client disconnect now rolls back its open transaction cleanly instead of leaving invisible rows behind.
Faster under concurrency
The statement hot path stopped doing avoidable work: admin-command pattern matching is compiled once instead of per statement, and per-row logging moved off the default path. On representative fixtures at eight concurrent clients we measured roughly 17× concurrent-read and 36× concurrent-write throughput — reproduce on your own hardware and report variance.
Filtered scans over non-indexed columns also get a lighter decode path: the predicate evaluator only needs column values, so it reads them with a lightweight decoder rather than fully deserializing each row. On a 100k-row fixture that measured ~45% faster on selective filters and ~20% faster on broad filters that return many rows, with no behavior change.
Upgrading
v8.3.0 is a drop-in upgrade. The one thing to note is the durability default: if you were implicitly relying on the old never-fsync behavior for latency, pick one of the three mitigations above before you roll out.
Full release notes and source: HeliosDatabase/HeliosDB-Full v8.3.0.