TigerBeetle vs PostgreSQL for ledgers: which to choose

When should a team choose TigerBeetle or PostgreSQL for ledgers?

Choose PostgreSQL for ledgers when your team wants a general-purpose store that its engineers already run, query and back up, and when the ledger logic is still changing faster than a fixed schema should. Choose TigerBeetle when the transfer path itself is the bottleneck or the risk, and you accept a narrower model in exchange for a purpose-built double-entry store. TigerBeetle is an Apache-2.0 project still on 0.x version numbers (0.17.9, released July 6, 2026), so treat its API and operating practices as moving targets and plan upgrades accordingly. The two can also run together, with TigerBeetle holding transfers and PostgreSQL holding the infrequently updated reference data around them.

The decision turns on four questions. First, schema rigidity: TigerBeetle's accounts and transfers have defined fields such as ledger, code and user_data, and new features are meant to fit without migrations, but any reporting or product attribute outside those fields must live elsewhere. PostgreSQL lets you add columns, constraints and views whenever you need them. Second, write contention: TigerBeetle is built for write-heavy transaction processing and avoids row locks, while a PostgreSQL ledger with a few hot accounts needs careful locking, batching or sharding. Third, replication and failover: TigerBeetle's documentation recommends 6 replicas across 3 sites, and PostgreSQL needs external tooling for automatic failover. Fourth, operating effort: confirm which of these your own staff can run, monitor and upgrade before you commit.

Before deciding, ask your current database team to measure peak transfer rates on your hottest accounts, list every ledger attribute that reporting depends on, and write down who will own failover drills for either option. Ask your vendors or DeployOpen for a written scope that covers schema design, the replica topology and the rehearsal of a failover. Label any cutover plan as illustrative until you have tested it in your own environment.

Which ledger scenarios favor TigerBeetle, and which favor PostgreSQL

This table maps common ledger scenarios to the platform that usually fits better and the condition that decides it. Read each row as a starting point, then test the condition against your own transaction volume, account contention, reporting needs and audit obligations.

Scenario	Better fit	Condition that makes it so
Payments core with heavy transfer volume on a few shared accounts	TigerBeetle	Write-heavy OLTP on hot accounts, where TigerBeetle is designed for strong consistency without row locks. Confirm throughput against your own workload before committing.
General ledger with many ad hoc reporting queries	PostgreSQL	Finance teams need flexible SQL joins, views and reporting across many tables, which TigerBeetle does not aim to provide natively. TigerBeetle is usually paired with an OLGP store for this.
Product team that needs custom account attributes on every record	PostgreSQL	Adding columns and tables is routine in PostgreSQL. TigerBeetle's fixed schema means new needs are expressed through its defined fields, so confirm they can carry your attributes.
Regulated ledger requiring auditable corrections	TigerBeetle	Recorded transfers cannot be erased, and corrections are made with reversing transfers, which keeps history auditable. PostgreSQL can meet this too, but it depends on your own table design and controls.
Small team with modest volume and existing PostgreSQL skills	PostgreSQL	Operating one familiar database avoids a second system. Choose TigerBeetle only if contention or throughput limits on balances are a measured problem.
Multi-site deployment requiring strong write availability	TigerBeetle	The docs recommend 6 replicas across 3 sites for production, and a 6-replica cluster stays available while at least 3 machines and the primary are up. Confirm the site and network design with your operations team.
Ledger that must combine transfers with rich reporting and integrations	PostgreSQL	Reporting, BI tools and third-party integrations expect SQL. If TigerBeetle is chosen, plan a PostgreSQL store for the infrequently updated and reporting data.

How each store is built, replicated and failed over

The four parts below decide how much of the ledger's safety you get from the database and how much you assemble yourself. Each card sets TigerBeetle's built-in behavior against PostgreSQL's general-purpose model, and states what your operations team has to own in each case.

Data model and schema

TigerBeetle stores two entities, accounts and transfers, built on debit/credit double-entry bookkeeping, and its schema is fixed. Each field has a defined role, and the docs state that new features can be supported without new columns, tables or migrations. PostgreSQL gives you general relational tables you design yourself, so ledger rules live in your schema, constraints and application code. Check whether your team wants that flexibility or wants the rules enforced by the store. Fixed schema means fewer ways to model a ledger wrong, but also fewer places to add a custom field without a new design.

Cluster replication layout

The TigerBeetle docs recommend 6 replicas for any production cluster, ideally across 3 sites with 2 replicas each, with each replica's data file on a separate disk and machine. Your team must plan the sites, network paths and disk layout before go-live, and the replica count is a design decision, not a tuning knob. PostgreSQL replication is built from a primary and one or more hot standbys, which operators size and place independently. Confirm how many sites your organization can run and who owns each replica's hardware.

