Master of None: The State of Today’s Infrastructure

The most recent era of infrastructure has been characterized by the rise of generalized computing primitives. The x86 instruction set, Linux, the RDBMS, Kubernetes, and dozens of other technologies provided a set of foundational building blocks that enabled a Cambrian explosion of applications that then catalyzed the digital transformation of organizations and entire industries, not to mention our daily lives.

But as we sit here today, our always-on digital world stretches these building blocks to their breaking point. Demand for real-time, intelligent apps requires ever-higher throughput at ever-lower latency, all while we’re drowning in data that can’t be processed fast enough. As a result, our jack-of-all-trades infrastructure has become master of none.

Nowhere have these deficiencies been felt more acutely than in the database world. The first class of database was the workhorse RDBMS (e.g. Oracle, DB2, Postgres, MySQL) which could be used for a wide variety of applications. Broadly speaking, there was a single taxonomy to distinguish these databases as “transactional” (OLTP) or “analytical” (OLAP), based on an application's read vs. write throughput requirements. Then, as the Internet actuated exponential growth of both structured and unstructured data, we saw the specialization of databases based on data models (graph databases, key-value stores, document databases, time series…), which were designed to handle specific “shapes” of data.

Today, many databases remain tailored to the data model rather than the specific characteristics of their workload. It turns out there’s a lot of extra engineering required to make these generalized technologies work for your business. For example, companies must enforce financial consistency and accounting principles to handle payments, wrapping their core database with tens or hundreds of thousands of lines of business logic (see public examples from Square, Uber, and Airbnb). As a result, the efficiencies of scale are not efficiencies at all. 

What if you could bring core business logic (like accounting) from common workload patterns (like payments) closer to the database?

Eye of the Tiger(Beetle)

In early 2022, we caught wind of a new conference exploring some of the most bleeding-edge ideas in databases and systems. There was one talk in particular that stood out. Joran Dirk Greef, a software engineer at Coil, described a new database his team was building called TigerBeetle to support their high-volume payments system after traditional databases hit the wall. 

Talking more with Joran, we learned that he was already thinking about applications for TigerBeetle outside of Coil. Payments are becoming global and increasingly more integrated into the fabric of the Internet, but the infrastructure required to support today’s payment volumes is prohibitively expensive. 

The core insight of TigerBeetle is that if we constrain the application domain and bring the primitives of financial accounting closer to the database, we can not only enforce financial consistency in the database, but also optimize performance, fault tolerance, and scale to a crazy degree. As such, TigerBeetle is able to reach extremely high transaction throughput (designed for up to 1M transactions per second). This high performance allows customers to trade expensive hardware for cheaper commodity hardware (e.g. a cluster of three Raspberry Pis) while still having headroom to handle volume spikes safely (e.g. Black Friday). Imagine the possibilities for a large payments provider that can increase its throughput 100-1000x overnight — we’d be on our way to continuous accounting. 

Besides constraining the domain model, TigerBeetle made some other head-turning design decisions:

• Domain-aware: Where traditional SQL databases may execute 10-20 DB queries to process 1 financial transaction, TigerBeetle's query and consensus layers were designed from the ground up to invert this equation, to process on the order of 10K financial transactions in 1 DB query, since debits and credits are small.
• Written in Zig: TigerBeetle takes advantage of Zig's explicit control over memory layout, alignment and allocations, OOM safety, bounds checking, rich choice of allocators (and test allocators), checked arithmetic, C ABI interoperability, support for io_uring, and comptime, which is a systems game changer.
• Static allocation: In a move back to the 70s, TigerBeetle not only allocates all memory at startup (with no dynamic allocation thereafter) but goes beyond this to limit disk and network usage, even for() loop iterations, to achieve optimal performance and predictable latency, following NASA's Power of Ten Rules for Safety-Critical Code.
• Fault-tolerant and distributed: TigerBeetle guarantees strict serializability, provides automated leader election, and implements new research on storage faults (see “Protocol-Aware Recovery for Consensus-Based Storage”) to achieve distributed transactions that can survive even the toughest storage fault models.
• Deterministic simulation testing: TigerBeetle built its own deterministic simulation framework to test every new feature under a myriad of possible faults — in other words, any forced “bad” state can be reproduced over and over again (something pioneered by FoundationDB). This makes TigerBeetle extremely stable and empowers developers to release new features more rapidly. “The future of databases is deterministic”.

All of this allows TigerBeetle to achieve break-neck performance while delivering mission-critical safety. 

We talked to dozens of top database researchers, practitioners, and founders, and the technical feedback was some of the best we’ve ever heard on a new systems project. The more we dug in, the more we learned that TigerBeetle is far more than the sum of its parts with respect to technical design decisions. 

Although TigerBeetle gets more credit for being an “accounting database,” the use cases extend far beyond financial applications. It turns out the fundamentals of double-entry accounting (i.e. debits and credits) apply to any business that deals with transactions (gaming, managing an energy grid, usage-based pricing, etc.). TigerBeetle at its core is a state machine — a distributed ledger where transactions represent a set of instructions to be executed and a trusted place to keep track of a global state. TigerBeetle has a two-tier architecture that separates the 1) application level from the 2) platform level. Business logic for “accounts” is stored at the application level which could hypothetically be swapped for new application models in the future. The platform level handles the consensus algorithm and fault tolerance of the system. 

The net result is that if you have any transactional business application that requires massive throughput while demanding utmost correctness and safety, odds are that TigerBeetle will soon be the database for you.

So today, we are thrilled to announce our investment in TigerBeetle. We believe TigerBeetle is building a foundational system to power the future of financial infrastructure for businesses all over the world and we couldn’t be more excited to be part of their journey.

Welcome to the Amplify family!