What is TulaDB?

TulaDB lets you build payment, settlement and liquidity systems without building the ledger underneath. It is a dedicated financial-state engine: it keeps balances, holds, commits, rollbacks, rejected attempts, duplicate retries, and financial history inside one explicit ledger contract — instead of spreading that behaviour across application tables, queue workers, and reconciliation jobs.

Its primary use is as a real-time posting ledger in front of a batch core: institutions joining an instant-payment rail post every payment into one balance per account, across every rail, with limits enforced on each payment. The same engine serves payment systems, wallets, treasury, settlement and marketplace balances. Wherever it sits, it owns the part your platform cannot afford to improvise: balanced, durable, idempotent financial state. Every problem it solves, with its status and proof, is listed outside the docs.

The contract

General-purpose databases work for ledgers, but you end up fighting their defaults — relaxing isolation for speed, or bolting lifecycle state onto rows. A double-entry financial ledger has a narrower contract, and TulaDB is shaped directly around it:

Guarantee	What it means
Atomic double-entry	Every transfer debits one account and credits another in a single atomic step. No partial state, ever.
Idempotent retries	A retried operation never double-posts. Duplicate detection is durable — it survives restart.
Explicit reservation lifecycle	Reserve, commit, and rollback are first-class operations. Holds cannot silently leak.
Fail-closed reads	Queries never return uncommitted or in-flight state.
Durable before acknowledged	Writes are acknowledged only after write-ahead-log durability is confirmed — the default posture; on a single node, the opt-in asynchronous-ack mode is for benchmarking only; in a cluster an acknowledgement always waits for fsynced copies on a majority of voters.
Rejected outcomes are records	A declined transfer is a durable, queryable record — not a dropped error.

The product surface

TulaDB ships as an engine plus the pieces you need around it:

• The engine — a single native binary that speaks a binary TCP protocol. Every write is a batch (a single operation is a batch of one), so there is one write path. Writes go to one port, queries to a dedicated read-only port that never blocks the write path.
• Replication — Raft-style consensus across a cluster of engine nodes, with follower proxying and quorum-gated durability. See Replication and consistency.
• SDKs — client libraries for Python, Java, Go, Rust, and C, a REST gateway for everything else, and tulactl, a command-line client for scripting and inspection. See SDKs & tools.
• Dashboard and observability — an operator console with server-enforced viewer, operator and admin roles and an audit log of every change, plus Prometheus metrics and six Grafana dashboards (an alert rule set is available to design partners). See Observability.
• Analytics export — an exporter that lands committed ledger history in Apache Iceberg tables, keeping analytical queries off the write path. Tested on AWS S3 Tables and Google BigLake over GCS, and queryable straight from the dashboard. See Analytics export and Lake query.

What stays above the ledger

TulaDB deliberately does not try to be your payment platform. Fraud scoring, routing, customer orchestration, compliance workflows, ISO 20022 message parsing, and network adapters stay in your services, where they belong. The ledger receives validated financial intent and returns durable outcomes.

This boundary is what keeps the core small, deterministic, and reviewable — and what makes the guarantees above possible to state precisely.

Where to go next

1. Getting started — three ways to run 0.0.1-preview: on your laptop with Docker or Podman, one node natively, or a full cluster.
2. Quickstart — a running ledger and your first transfer in a few minutes.
3. Core concepts — accounts, transfers, holds, and operation identity.
4. Architecture overview — how a TulaDB deployment fits into a payments stack.

Preview status. These docs describe 0.0.1-preview, TulaDB’s first release: a developer preview, suitable for evaluation, benchmarking, integration testing, and architecture review, and not certified for production financial workloads. It is pre-1.0 — the wire protocol, on-disk format, and config schema can still change between releases, and data directories from earlier development builds are not an upgrade source. The SDKs ship as a preview distribution rather than through public package registries. Pilots run on replayed or anonymised copies of your own traffic, in a non-production environment, under the evaluation licence. Production use requires deployment-specific security review, operational drills, and workload validation; see Path to production and Limits and sizing.