TigerBeetle for CTOs: When a Ledger Database Beats Postgres, and When It Won’t

TigerBeetle for CTOs: tigerbeetle adoption, architecture, and trade-offs

TigerBeetle hit a production release in March 2024, raised a $24M Series A on May 30, 2024, and reported production customers doing 100M transactions per month by Jan 1, 2025. The company also claims a trillion transactions processed in testing by March 19, 2026. Those numbers matter because they point to a new default for “counting things of value” at scale, not a niche fintech toy.

TigerBeetle gives CTOs a different answer to a familiar question: do we keep stretching Postgres, or do we put a ledger in the hot path and stop re-building accounting rules in app code?

What is TigerBeetle (and what problem does it solve)?

TigerBeetle is an OLTP database built for double-entry accounting. It stores accounts and transfers and treats debit and credit as first-class primitives. It’s not trying to be Postgres or MySQL.

Jepsen describes it as an OLTP database “built for double-entry accounting” with a focus on safety and speed, using Viewstamped Replication and strong serializable consistency. Jepsen also calls out a constraint that will shape your application design: each request is a single transaction, and there are no interactive multi-request transactions. That’s not a missing feature. It’s the design. See the Jepsen analysis for details: Jepsen: TigerBeetle 0.16.11.

TigerBeetle’s docs frame the system as a split-brain architecture. You keep a general-purpose database for metadata and slower-moving state, and you put TigerBeetle in the hot path for transfers. They call the general-purpose database “OLGP” and TigerBeetle “OLTP” in this model. See: TigerBeetle in Your System Architecture.

Core components and capabilities:

• Accounts and transfers only. You model value movement, not arbitrary tables. Jepsen notes users pair it with other databases for other data types. Jepsen: TigerBeetle 0.16.11
• Strong serializable consistency. It builds on Viewstamped Replication for consensus. Jepsen: TigerBeetle 0.16.11
• Batching as a first-class idea. Amplify claims 8,190 debit credits can pack into a 1 MiB query in one round trip. Amplify Partners on TigerBeetle
• Simple deployment shape. It ships as a single statically linked binary with no external dependencies. Deploying TigerBeetle
• Multi-cloud guidance. The docs recommend six replicas across three cloud providers for high availability. TigerBeetle single page docs

Framing statement: TigerBeetle is a ledger engine you put in the hot path so your product stops re-implementing accounting rules in application code.

How TigerBeetle works in a real system architecture

Most CTOs I talk to have the same pain: the “ledger” lives in a pile of tables, triggers, and service code. Then a new product line shows up, and the team adds more columns, more locks, and more retries. It keeps working, until it doesn’t. Audit risk climbs. Incident risk climbs. People start being afraid to touch it.

TigerBeetle pushes you toward a cleaner split.

The OLTP and OLGP split: hot path vs control plane

TigerBeetle’s docs describe a division of responsibilities. Your API service handles auth, ID generation, and batching. Your general-purpose database stores names, mappings, and metadata. TigerBeetle stores the accounts and transfers. See the full breakdown: TigerBeetle in Your System Architecture.

The TigerBeetle repo goes deeper and names the principle: control plane vs data plane separation, tied directly to batching. The control plane work stays O(1). The data plane work stays O(N). It also spells out the target workload: contended workloads that shard poorly, mostly writes, high throughput, moderately low latency, strong consistency, and high durability. TigerBeetle ARCHITECTURE.md

That maps cleanly to a lot of “money-like” systems:

• Usage-based billing with spend caps
• Wallets and stored value
• Inventory reservations
• Ticketing and seat holds
• Utility metering

TechCrunch lists many of these use cases and quotes TigerBeetle’s CEO on “count anything of value” moving between accounts. TechCrunch on TigerBeetle.

A concrete scenario: usage based billing with real time caps

Say you run a B2B API business. You bill per request and you offer a hard monthly cap. You also need real-time enforcement.

A common Postgres design uses:

• A usage_events table
• A monthly_rollups table
• A background job to aggregate
• A cache to enforce caps

