TigerBeetle: a database built for financial transactions

Actualizado: 2026-05-03

TigerBeetle is one of those projects that, when you first encounter them, makes you wonder whether it’s a technical joke or a serious work. A database specialized only in two types of operations, written in Zig, with a rigid fixed-two-table schema, that claims to process millions of financial transactions per second on a five-machine cluster. After reading the design docs, the second reaction is deep respect for the technical seriousness.

Key takeaways

• TigerBeetle does only one thing: double-entry accounting. Two fixed tables, accounts and transfers, with no ability to create new tables, add columns, or do text search.
• Written in Zig deliberately: low-level memory control, zero dynamic dependencies, predictable behavior under pressure.
• Uses Viewstamped Replication on five-node clusters tolerating two-node failures, with synchronous ledger replication.
• Uses formal verification and deterministic simulation; Jepsen has been applied without serious findings since the first stable release.
• The typical architecture is TigerBeetle alongside a traditional database: Postgres stores users, products, and metadata; TigerBeetle stores the ledger.

What it is and what it isn’t

TigerBeetle is a very narrow-purpose database: double-entry accounting. Every transfer produces a debit in one account and a credit in another, and the total sum is always zero. That mathematical property is the basis of every serious financial system, and TigerBeetle models it directly in its schema.

The schema is deliberately simple: two fixed tables, accounts and transfers. You can’t create new tables, you can’t add columns, there’s no JSON or text search. The database does accounting or it does nothing.

That rigidity is the strength. A system that only has to do one thing can be brutally optimized for doing it well.

Design: what makes it different

The language is Zig, a deliberate choice. Low-level memory control, zero dynamic dependencies, predictable behavior under pressure, no complex runtime. TigerBeetle grew with Zig and its creators are regular contributors to the language.

The consensus protocol is Viewstamped Replication: TigerBeetle runs on five-node clusters tolerating two-node failures, with synchronous replication. Before answering the client, a transfer must be in at least three nodes’ ledgers.

The storage format is custom: an immutable on-disk ledger where each transfer is appended and never modified. Account balances are recomputed in memory from the ledger when needed. Formal verification is central: deterministic simulation tests the system under all possible failure sequences. A bug losing a cent in a million transfers is unacceptable, and TigerBeetle was designed with that awareness.

Where it fits

The clear use case is large-scale payment systems. Any platform processing account transfers, payment cards, interbank settlements, loyalty points or virtual wallets is a natural candidate. The rule: if the main application workload is counting money going from A to B, and the rate exceeds tens of thousands of operations per second, TigerBeetle deserves evaluation.

The typical architecture is TigerBeetle alongside a traditional database. Postgres stores users, products, metadata and search; TigerBeetle stores the ledger. This separation is explicit and recommended by the creators, who don’t intend TigerBeetle to replace a relational database.

Honest limits

TigerBeetle doesn’t do analytical queries. For analytics, export to a data warehouse as usual. It doesn’t do text, geography, JSON or any data outside the strict financial model.

Operations are relatively new. Observability and diagnostic tooling is maturing. The community is small compared to Postgres.

How to think the decision

No rush. If your volume is tens or hundreds of transfers per second, well-tuned Postgres is probably the right answer today and for a long time. If you start seeing hundreds of thousands per second or millions, or your business nature carries regulatory risk on ledger integrity, TigerBeetle offers a map point no other option occupies well.

It’s the kind of tool that when you need it, you really need it; and when you don’t, it’s complexity that doesn’t pay off.

Conclusion

That clarity about its niche is part of why the project inspires trust: its creators know exactly what they’re building and for whom, and don’t try to turn it into something else.