Commit durability modes

PostgreSQL offers synchronous replication, where a commit waits for standbys, and asynchronous replication, where it does not. That choice trades commit latency against the risk of losing recent transactions on failover, and your team sets it per deployment or per session. TigerBeetle's replicas are part of the consensus group itself, so the durability model is set by the cluster design rather than a per-commit option. Ask your vendor and your own tests to confirm how each store behaves under a site outage before you accept a recovery point.

Primary election and quorum

In a 6-replica TigerBeetle cluster, electing a new primary needs 4 of 6 replicas, and the cluster stays available while at least 3 of 6 machines and the primary are up. Losing a site with two replicas leaves the quorum intact, but losing two sites does not. PostgreSQL does not include software to detect a primary failure and notify the standby, so automatic failover depends on external tools that your team selects, configures and tests. Plan the drill for each failure you expect, and confirm which of these tools your platform team already runs.

Client libraries and access control

TigerBeetle documents client libraries for .NET, Go, Java, Node.js, Python, Ruby and Rust, so your application teams must match one of these languages or accept building against a supported client. PostgreSQL has broad driver support, and its client authentication methods include password, GSSAPI, SSPI, LDAP, RADIUS, certificate, PAM and OAuth. Your security team should map which identity method each service uses and who can open a database session. Confirm that the language of each ledger-facing service has a supported client before choosing TigerBeetle.

Which capabilities are built in, and which you still build

This table compares what TigerBeetle and PostgreSQL provide out of the box for ledger work, and what your team would still design, test and operate. Read the cells as a checklist: where a row says to confirm, the supplied documentation does not settle the point and your own tests should.

Capability	TigerBeetle	PostgreSQL
Data model	Two entities, accounts and transfers, built on debit/credit double-entry bookkeeping	General-purpose relational tables; you define the ledger schema, account types and posting rules
Schema flexibility	Fixed schema; new features are said to fit without new columns, tables or migrations	Flexible; schema changes are normal, and migrations are your responsibility
Double-entry enforcement	Built into the data model: every debit has an equal and opposite credit	Not provided by default. Confirm how your schema, constraints or triggers would enforce balanced postings in your tests
Correction method	Recorded transfers cannot be erased; corrections are made with separate reversing transfers	Corrections depend on your application design and audit tables. Confirm how updates and deletes are blocked or logged in your setup
Ad hoc SQL and reporting	No SQL query interface is covered by the supplied facts; confirm how reporting data is exported and queried	Full SQL for ad hoc queries and reporting; you choose how to model reporting views
Transaction isolation and row locking	Strong consistency without row locks, per its OLTP concepts page; confirm behavior under your hot-account workload	Row-level locking and isolation levels are configurable; confirm contention behavior on hot balance rows in your own load tests
Replication and automatic failover	Six replicas recommended for production, across three sites; election needs 4 of 6 replicas; available while at least 3 of 6 machines and the primary are up	Hot standby, synchronous and asynchronous replication are supported; PostgreSQL does not detect primary failure, so external failover tooling is required
Point-in-time recovery	Not covered by the supplied facts; confirm backup and restore procedures with the vendor	Continuous archiving and point-in-time recovery are documented; you still design the backup target, retention and restore tests
License	Apache-2.0	PostgreSQL License, a liberal license similar to BSD or MIT
Client languages	.NET, Go, Java, Node.js, Python, Ruby and Rust client libraries are documented	Client drivers exist for many languages; confirm driver support for your stack and connection pooling needs, such as PgBouncer

Why hot accounts decide the write path

The write path for a ledger is decided less by average throughput than by how many transactions touch the same few accounts at once. A settlement account, a fee account or a clearing suspense account can be debited or credited by every payment in the system. In PostgreSQL, the usual way to keep such a balance correct is to update the row inside a transaction, which takes a row lock. Every other transaction that needs that row waits until the first one commits, so throughput on a single hot account is bounded by how fast each lock can be taken, held and released.

TigerBeetle takes a different approach. Its docs describe strong consistency without row locks and a single-core design aimed at 1 million transactions per second. The docs also position TigerBeetle alongside OLGP databases such as PostgreSQL, MySQL and SQLite, which hold infrequently updated data, and say TigerBeetle, optimized for write-heavy OLTP, works well alongside them. A practical split is to keep balances and transfers that hit hot accounts in TigerBeetle while customer profiles, configuration and reporting views stay in PostgreSQL. Confirm that split against the TigerBeetle OLTP concepts page before you commit to a design.

