Not to mention the smallest and toughest. An incredible storage fault model. TigerBeetle is the system of record for the next generation of financial services.
Most distributed databases have network fault models, but TigerBeetle survives even the toughest of storage fault models. Firmware that sends writes to the wrong disk sector. Kernel page caches that misrepresent the disk. Filesystems that fail to detect the corruption of critical file metadata such as the log file size. Not to mention slowly failing hardware. TigerBeetle keeps on running with predictable performance.
Strict serializability
Automated leader election
Protocol-aware recovery from corruption and grey failure latency spikes
No stale reads
Faster than a generic in-memory database but with replicated persistence for every transaction, zero deserialization with cache line aligned data structures, zero copy with Direct I/O, zero syscalls with io_uring, and static allocation of memory (and storage). More performance reduces cost and leaves a large margin of safety to absorb the unexpected. TigerBeetle is ludicrously fast with a small footprint to boot. Why big iron when you can beetle?
faster than ad hoc balance tracking
more efficient than a one-phase ledger
more write availability in the critical path
smaller clusters with flexible quorums
TigerBeetle’s accounting primitives propel distributed balance tracking into the age of high-volume digital payments. In the past, developers had to glue everything together with multiple queries, moving the data back and forth across the network to run the business logic. TigerBeetle inverts the equation and moves the code to the data, to enforce the accounting policy needed to transfer thousands of amounts between accounts, all in a single query.
Model your financial domain as it is: double-entry T-accounts
Design your chart of accounts for the perfect schema
Never do a SQL schema migration again
TigerBeetle does double-entry accounting like Newton’s Third Law. For every transfer to an account, there is an equal and opposite transfer from a different account.
Multiple transfers between multiple accounts may be linked together to succeed or fail as an atomic unit.
Accounts may enforce net balance limits, such as debits may not exceed credits, or credits may not exceed debits.
Accounts and transfers may specify a chart of accounts code so you can query for accounts or transfers of a given type.
Accounts and transfers stay connected to third-party entities (many-to-one) through a 128-bit user data identifier.
A cluster may contain accounts denominated in different currencies or units of value, with transfers only ever between accounts of the same unit.
Out of the box. Reserve transfer debits and credits in the first phase, and accept or reject these amounts in the second phase, with monotonic clock timeouts. The perfect atomic primitive for reliable transfers across different systems.
TigerBeetle can distinguish between inflight reserved amounts and committed accepted amounts to control inflight liquidity.
TigerBeetle follows the state of
the art in financial exchange architectures
advanced by Martin Thompson and LMAX, a lockless thread-per-core
design with mechanical sympathy that models the system of record as
a replicated state machine for fault-tolerance.
TigerBeetle
incorporates
groundbreaking research on storage faults
led by Remzi and Andrea Arpaci-Dusseau at the University of
Wisconsin-Madison.
At the heart of TigerBeetle is
the pioneering Viewstamped Replication consensus protocol
developed by Brian M. Oki with Turing Award-winner Barbara Liskov
and later James Cowling at MIT for low-latency leader election and
optimal strict serializability.
Finally, TigerBeetle is
written in Zig,
a revolutionary systems language
designed by Andrew Kelley.
TigerBeetle is open-source under the Apache-2.0 License and is currently in beta, while we engage in automated testing and audits of our consensus and replication protocol, storage, networking and state machine. The production release of TigerBeetle is planned for 2023.
