TigerBeetle: a database built for financial transactions
Updated: 2026-07-07
TigerBeetle is one of those projects that, when you first encounter it, makes you wonder whether it’s a technical joke or a serious piece of work: a database specialized in only two kinds of operations, written in Zig, with a rigid two-fixed-table schema, that claims to process millions of financial transactions per second on a small cluster. The first reaction is disbelief. The second, after reading the design docs and the creators’ own posts, is deep respect for the technical seriousness. TigerBeetle is not for every problem, but for its own it is a notable example of focused design.
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 with flexible quorums; official docs recommend six replicas across three cloud providers for production.
-
Uses formal verification and deterministic simulation; an independent 2025 Jepsen audit found minor availability bugs but no serious flaw in the ledger’s strict-serializability guarantee.
-
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 database of a very specific purpose: double-entry accounting, the technique accountants have used since the fifteenth century to record every economic movement as an entry with two legs that always balance. 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, one for accounts and one for transfers. Accounts have an identifier, a debit balance, a credit balance, a currency code and a ledger. Transfers have an identifier, a debit account, a credit account, an amount and a set of flags. That is all. 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. TigerBeetle batches transfers, validates them in memory, keeps an immutable ledger, replicates state through a consensus protocol, and does all of it at speeds general-purpose systems simply do not reach.
Why it was created
TigerBeetle began as an internal project at Coil, a web-payments startup where its creator, Joran Dirk Greef, was building payment infrastructure and had previously consulted on a central bank’s payment switch. From that vantage point he saw up close that transactional accounting is a peculiar workload: very high write rate, conceptually simple operations with strict rules, zero tolerance for data loss, demanding latency requirements. And yet the industry kept running Postgres or Oracle configured with heavy workarounds. According to Amplify Partners[1], recording a single debit/credit movement on a general-purpose SQL system takes 10 to 20 queries (reading balances, locking rows, waiting on application logic, writing back), while countries like India and Brazil already process billions of transactions a month.
The thesis was that building a database from scratch for that specific workload, taking every shortcut the narrow purpose allows, could beat a well-tuned general-purpose database by orders of magnitude. TigerBeetle does not compete with Postgres on feature parity; it competes with Postgres when the workload is exactly the one TigerBeetle models, and there it wins by a wide margin.
The code has been public on GitHub[2] since 2020. The project later spun out of Coil as its own company, closing a $6.4 million seed round in early 2023 and a $24 million Series A led by Spark Capital in 2024, according to TechCrunch[3]. It is still on 0.x versioning, has not yet declared a 1.0, and ships frequent releases with a growing user base among payments and fintech companies.
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 has grown alongside Zig to the point of investing in the language itself: in October 2025, together with Synadia, it pledged $512,000 to the Zig Software Foundation[4].
The consensus protocol is Viewstamped Replication, a variant little known outside academic circles but elegant and proven, using flexible quorums designed by Heidi Howard. The classic fault-tolerance arithmetic requires 2f+1 replicas to tolerate f simultaneous failures: tolerating two failures needs a minimum of five nodes. For production, the official docs[5] go further and recommend six replicas spread across three different cloud providers, two per provider, to survive even the complete outage of one of them. Before answering the client, every transfer must be recorded on a majority of the cluster’s replicas. It’s the same replication discipline that contrasts with Postgres 16’s logical replication, built for a different problem: syncing whole relational databases, not a financial ledger.
The storage format is custom: an immutable on-disk ledger where each transfer is appended and never modified; the data is, per the documentation itself, checksummed and hash-chained. Account balances are recomputed in memory from the ledger when needed. That gives it strong properties: near-perfect auditability, simple replication, natural resistance to corruption because nothing is ever overwritten.
Formal verification is central to the project: TigerBeetle uses deterministic simulation to test the system under failure sequences generated by its own fuzzer, the VOPR. In 2025 it also commissioned an independent audit from Jepsen[6], which tested versions 0.16.11 through 0.16.30. The report found a couple of minor bugs, such as incomplete results on queries with multiple predicates, plus several client and server crashes in upgrade edge cases, but concluded that the database met its promise of strict serializability and that most findings were crashes or performance loss rather than safety errors in the ledger; TigerBeetle fixed nearly all of them in later releases, according to its own writeup of the process[7]. That matters in accounting: a bug that loses one cent in a million transfers is unacceptable, and that is exactly the kind of failure neither the internal fuzzer nor Jepsen managed to trigger.
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 moving from A to B, and the rate exceeds tens of thousands of operations per second, TigerBeetle deserves evaluation.
It also fits adjacent worlds: gaming platforms with internal economies, marketplaces with complex commission splits, cloud-scale billing systems. A verifiable example is Rafiki[8], Interledger Foundation’s reference implementation for Open Payments, which uses TigerBeetle as its accounting engine and leaves Postgres for authentication and application resources.
The typical architecture is TigerBeetle alongside a traditional database. Postgres stores users, products, metadata and search; TigerBeetle stores the ledger. Applications query both depending on the need: descriptive data in Postgres, balances and transfers in TigerBeetle. This separation is explicit and recommended by the creators, who don’t intend TigerBeetle to replace a relational database. The same logic of using the right tool for each workload applies to what we covered in Citus for scaling Postgres: every problem calls for the tool designed for it.
Honest limits
TigerBeetle doesn’t do analytical queries. If you want to know how much a user spent in January by category, that is not the question TigerBeetle answers. For analytics, export to a data warehouse as usual. It also doesn’t handle text, geography, JSON, or any data type outside the strict financial model; the abstraction is closed on purpose.
Operations are relatively new. Observability and diagnostic tooling is still maturing. The community is small compared to Postgres. An odd problem on a Sunday night has less community backup than the same problem on a classic system. Jepsen’s own report flagged a debatable design choice: the client retries indefinitely instead of surfacing an explicit error to the application, which complicates failure handling in the code that consumes it.
How to think about the decision
TigerBeetle deserves serious consideration if you are building something where accounting is the heart of the business and volume is growing fast. The cost of adopting it is real: another database to operate, another mental model to learn, an explicit split between financial data and everything else.
There is no need to rush. If your volume is tens or hundreds of transfers per second, a well-tuned Postgres is probably the right answer today and will remain so for a long time. If you start seeing hundreds of thousands per second or millions, or your business carries regulatory risk on ledger integrity, TigerBeetle offers a point on the map that 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 are building and for whom, and they don’t try to turn it into something else.
Spanish version: TigerBeetle: una base de datos pensada para transacciones financieras.