PostgreSQL can serve many ledgers well. If contention is spread across many accounts, for example one balance per customer wallet, row locks rarely collide, and batching several postings into one transaction can cut lock churn further. The decision therefore depends on your own pattern. Model the hot account explicitly: count the transactions per second that touch your busiest shared account at peak, including retries and fee postings, and load-test that pattern on a realistic PostgreSQL configuration and on TigerBeetle. Ask your team to produce the same test for the case where the hot account is the single bottleneck, because that is the case that changes the answer.

What each license allows and what it costs to adopt

TigerBeetle is licensed under Apache-2.0, a permissive license that allows your organization to use, modify and distribute the software, including inside proprietary products, subject to its notice and patent terms. The project uses 0.x version numbers, and the latest release in the supplied facts is 0.17.9, released on July 6, 2026. Under semantic versioning conventions, a 0.x line signals that the project has not declared a stable 1.0 release, so upgrade planning should assume that changes between releases need testing.

License scope: Apache-2.0 governs the source code. Ask counsel how it applies to your redistribution, internal use and any bundled dependencies.
Version line: Treat each 0.x release as a change that needs regression testing in a staging cluster before production upgrades.
Commercial support: The documented open-source release is what this page can describe. Confirm directly with the project whether paid support, hosted service or enterprise terms exist and what they cover.
Recurring cost: The software itself carries no license fee. The recurring costs are the infrastructure for production, which the project documents as six replicas across three sites, and the engineering time to operate it.

Confirm the project's written compatibility and upgrade policy before committing, and ask for it in writing.

What drives the running cost of each ledger store

Running cost for a ledger store comes from the machines you keep, the people who can operate them, the upgrades you must plan, the support you buy, and the custom features you build yourself. TigerBeetle and PostgreSQL shift these costs in different directions, so the same line item can be large for one and small for the other.

Infrastructure footprint

TigerBeetle's docs recommend 6 replicas for any production cluster, ideally across 3 sites with 2 replicas each, with each replica's data file on a separate disk and machine. A PostgreSQL ledger usually runs a primary, one or more standbys and failover tooling, which is a smaller footprint but still needs its own monitoring and backup storage. Ask for the machine, disk, and cross-site network costs for both designs at your transaction volume.

Team skills and hiring

Most engineers already know PostgreSQL, its backups, replication and query tuning, so that knowledge is cheap to find. TigerBeetle is a 0.x database with its own client libraries and operating model, so you should expect a narrower hiring pool and a period of internal training. Price this as ongoing staff time and as the cost of any vendor or partner training you buy.

Routine PostgreSQL upgrades

Minor PostgreSQL releases never change the internal storage format, so they are a binary replacement and restart. Major upgrades run through pg_upgrade or logical replication, and logical replication can shorten downtime to several seconds. Supported versions run until dates listed in the versioning policy, so budget a recurring upgrade cycle. For TigerBeetle, confirm the documented upgrade procedure, rollback path, and whether replicas must be upgraded in a fixed order.

Support model and who pays

Support can come from the vendor, the open-source community, or a partner under a retainer. PostgreSQL has a large community and many commercial providers, while TigerBeetle support options should be confirmed directly with its maintainers. DeployOpen supports self-hosted platforms through fixed-scope engagements and ongoing retainers, but it does not publish prices. In a quote, ask for response expectations, who handles incidents at night, and what is included in an upgrade.

Custom ledger features in SQL

Balances, holds, reconciliation views and audit reporting are often built as SQL tables, triggers and application code on PostgreSQL. Each new rule adds schema changes, migrations and tests that your team owns for the life of the system. TigerBeetle's fixed schema reduces migrations, but features outside its model must be built elsewhere. Estimate the ongoing build and test effort for each custom feature you expect in the next three years.

How to move ledger transfers from PostgreSQL to TigerBeetle

This sequence moves balances and transaction history from PostgreSQL tables into TigerBeetle accounts and transfers, proves the two stores agree, and then cuts writes over while PostgreSQL keeps the reference data and reporting it does well.

