What's Interesting About TigerBeetle?

Wed, 07 Jan 2026 09:53:00 +0000
Database, Clustering, Fintech, Replication, Tigerbeetle

TigerBeetle: a fixed-schema, performance-oriented, replicated, highly available financial database. This more or less sums up what the project is about. Still, TigerBeetle generates a seemingly disproportionate amount of attention. What's the fuss? What is interesting about TigerBeetle?

Let's take a closer look!

TigerBeetle from an SQL viewpoint

We'll start with a rather traditional perspective. Most of you probably have a solid background in SQL, and relational databases determine the way we assess other database systems (even if something is not a relational database, we say it's "NoSQL").

Unlike a relational database, TigerBeetle has a fixed schema, with only three "entity types": ledgers, accounts, and transfers. Each entity type has a fixed number of columns of fixed types. The schema can be visualised as an ERP diagram:

This schema supports a well-known accounting concept: double-entry bookkeeping. It has been around since the Middle Ages, and operates on a simple principle: every transfer always concerns two accounts, with one debit and one credit. That is, money (or whatever resource is tracked) never disappears, and never appears out of thin air.

If you haven't worked in the accounting domain, the terminology might not be that well-known. That's why TigerBeetle prepared a primer to get you up to speed with accounting 101. Which is interesting and educational in itself, even if you're not that interested in TigerBeetle itself.

What's OLTP?

TigerBeetle positions itself as an OLTP database (online transaction processing), which traditionally is the space occupied by SQL databases. OLTP is contrasted with OLAP (online analytical processing, e.g., ClickHouse).

However, TigerBeetle introduces further differentiation. First, there's OLGP (online general purpose), which is the category of PostgreSQL, MySQL etc.; while "true" OLTP, handling real-time transactions, is where TigerBeetle falls in.

Whether a database is OLGP or OLTP is also reflected in typical usage patterns. With OLGP databases, reads most often dominate writes. In OLTP, you'll most often create new transfers. Write-heavy workloads are what TigerBeetle is optimized for.

Consistency

When working with a SQL database, we have a range of isolation levels to choose from (repeatable read, snapshot isolation, etc.), which also means that we implicitly choose which "phenomena" we might encounter (such as phantom read, lost updates, etc.).

With TigerBeetle, the story is much simpler: you get strict serializability, and there are no other options. That is, transactions are always executed serially, one after another, where each transaction fully observes all effects of the previous ones.

Data operations: inserting & querying

When interacting with TigerBeetle, you don't use SQL or any dedicated query language, but an API. There are client libraries for the most popular programming ecosystems. You might also just use the bundled CLI client.

All data in TigerBeetle is immutable. Hence, the only thing you can do is inserting (and querying). There are no UPDATEs, DELETEs, or ALTER SCHEMAs, as the schema is fixed.

Inserting includes three features that are crucial for many of TigerBeetle's use cases.

First, you can require that the account balance...