It works until a customer spikes traffic, the job lags, and you overshoot the cap. Then finance asks for an audit trail and engineering starts sprinkling locks and retries everywhere.

A TigerBeetle design looks different:

• Each customer has an account for “remaining credits”
• Each API call creates a transfer from customer credits to a revenue or burn account
• The API gateway checks the account balance before accepting the call

You still keep Postgres for customer plans, invoice PDFs, and human-readable labels. But the cap logic lives in the ledger, not in a cron job.

Deployment shape and ops reality

TigerBeetle’s deployment story is refreshingly boring. You copy a single binary to each node, format data files with cluster id and replica index, and start replicas with addresses for the cluster. Deploying TigerBeetle.

The docs also recommend a six-replica, three-cloud-provider setup for high availability. That’s a strong stance. It’s also expensive and operationally heavy for a lot of teams. TigerBeetle single page docs.

If you already run multi-region Postgres or Spanner, you know the deal. Availability costs money and attention, and you pay that bill every week on call.

TigerBeetle performance and correctness: what the data says

CTOs need two things from a ledger: it must be correct under stress, and it must keep up with peak load.

Throughput and client side batching

TigerBeetle leans hard on batching. The client APIs support sending many transfers per request. TigerBeetle’s own blog benchmarked client implementations by submitting one million transfers and measuring client-side throughput. It reported:

• Zig: 1,563,167 transfers per second, max batch latency 7 ms
• Go: 1,471,084 transfers per second, max batch latency 7 ms
• Java: 1,273,476 transfers per second, max batch latency 9 ms
• C#: 1,521,359 transfers per second, max batch latency 9 ms

See: Writing High-Performance Clients for TigerBeetle.

Those numbers aren’t end-to-end system throughput. They’re still useful because they show the client overhead stays low, even across FFI boundaries.

A third-party benchmark from SoftwareMill compared TigerBeetle to Postgres implementations and reported 42k TPS for TigerBeetle vs 15k TPS for a Postgres batched approach in their local tests. They also reported 60k TPS in “quick” tests. SoftwareMill benchmark.

If you run a ledger at 5k TPS peak, TigerBeetle’s raw speed isn’t the point. Headroom is. Headroom buys you simpler code, fewer lock fights, and fewer “we need to redesign the ledger this quarter” fire drills.

Correctness under failure: Jepsen and simulation testing

Jepsen’s TigerBeetle 0.16.11 analysis describes the system model and the constraints. It calls out the single-request transaction model and the lack of multi-request transactions. That matters for app design. You either shape your business operations into one request, or you accept a saga-style workflow outside the database. Jepsen: TigerBeetle 0.16.11.

Amplify also claims Kyle Kingsbury was unable to break TigerBeetle’s foundations in June 2025, finding one correctness bug in the read query engine that did not affect durability. It also describes TigerBeetle’s simulator, VOPR, which runs a whole cluster on a single thread and injects faults. Amplify Partners on TigerBeetle.

The TigerBeetle architecture doc backs this up and explains simulation testing as the most important technique, with VOPR running many cluster behaviors and fault injections. TigerBeetle ARCHITECTURE.md.

Here’s the CTO-level point: TigerBeetle treats correctness as a product feature, not something you bolt on for compliance. That changes how you staff the work and how strict you are in review.

Should you use TigerBeetle or Postgres for a ledger? A CTO decision matrix

Teams reach for Postgres because it’s already there. That’s rational. Postgres also has a huge ecosystem, mature tooling, and a deep hiring pool.

TigerBeetle wins when you need a ledger that stays correct at high write rates, under contention, with strict ordering.

I use a simple model with peers.

The Ledger Fit Matrix

Quotable definition you can use with your board:

A ledger database.

If you want a formal build vs buy decision, use our Build vs buy matrix for core infrastructure choices. TigerBeetle can be a build, buy, or hybrid choice depending on whether you run it yourself or use a managed service.

A real integration example: Interledger Rafiki