Inventory and map existing tables to accounts
Your team lists every PostgreSQL table that touches money: balances, journal or transaction tables, and the reference tables that describe customers, products and currencies. Each balance-holding row becomes a TigerBeetle account, and each money movement becomes a transfer. Keep a durable mapping table in PostgreSQL that links your internal account keys to TigerBeetle account IDs, because the ID scheme is yours to design. Done when every money-moving table has a written mapping and an owner signs off on it.
Define ledger and code values
Your finance and engineering leads agree on the ledger identifiers, one per currency or balance domain, and the transfer code values that label transaction types such as payment, fee or reversal. TigerBeetle's schema is fixed, so these values carry meaning that your old columns used to carry. Record the agreed values in a versioned document and in configuration. Done when a reviewer can trace each existing transaction type to exactly one code and each balance to exactly one ledger.
Backfill history as transfers
Load historical movements into TigerBeetle as transfers in the original order, and set opening balances with transfers from a clearing or opening account so that the double-entry books balance. Where an old record was wrong, do not edit it: post a separate reversing transfer that references the original, which keeps the audit trail intact. Done when every account's balance in TigerBeetle matches the balance computed from the PostgreSQL source for the same cutoff point.
Run both stores in parallel with reconciliation
Dual-write new activity to PostgreSQL and TigerBeetle while a scheduled job compares balances and transfer counts between the two systems. Investigate every difference, classify it as a mapping error, timing gap or real defect, and fix the cause before continuing. Confirm the reconciliation method with your auditors and with the TigerBeetle maintainers or documentation before you start, since the exact comparison logic depends on your data. Done when a agreed number of consecutive reconciliation cycles report no unexplained differences.
Rebuild queries, reports and custom attributes
Queries that filtered or sorted by free-text fields, joins to customer data and ad hoc reports cannot run against TigerBeetle directly. Move those reads to PostgreSQL, populated from TigerBeetle transfers or from the dual-write path, and store attributes that TigerBeetle does not hold, such as descriptive notes, in PostgreSQL keyed by transfer ID. Rebuild authorization and identity links in your application layer so each transfer is tied to the right user or service. Done when every report that finance uses produces the same totals from the new read path as from the old one.
Cut over writes and keep PostgreSQL for reference data
Stop dual writes and direct all new money movements to TigerBeetle, with the application writing transfers as the source of truth for balances. Keep PostgreSQL running for reference data, reporting, identity and the mapping table, and keep the reconciliation job active for a period your risk owner approves. Done when production writes flow only to TigerBeetle, the reconciliation job reports clean results after cutover, and a rollback path is documented and tested.
Confirm operating model and replica layout
Before go-live, confirm that the production layout matches TigerBeetle's documented cluster guidance, which recommends 6 replicas across 3 sites with 2 replicas each and a separate disk and machine for each replica's data file. Document backup, restore and failover runbooks for both TigerBeetle and PostgreSQL, and test them. Ask your infrastructure team to confirm the hosting cost for the replicas in your own environment, since that cost is yours to carry and no vendor price is implied here. Done when a restore test and a failover test have both been run and recorded.

Where ledger migrations usually run long

The longest parts of a ledger migration are rarely the database itself. They are reconciliation, reporting and the operating model around the database. Before you commit to either option, map the work in four areas: schema design, deployment topology, backup and recovery, and monitoring. On the PostgreSQL side, the schema is your own design, so balances, holds and corrections must be modeled by your team and tested against existing reports. On the TigerBeetle side, the schema is fixed to accounts and transfers, so the work shifts to mapping your current tables onto ledger, code and user_data fields and deciding how to express what used to be SQL joins. Ask any implementer to show that mapping in writing before work starts.

Reconciliation with existing reports is where projects most often overrun. Every balance your finance team has signed off must be reproduced from the new store, including historical periods. Reporting queries that depended on SQL joins need a replacement plan, either in a PostgreSQL reporting replica or in an exported analytical store, and that plan carries its own build and run cost. On the PostgreSQL side, connection pooling with PgBouncer is a common late addition, and it changes how transactions and session settings behave, so it should be tested under load. On the TigerBeetle side, the 3-site, 6-replica recommendation in the cluster documentation is a deployment decision with network, facility and disk costs that must be agreed with your infrastructure team early.

Backup and point-in-time recovery also need explicit design. PostgreSQL offers continuous archiving and point-in-time recovery, but you must configure archiving, retention and restore drills yourself, and automatic failover requires external tools. Confirm which tools your team will use and who operates them. Scope, deliverables and timelines for any of this work are agreed in writing before work starts, so ask each party to state exactly what is included, what is excluded and how acceptance will be tested. No durations are estimated here; request them as part of a written scope.

What buyers ask before choosing or hiring help for a ledger

Can PostgreSQL handle hot accounts with tuning alone?

It can serve many workloads with careful design, but a single hot account receives every update in one row, so writers queue behind each other. Teams usually mitigate this with sharded or sub-account designs, batching, or short transactions, and each of these adds application logic you must test and maintain. Whether tuning is enough depends on your peak write rate on the most active account, which you should measure under realistic load in your own environment. TigerBeetle's OLTP concepts page describes strong consistency without row locks as a core design point, which changes the contention picture, but you should validate it against your own transfer pattern before deciding.

