DB
Get started
Back homeIndustry

Payments & fintech

A ledger where every statement lands atomically and durably, balances that do not depend on arrival order, and the state at any past commit on demand.

The problem

Where the usual stack breaks

  1. 01

    A payments system has a strict correctness bar: every write has to land atomically and durably, balances have to be right, and history has to be reproducible to the 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.

  2. 02

    The drift is unacceptable here: a balance that depends on which copy answered is a balance that is wrong, and an audit trail that cannot reproduce the state at decision time is not an audit trail.

  3. 03

    You want an append-only ledger, balances ordered by declared coordinates so late and re-delivered postings converge, and point-in-time reads, in one engine rather than three that have to agree.

Where NYXDB fits

Use-case journeys

01

Transaction ledgers

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

HTAP & operational analytics
02

Fraud & transaction risk

Every threshold reads per-account totals that are current and events enriched at processing time.

Fraud & risk
03

Balances & live serving

Balances per account, followed live by every service that needs them.

Real-time dashboards

Architecture

How NYXDB fits payments & fintech

Postings land in a durable ledger, each statement its own atomic write, in the write-ahead log before acknowledgement; balances live in versioned tables where the engine settles which version wins; AS OF COMMIT rereads the winners at any commit sequence.

  1. 01

    Append the ledger

    A posting is acknowledged only after the write-ahead log’s group persistence barrier has passed.

  2. 02

    Atomic statements

    Each statement is its own atomic write; there are no multi-statement transactions.

  3. 03

    Ordered balances

    In-order, shuffled and late postings converge to the same current and retained state, with VALID BY and REVISION BY.

  4. 04

    Audit as of

    Reread the winners exactly as they stood at a commit, with AS OF COMMIT and the sequence from a write receipt.

In practice

Representative statements

Balances, as a versioned table with a slice per producer
CREATE TABLE balances (
  chain_id UINT16 NOT NULL,
  address STRING NOT NULL,
  token STRING NOT NULL,
  amount UINT256 NULL,
  updated_at DATETIME64(3, 'UTC') NULL,
  balance_index UINT128 NULL,
  balance_version UINT64 NULL,
  transfer_count UINT64 NULL,
  last_transfer_at DATETIME64(3, 'UTC') NULL,
  activity_index UINT128 NULL,
  PRIMARY KEY (chain_id, address, token),
  ATTRIBUTE GROUP holding (amount, updated_at, balance_index, balance_version)
    VALID BY (balance_index)
    REVISION BY (balance_version),
  ATTRIBUTE GROUP activity (transfer_count, last_transfer_at, activity_index)
    VALID BY (activity_index)
)
MODE VERSIONED
SHARD BY (address) SHARDS AUTO
ORDER BY (chain_id, address, token);
Balances exactly as they were at a commit
SELECT address, token, amount
FROM balances AS OF COMMIT 42
WHERE chain_id = 1;

The examples use the same two tables on every page. See the SQL reference for full syntax.

Capabilities

What you get out of the box

Append-only ledger

Durable, ordered records.

Atomic statements

Each statement is its own atomic, durable write.

Point-in-time reads

AS OF COMMIT reads the winners at a commit sequence.

Arrival-order independent

Late and re-delivered postings converge to the same balance.

Learn more

Go deeper

Versioned tables

VALID BY, REVISION BY and AS OF COMMIT.

Transactions

Statement atomicity.

Durability

Write-ahead log and acknowledgement.

A ledger you can audit

Explore HTAP & operational analytics or run a node.

Get startedRead the docs