The Interledger Foundation wrote up how Rafiki integrates TigerBeetle as its accounting database. It shows concrete debit and credit entries for sending and receiving payments, and it calls out atomic transactions and audit trail benefits. It also notes you can deploy with Docker Compose or Helm on Kubernetes. Balancing the Ledger: Rafiki's TigerBeetle Integration.

This is a good pattern to copy: put TigerBeetle behind a service boundary and keep the rest of your stack boring.

CTO recommendations: how to adopt TigerBeetle without blowing up your org

TigerBeetle adoption isn’t a database swap. It’s a product and org change because you’re moving accounting rules into a core system.

Immediate actions

1. Pick one value flow. Start with one flow like credits, refunds, or inventory holds. Avoid “all money” as a first step.
2. Define the ledger contract. Write down account types, transfer types, and invariants. Treat it like an API spec.
3. Run a shadow ledger. Write transfers to TigerBeetle and keep Postgres as the source of truth for 30 to 90 days.
4. Reconcile daily. Compare balances and totals. Track mismatch count and dollar impact.
5. Load test with real batches. Use production-like batch sizes and concurrency. Client-side batching drives results. TigerBeetle client benchmarks

If you need a place to track this work, use Command Center to manage risks, migrations, and incident history. Our Command Center for tech debt and migration tracking fits well for a ledger cutover plan.

Policy framework

1. Ownership. Assign a single team to own the ledger schema and invariants. Don’t spread it across product squads.
2. Change control. Require an architecture review for new transfer types. Use an ArchiMate diagram to show system boundaries. Our ArchiMate modeler for architecture governance helps here.
3. Audit readiness. Define retention, export formats, and reconciliation cadence before you go live.

Architecture principles

1. Service boundary. Put TigerBeetle behind a ledger service. Don’t let every team talk to it directly.
2. Id strategy. Generate stable identifiers in the API layer, then store mappings in your OLGP database. TigerBeetle’s docs call this out as part of the split. System architecture docs
3. Event stream. Publish ledger events to Kafka or Redpanda for downstream systems. Keep the ledger as the source of truth.

This is where leadership shows up. You’ll need to tell teams “no” when they want to add random metadata to the ledger. Put that metadata in Postgres.

If you want to measure whether the change is helping, track lead time, change failure rate, and incident count. Our engineering metrics dashboard for DORA tracking is a good fit.

And plan for incidents. Ledger incidents are scary because they hit trust. Use a strict postmortem format and keep it blameless. Our incident postmortem guide for high trust teams is built for this.

Bigger picture: “everything is a transaction” is now an org design problem

TechCrunch quotes TigerBeetle’s team on use cases beyond fintech, like gaming live ops, energy smart meters, and usage based billing. That’s the trend. More products now meter, cap, reserve, and settle in real time. TechCrunch on TigerBeetle.

The hard part isn’t the binary. The hard part is getting teams to treat value movement as a first-class domain. That means shared language, shared invariants, and a clear owner. If you let every squad invent its own “balance” concept, you’ll ship bugs that look like fraud.

TigerBeetle also pushes a different staffing model. The company had eight employees as of July 2024 and reported 200 percent year over year community growth, with paying customers “since day one.” That’s a strong signal, and it’s also a reminder: you’re betting on a smaller ecosystem than Postgres. TechCrunch on TigerBeetle.

So ask yourself one question and answer it in writing: do you want your system of record for value to live in application code, or in a ledger you can test and audit?

Sources

1. TigerBeetle is building database software optimized for financial transactions, TechCrunch
2. Why TigerBeetle is the most interesting database in the world, Amplify Partners
3. TigerBeetle company timeline and milestones
4. Jepsen: TigerBeetle 0.16.11
5. Deploying TigerBeetle docs
6. TigerBeetle in Your System Architecture docs
7. TigerBeetle architecture internals, ARCHITECTURE.md
8. Balancing the Ledger: Rafiki's TigerBeetle Integration, Interledger Foundation
9. Writing High-Performance Clients for TigerBeetle
10. TigerBeetle vs PostgreSQL Performance: Benchmark Setup, Local Tests, SoftwareMill