Can TigerBeetle run without a PostgreSQL companion?

Yes, TigerBeetle can hold accounts and transfers on its own, but most ledgers also need data it does not model: customer profiles, product catalogs, reporting views and workflow state. TigerBeetle's documentation describes PostgreSQL and other OLGP databases as a good pairing for infrequently updated data, so the common pattern keeps balances in TigerBeetle and everything else in PostgreSQL. You will then own the consistency between the two stores, including how you handle a transfer recorded in one and not the other. Confirm which of these data sets your product needs before choosing a design.

What replication does a 6-replica cluster need to survive a site loss?

The TigerBeetle docs recommend 6 replicas for production, ideally across 3 sites with 2 replicas each, with each replica's data file on a separate disk and machine. In a 6-replica cluster, electing a new primary needs 4 of 6 replicas, and the cluster stays available while at least 3 of 6 machines and the primary are up. Losing one site removes two replicas, which leaves the cluster available under those rules, but losing a second machine before recovery could stop writes. Ask your architects to model site, power and network failure domains against those thresholds, and to confirm the behavior with TigerBeetle's documentation for your version.

How much effort does a migration take and what drives it?

Effort depends less on the number of rows than on how many services read balances directly, how much reporting depends on SQL joins over transfers, and how much history must be carried over. Cutover design matters most: you need a plan for in-flight payments, dual running or reconciliation between the old and new balances, and a rollback path. There is no supplied figure for typical duration, so ask any vendor, including DeployOpen, for a written estimate based on an inventory of your integration points and data volumes. A fixed-scope agreement is typically written before work starts, so the scope document should name these items explicitly.

What must our team supply for a ledger project?

Plan for four inputs: staff who own the ledger data model and account semantics, environments that mirror production topology including multiple failure domains, written reconciliation rules that define how balances must match external records, and a decision owner for accepting risk. Engineers must know both the double-entry model and your payment flows. Reconciliation rules are the most often underspecified item, because they determine what the ledger must prove and how corrections are recorded. TigerBeetle's docs state that recorded transfers cannot be erased and corrections use reversing transfers, so your rules should describe that process explicitly.

Is a 0.x TigerBeetle release production-ready for our risk profile?

The project still uses 0.x version numbers, and the latest release supplied is 0.17.9, released July 6, 2026. A 0.x version number signals that the project has not declared a stable 1.0 API, so you should expect breaking changes between releases and plan upgrade testing accordingly. Whether that is acceptable depends on your risk appetite, your ability to pin versions and run staged upgrades, and your regulator's expectations for vendor maturity. Review the release notes, the client library versions you use, and the production guidance in the docs before signing off.

Can we build and run this ledger in-house?

Often yes, if you have engineers with database and distributed systems experience and the operating capacity to run a multi-site cluster, backups and recovery drills. PostgreSQL's high availability docs state that it does not detect primary failure on its own, so automatic failover requires external tooling that you must select, test and maintain. A TigerBeetle deployment adds a second database technology with its own cluster operations. Whether to build, buy or hire help depends on how many people will carry the pager and whether your team has run similar systems. DeployOpen plans, implements, hardens and supports self-hosted platforms in your own infrastructure under written scope, and ongoing support is available as a retainer.

How DeployOpen helps choose, implement or migrate a ledger

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For TigerBeetle vs PostgreSQL for ledgers, the work starts with a written decision on whether balances stay in PostgreSQL, move transfers to TigerBeetle, or combine both, and it continues through build, handover and support.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names the ledger workloads, account and transfer volumes, and hot account patterns to be assessed.
We record which data stays in PostgreSQL, which moves to TigerBeetle, and which reconciliation and audit needs apply.

How we build

We build the chosen design in your own cloud accounts, data centers or air-gapped network.
Work covers the account and transfer model, replication layout, backup and restore paths, and client integration.
Security testing of the ledger API and its access controls is scoped alongside the build where the written scope includes it.

How we hand over

Deliverables include architecture documentation, configuration records and runbooks for operating the ledger.
Handover covers backup, restore and failover procedures, tested against the environment agreed in scope.
Compliance readiness evidence is prepared for your assessors, though DeployOpen does not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades for TigerBeetle and PostgreSQL, with each change planned and documented.
Ask any provider to confirm in the written quote which operational tasks, response arrangements and environments are included.

TigerBeetle vs PostgreSQL for ledgers