TigerBeetle Raises $6.4M to Power the Future of Financial Accounting Infrastructure

A textbook database problem

Tracking financial transactions, where Alice pays Bob, is a textbook database problem. It’s the classic example given by databases that guarantee strict serializability, the gold standard of data consistency.

You can’t double-count money. You can’t reorder transactions. And you can’t lose data.

Jepsen, a library for testing distributed databases, even has a bank test. It’s hard to get strict serializability right, even for non-financial data.

But financial data is intrinsically valuable, where each row represents value in the real world. Someone once said to me that tracking financial transactions terrifies them—“It’s close to nuclear!”.

And yet, which database provides double-entry financial accounting primitives out of the box?

If you’re a fintech startup, or a SaaS startup charging for API usage, or a game offering in-app purchases (let alone a bank!) and you believe that your database should enforce financial consistency, not only foreign key constraints, what do you do?

Do you use a proprietary ledger API for your core business data? Or do you reinvent double-entry accounting over a general-purpose database like Postgres?

The first option can be expensive. The second can be subtle and take longer than you expect, just when you want to get to market.

At least, this is what I saw when I did safety and performance analysis of the Mojaloop payments switch in 2020, together with Adrian Hope-Bailie and Donovan Changfoot, while consulting for Coil.

Reinventing double-entry accounting

Tracking money movements not only within a system, but also between partner systems with different tech stacks, can be 10k lines of complex code if you do it yourself.

It’s at the dangerous intersection of double-entry and distributed systems, and there’s a two-phase commit protocol coordinator in there somewhere, to make sure that money either moves or doesn’t move. For example, when timestamping transactions, even dealing with time is difficult.

At some point, you’re building a ledger database.

And when we looked around, everyone was doing this: reinventing the wheel. Ad hoc ledgers were everywhere. It was all Postgres and duct tape. Multiple round trips to the database to execute a single transfer of money between accounts. Race conditions. Painful migrations. No separation of concerns between user data and financial data. No automated failover across multiple data centers for high availability. Or worse, cloud database lock-in.

We also saw that high volume switches and large startups were starting to hit the wall at around 2k transactions per second, because of SQL row lock contention for hot accounts.

So we tried rubbing a database on it, to solve the problem once and for all, with a purpose-built database.

A new era for databases

We were lucky to begin in 2020, when several innovations began to reshape the distributed systems and database research landscape:

1. Jens Axboe had created io_uring, revolutionizing Linux I/O.

2. Safer systems languages were coming out, making it easier to write correct code, and bringing gamechangers like comptime.

3. UW-Madison’s research into storage faults had shown that existing database design had to change, for correctness and availability.

4. FoundationDB had pioneered the deterministic simulation testing of distributed systems, to find and replay rare bugs deterministically, for increased developer velocity.

All this meant that we could:

1. replace the context switches and syscalls of multithreaded I/O, not with custom I/O stacks like DPDK or SPDK, but with the kernel thread pool directly as our data plane (thanks Jens!),

2. reap the long term rewards of being early in Zig (realizing that our production roadmaps would coincide), e.g. control over memory allocation for tight bounds on latency, following NASA’s Power of Ten Rules for Safety-Critical Code,

3. take storage fault-tolerance to the theoretical limit, with a pioneering storage fault model, and

4. use a simulator to magically accelerate decades of manual testing.

We could stand on the shoulders of giants, to design TigerBeetle as a distributed financial accounting database for mission-critical safety and performance.

Looking back on this design phase, I remember the first prototype of TigerBeetle achieving 200k transactions a second, and the feeling that this would one day become a database company.

I gave up the startup I was working on, and joined Coil to work full time on TigerBeetle as Apache 2.0 open source. With Coil’s backing, TigerBeetle took shape.

The Mojaloop payments switch and Coil’s Interledger began designing for TigerBeetle. Then a digital wallet called Fynbos. And then energy and gaming startups were reaching out.

The world was becoming more transactional—money movements were becoming smaller and more frequent—and the demand for high performance accounting was growing.

Planting the seed

With an open source production release of TigerBeetle on the horizon, Coil decided to invest and spin out TigerBeetle as a startup, with sentientwaffle and kprotty from Coil joining me for the adventure, along with Phil Eaton, S.M Mukarram Nainar, Jamie Brandon, matklad, and Federico Lorenzi.

Concurrently, we met Lenny Pruss and Natalie Vais of Amplify Partners through Jamie’s HYTRADBOI database conference. There was something special about Amplify—Lenny and Natalie were as excited about database research as we were, and were early investors in our favorite database startups.

We are therefore thrilled to announce TigerBeetle’s Series Seed of $6.4 million led by Amplify Partners, with Coil as equal partners.

We are further incredibly grateful to our angels and advisors:

Ameet Patel, Amod Malviya, Derek Collison, James Cowling, Chris Riccomini, Dominik Tornow, Deepti Srivastava, Thomas McLeod, Desigan Chinniah, Loris Cro and Andrew Kelley.

Finally, to everyone who has been there for the journey, we look forward to Systems Distributed ‘23 from 9-10 Feb, to share our love of systems programming, and most of all, to meet you in person.

Until then, if this is your first time learning about TigerBeetle, I invite you to visit our repo, follow us for updates, and join our community.