DB
Back homeIndustry

Payments & fintech

Transaction ledgers with atomic per-write ingestion, exact balances and counts, and point-in-time audit — append, MVCC snapshot reads, and AS OF on one engine.

The problem

Why this is hard today

A payments system has the strictest correctness bar in software and a low latency budget on top of it: every write must land atomically, balances must be exact, and history must be auditable to the exact state a decision saw. Bolting a ledger onto a general-purpose stack means reconciling an OLTP store, an analytics warehouse, and an audit log that can drift from each other.

The drift is unacceptable here: a balance that is approximate is a balance that is wrong, and an audit trail that cannot reproduce the exact state at decision time is not an audit trail.

What payments needs is an append-only ledger with atomic per-write ingestion under MVCC snapshot isolation, exact counts and balances, and point-in-time reads that reconstruct history precisely — in one engine, not three that must agree.

Where NYXDB fits

Use-case journeys

Transaction ledgers

Append-only, atomic, durable — with analytics on the same ledger, no ETL.

HTAP & operational analytics

Fraud & transaction risk

Read-your-writes state and exact counts behind every risk threshold.

Fraud & risk

Balances & real-time serving

Exact per-account balances served from memory, read-your-writes.

Caching & real-time serving

Architecture

How NYXDB fits payments & fintech

Payments append to a durable ledger; each write commits atomically under MVCC snapshot isolation (READ COMMITTED default, ADR-017); keyed balances stay exact and read-your-writes; AS OF reconstructs the exact state at any point for audit.

  1. 01

    Append the ledger

    Payments append to a WAL-backed table, durable at the group-commit watermark before ack.

  2. 02

    Atomic writes

    Each write or batch commits atomically via its Raft entry under MVCC (WAL-sequence version clock) — no partial state (ADR-017).

  3. 03

    Exact balances

    Keyed current-state tables hold per-account balances, exact and read-your-writes.

  4. 04

    Audit as-of

    FOR SYSTEM_TIME AS OF reconstructs the exact state a decision saw.

Real SQL

Representative query

Point-in-time balance audit
-- AS OF takes a literal revision (integer), not a timestamp
SELECT account_id, balance
FROM account_balances
FOR SYSTEM_TIME AS OF 1000;

Every statement follows the engine’s own test SQL shapes. See the SQL reference for full syntax.

Capabilities

What you get

Append-only ledger

Durable, ordered records.

Atomic & exact

Atomic per-write commits under MVCC snapshot isolation; exact balances and counts (ADR-017).

Point-in-time audit

AS OF <revision> reconstructs decision-time state.

Read-your-writes

Balances reflect the write that just committed.

Proof

Measured on the vetted benchmark lane

2.66M rows/s

durable ledger ingest, single core

1M-row batches (~232B, 16-col)

group-fsync default

View benchmark230 ns

exact balance/count, O(1)

flat 1k–16k keys

vetted table

View benchmark
read-your-writes

balances reflect the last commit

MVCC (ADR-017)

engine

Measured on Apple M4 Max (dev), macOS — server-class validation pending. Release build, median of 5, commit-pinned (d4a3885b, 2026-07-07). Ingest figures are engine-side. See the full benchmark suite.

Learn more

Related documentation

Keyed tables

Exact per-account balances.

SELECT … AS OF

Point-in-time audit reads.

Getting started

Run a node in minutes.

A ledger that is exact and auditable

Explore HTAP & operational analytics or run a node.

Get started Read the docs