---
title: "HeliosDB Full v8.3.0 — Durable-by-Default WAL, Request-Path Hardening, and a Concurrency Jump"
description: "The WAL is now fsync-durable on acknowledgement, with real group commit so durable throughput scales with concurrency. Plus request-path panics eliminated, a startup-handshake timeout and connection cap, PRIMARY KEY uniqueness enforced across restarts, and ~17× read / ~36× write gains at eight clients on representative fixtures."
date: 2026-07-06
updated: 2026-07-06
tag: "Release"
canonical: https://www.heliosdb.com/blog/full-8-3-0-durable-wal-concurrency.html
---

# 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](https://github.com/HeliosDatabase/HeliosDB-Full/releases/tag/v8.3.0).