cloudparts

TigerBeetle

A replicated database with one fixed schema, double-entry accounts and transfers, built in Zig to record money movements at high rates with strict serializability.

What it is
NoSQL databases
Type
Open source
Made by
TigerBeetle, Inc.
License
Apache 2.0
Facts checked
24 October 2026
Website Source code

What it is

TigerBeetle doesn’t store arbitrary tables. It has two kinds of record: accounts, grouped into ledgers such as a currency, and transfers, each of which debits one account and credits another on the same ledger by an amount. Accounts keep running totals of posted and pending debits and credits, from which the application computes balances, and can be told never to let debits exceed credits. Both records are immutable once created, fixed at 128 bytes, and carry a code for the reason and three indexed user_data fields for the application’s own IDs. Transfers can be linked so a group succeeds or fails together, as in a currency exchange, and two-phase transfers reserve an amount as pending first, then post all or part of it, void it, or let it time out.

It is built for the write-heavy, contended side of transaction processing, where a few accounts, such as a bank’s settlement account, take part in most transfers and row locks in a general-purpose database queue up. Requests always arrive in batches of up to 8,190 events, which a single leader applies one after another on one core, with no locks; the cost of replication is paid once per batch. Memory is allocated once at startup, I/O goes through Linux io_uring, and data lives in a forest of LSM trees. The vendor’s guidance is to keep a general-purpose database such as PostgreSQL for the slower-changing data, and put the money movements in TigerBeetle.

A cluster replicates with Viewstamped Replication and can be spread across three clouds, two replicas in each, so it survives losing a whole provider. Every piece of data is checksummed and hash-chained, so a replica detects a corrupted sector and repairs it from the others. The code is tested by the VOPR, a deterministic simulator that runs the real cluster under network, disk and process faults. A Jepsen analysis in 2025 found it met its strict serializability claim from 0.16.26 onward, after fixes to several crashes and two safety bugs.

Why teams pick it

  • Debits and credits are the database’s own primitives, so balances can’t drift and every change is an immutable transfer
  • High throughput on hot accounts: batches of up to 8,190 transfers applied without row locks
  • Strict serializability with automatic failover, checked by Jepsen and by continuous simulation testing
  • Built to survive disk corruption and the loss of a whole cloud provider

Watch out for

  • Only accounts and transfers: everything else, such as customer details, needs a second database
  • Records are immutable, so corrections are new transfers, and changing a ledger’s scale means creating a new ledger
  • Throughput comes from one leader on one core; more replicas add safety, not speed
  • Requests are retried forever by default, which Jepsen flagged as making errors hard to tell apart from slowness

Good for

Specs

Compare with alternatives →
Data model
Fixed schema: accounts and transfers, 128 bytes each, immutable
Secondary indexes
Three indexed user_data fields per record
Transactions
Batches of up to 8,190 events; linked events succeed or fail together
Consistency
Strict serializable
How it scales
One leader on one core; more replicas add safety, not speed
Replication
Viewstamped Replication with automatic failover
Multi-region
Can span three clouds with two replicas in each
Storage engine
A forest of LSM trees, checksummed and hash-chained
Written in
Zig

Alternatives

What all nosql databases have in common →Compare side by side →
PostgreSQLOpen sourceAlso good for serializable transactions across keysThe open-source relational database that most new projects start on, extensible enough to grow into many niches.+2 Citus, OmnigresFoundationDBOpen sourceAlso good for serializable transactions across keysAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.CockroachDBCommercialAlso good for serializable transactions across keysA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.RealmDeprecatedOpen sourceAn embedded object database for mobile apps, a replacement for SQLite and Core Data, whose cloud sync service MongoDB shut down in 2025.

How it fits with other technologies

The TigerBeetle REPL: two accounts on ledger 700 and a transfer between them · text

create_accounts id=1 code=10 ledger=700, id=2 code=10 ledger=700;
create_transfers id=1 debit_account_id=1 credit_account_id=2 amount=10 ledger=700 code=10;
lookup_accounts id=1, id=2;
# account 1: debits_posted=10   account 2: credits_posted=10

See it in a real stack

No architecture uses TigerBeetle yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2026

In 2020 Joran Dirk Greef, consulting for Coil, studied the safety and performance of Mojaloop, an open-source payments switch, with Adrian Hope-Bailie and Donovan Changfoot. They found many ad hoc ledgers built on general-purpose databases that topped out around 2,000 transactions a second. TigerBeetle began in July 2020 as a drop-in open-source database to power such a switch; Coil released it under Apache 2.0, and the first prototype reached about 200,000 transactions a second.

The team wrote it in Zig, then a young language, for control over memory allocation and tight latency bounds, and built it around Viewstamped Replication and deterministic simulation testing from the start. Coil spun TigerBeetle out as a company, which raised a $6.4 million seed round led by Amplify Partners in January 2023.

Jepsen tested versions 0.16.11 to 0.16.30 in 2025 and found it met its strict serializability claim once its bugs were fixed. In March 2026 the team reported processing a trillion transactions in a test cluster that kept its lower LSM levels in object storage.

Why it’s built this way

Debit-credit as the schema
Double-entry bookkeeping is centuries old and fits every money movement. Making it the only data model lets the database enforce balance rules and pack each transfer into 128 bytes.
Batches on one core instead of row locks
Payment workloads hammer a few hot accounts, where locking serialises everything anyway. Applying large batches in order on one thread removes lock contention and pays for replication once per batch.
Viewstamped Replication
Greef argues VSR, published before Paxos and revised before Raft, elects the next primary in a fixed round-robin order and copes better than Raft when the most up-to-date replica has a faulty disk.
Static allocation and deterministic simulation
Allocating all memory at startup rules out out-of-memory errors and fragmentation, and a deterministic codebase can be replayed exactly in the VOPR simulator, which injects faults at many times real speed.

Timeline

  1. 2020

    TigerBeetle starts in July at Coil, for the Mojaloop payments switch

  2. 2023

    Spun out of Coil; $6.4 million seed led by Amplify Partners

  3. 2025

    Jepsen analysis of 0.16.11 to 0.16.30

  4. 2026

    A trillion transactions processed in a scale test

Sources8 · facts checked 24 October 2026

Improve this page on GitHub