Spin up your first ledger in minutes
Clone the Formance Ledger on GitHub, run it locally, and post your first transaction.
Formance and TigerBeetle get benchmarked against each other in payments infrastructure, but the two platforms sit at different layers of the stack.
Formance is an open-source, programmable core ledger that unifies fiat and digital assets with regulatory-grade traceability, covering ledgering, orchestration, connectivity, and reconciliation above the storage layer. TigerBeetle is a specialized transaction database and not an operational ledger platform; it uses database software built for the hot path of financial transaction processing.
Picking between them is a category error until you know which layer you are actually buying.
Formance and TigerBeetle differ across ten properties, including abstraction layer, multi-asset support, built-in reconciliation, payment rail connectivity, and regulatory-grade traceability.
| Property | Formance | TigerBeetle |
| Abstraction layer | Operational core ledger platform with an open-source Ledger and Connectivity; Enterprise Flows and Reconciliation | Storage and consensus tier; low-level transaction database, paired with a general-purpose control-plane database |
| Account identifiers | Readable multi-segment strings, e.g. @wallet:polygon:0xabc | Numeric 128-bit identifiers for accounts and transfers |
| Schema model | Multi-segment namespace, arbitrary first-class metadata, Numscript-defined postings | Specialized transaction database; three numeric metadata fields per record, so text lives outside the hot path |
| Multi-asset support | Native; all assets in one ledger, customer-defined | Cross-asset movement handled outside the core; a separate ledger per asset |
| Metadata queryability | First-class queryable, server-side | Requires client-side join against the sidecar |
| Built-in reconciliation | Enterprise Reconciliation: policy-based matching, drift detection, balance verification | Application-layer responsibility |
| Payment rail connectivity | Enterprise pre-built connectors plus a generic connector framework | Application-layer responsibility |
| Fund flow orchestration | Enterprise Flows with retries and fallbacks | Application-layer responsibility |
| Regulatory-grade traceability | Immutable hash-chained log, bi-temporality; SOC 2 Type II, ISO 27001; supports DORA, GENIUS, MiCA | Immutable, checksummed, hash-chained data; ships no certifications out of the box |
| Open-source posture | MIT-licensed Core Ledger and Connectivity; Enterprise products (Flows, Reconciliation, Wallets, Web Console, pre-built connectors) are subscription-based | Open source |
| Deployment options | Open Source / Community Edition; Enterprise Self-Hosted; Enterprise Private Cloud | Self-operated or commercial support; specialized operations planning required |
Formance Ledger is an operational core ledger built on four properties: double-entry enforcement at the storage layer, Numscript as a purpose-built transaction language, native multi-asset accounts with bi-temporality, and four modules (Connectivity, Flows, Reconciliation, and Wallets) layered on top of the ledger.
Double-entry records every transaction as equal and opposite postings across two accounts, which is what makes ledger balances auditable and lets discrepancies be traced to a specific entry
Financial correctness is enforced at the storage and data model layer, beneath the application logic, so no service-layer code can bypass double-entry. Every transaction's postings sum to zero, and multiple send statements in one script commit as one atomic transaction.
Numscript is Formance's purpose-built transaction language that describes transaction intent in terms readable by both engineers and finance teams. A send statement names an asset, a source account, and a destination account, while multiple sends in a single script commit atomically.
A USD-to-USDC conversion through an omnibus account (a single omnibus or FBO account holding funds on behalf of many underlying owners) shows the multi-asset case that TigerBeetle's transfer-oriented model cannot express natively without a custom application layer:
// STABLECOIN_ONRAMP
// Event: Alice converts $1000.00 to 100 USDC through the platform omnibus via Circle
send [USD/2 100000] (
source = @users:alice:wallet
destination = @platform:treasury:omnibus
)
send [USD/2 100000] (
source = @platform:treasury:omnibus
destination = @counterparties:liquidityProviders:circle
)
send [USDC/6 1000000000] (
source = @counterparties:liquidityProviders:circle allowing unbounded overdraft
destination = @users:alice:wallet
)
set_tx_meta("event_type", "stablecoin_onramp")
set_tx_meta("conversion_id", "cnv001")
The postings carry explicit asset identifiers, USD/2 and USDC/6, and execute as one atomic transaction. Alice's USD moves from @users:alice:wallet through the platform omnibus to @counterparties:liquidityProviders:circle, and the delivered USDC is sourced from that named liquidity-provider counterparty.
Formance accounts are multi-asset by default, so the same account structure works across USD, EUR, stablecoins, or any asset the customer defines. Postings carry explicit asset identifiers, so a single ledger tracks fiat and digital assets without spawning a separate ledger per asset.
Formance Ledger also carries bi-temporality, which tracks both when an event was recorded and when it was effective. Separate recorded and effective timestamps keep historical balance queries accurate when transactions arrive out of order, and support point-in-time views and backdated corrections without rewriting history.
Four modules can be added on top of Ledger: Connectivity, Flows, Reconciliation, and Wallets.
Together, the four modules mean the operational work most payments teams would otherwise build themselves (provider integration, workflow orchestration, matching, and balance management) sits inside the platform.
TigerBeetle is a specialized transaction database for financial transfers, with a scope intentionally narrow to the hot path of financial transaction processing and payment-system context kept outside that path.
Four properties define TigerBeetle's architecture: a purpose-built OLTP design optimized for double-entry transfers, deterministic simulation testing (DST), a mandatory sidecar database, and a narrow scope that leaves everything above storage to the application team.
TigerBeetle is built for high-volume, low-latency double-entry transfers between numeric accounts. Every design choice serves that workload. Accounts and transfers use fixed-size 128-bit numeric identifiers instead of variable-length strings. Records carry three numeric metadata fields and nothing else, so the hot path avoids variable-width text entirely. Transfers commit in batches against a custom storage engine tuned for sequential writes, and the operation set is limited to a small, fixed vocabulary of transfer types.
A general-purpose OLTP database has to accommodate arbitrary schemas, joins, secondary indexes, and ad hoc queries; TigerBeetle deliberately does none of that. In exchange, it targets 1M+ transfers per second on batched workloads and predictable tail latency at that ceiling. However, anything outside the transfer hot path (human-readable text, reconciliation state, or provider-specific metadata) has to live somewhere else.
TigerBeetle's durability results come from deterministic simulation testing (DST), a technique conventional integration tests cannot match. TigerBeetle's simulator, the Viewstamped Operation Replication Simulator (VOPR), runs an entire cluster with mocked clock and mocked disk/network behavior and injects storage and network faults across simulated executions.
Deterministic simulated time lets the VOPR explore many more execution paths than ordinary integration tests. An integration test observes one execution of real time as the DST explores the state space. However, there is a technique limit: the VOPR's pre-registered query workload can create a blind spot that hides a bug.
In a TigerBeetle-based payments system, textual records such as reconciliation status, counterparty names, leg descriptions, and external reference hashes have to live in a second or sidecar database beside TigerBeetle, because the engine does not carry them.
The team owns, backs up, and keeps consistent a second database alongside the cluster. Because the sidecar sits outside TigerBeetle's replicated cluster, the sidecar claws back much of the engine-level disaster-recovery advantage at the system level. The cluster protects the transfers, but the metadata that reconciliation depends on has whatever durability the sidecar has.
TigerBeetle's excluded scope follows from the product boundary. Teams still need operational layers around the storage engine for multi-asset ledgering, plus reconciliation against bank or PSP statements and connectivity to payment service providers or custodians.
More complex movement patterns become application-design concerns. TigerBeetle has added query capabilities, but payment systems usually still need a separate control-plane database. Operationally, teams should also plan around a specialized database.
A client ran an identical 49-event stream through Formance and TigerBeetle behind a swappable ledger port in a single payments system, changing only the ledger implementation. Every client-specific number in the sections that follow (line counts, timings, and operational-question outcomes) comes from that run.
Both engines came out correct and safe: balances reconciled, no partial writes, idempotency behaved as documented, and records were immutable on both sides.
Correctness was not the differentiator, but within the three layers around the core ledger: how much scaffolding the team had to build for a working integration, how well the data model fit a multi-asset payments business, and what it took to answer operational questions after the fact.
Formance outperformed in all three layers: scaffolding (integration code and pre-built connector), data model fit (atomic multi-asset postings and bi-temporality), and operational questions (server-side reporting vs client-side sidecar joins).
The client's 49-event run put concrete numbers behind the scaffolding argument. The Formance adapter came in at 283 lines with no additional infrastructure to stand up. The TigerBeetle adapter came in at 473 lines, of which 113 existed only to build and maintain the mandatory sidecar database. The line-count gap traces directly to the data model.
With Formance, an account is a readable string such as @wallet:polygon:0xabc, multiple assets live in a single ledger, and metadata is a first-class queryable field on transactions and accounts.
TigerBeetle, by design, uses numeric 128-bit identifiers for accounts and transfers, requires a separate ledger per asset, and exposes only three numeric metadata fields per record, so any text the business actually needs (reconciliation status, leg names, counterparty descriptions, or external reference hashes) has to live outside the engine, in the second datastore the team owns and keeps consistent with the cluster.
Connectivity closes the rail-adapter gap. The pre-built Formance connector catalog includes Stripe, Adyen, Wise, Fireblocks, Kraken, Banking Circle, Modulr, Mangopay, Tink, and Powens. The generic connector framework handles any provider without native support.
Customers build their own connector for unsupported providers as Formance provides the framework, and the customer implements the translation layer. On TigerBeetle, each of those integrations is a bespoke adapter plus its share of the sidecar schema.
With Numscript, double-entry enforcement, bi-temporality, and atomic multi-posting across fiat and digital assets are properties of Formance Ledger rather than conventions the service layer must uphold.
The USD-to-USDC Numscript block above is the ledger-side atomic posting model for a two-asset conversion. Actual money movement still executes through connected providers.
Formance answered the operational questions the client cared about (balances by asset, transaction history filtered by metadata, reconciliation status, and human-readable leg descriptions) server-side, in a single API call per question.
TigerBeetle natively answers only balances and transfer history against its numeric identifiers. Anything human-readable, filterable by text, or joined against reconciliation state required a client-side join between the engine and the sidecar. The client-side join follows directly from the "text lives outside the engine" data model. The application layer still inherits that work every time a new operational question comes up.
TigerBeetle has two advantages over Formance: batched throughput and engine-level disaster recovery, with the caveat of a sidecar database.
On throughput, TigerBeetle targets 1M+ transfers per second on batched workloads with a custom storage engine, and predictable performance is a first-class design goal over a broad general-purpose database surface. Teams should still benchmark that ceiling against their own workload and batch sizes before treating it as their result.
In the 49-event run, Formance completed the stream in 1,099ms and TigerBeetle in 1,673ms. The result does not mean Formance is faster than TigerBeetle in general. The client's workload was per-leg rather than heavily batched, which is TigerBeetle's worst case. TigerBeetle's throughput advantage applies to extreme batched volume, and most teams should measure the ceiling against their actual workload and batch sizes rather than assume either result generalizes.
On disaster recovery, TigerBeetle's replication quorum can help a failed node self-heal from the cluster. With three-replica consensus, the engine-level DR model gives zero data loss on single-node failure by default, an edge over Formance self-hosted deployments, where replication has to be configured and does not guarantee zero data loss out of the box.
TigerBeetle's narrow operation set also helps prevent an entire class of accidental misuse. The committed-financial-transfer model limits what application code can do to committed financial records. The narrow operation set plus engine-level DR make TigerBeetle a defensible choice for a team that wants to compose its own financial stack from low-level primitives and has the staffing to build everything on top.
The sidecar database caveat still applies because the second datastore sits outside TigerBeetle's replicated cluster. Therefore, the system-level recovery story is weaker than the engine-level one, and any team relying on the guarantee has to plan the sidecar's durability with equal care. Some teams accept the sidecar burden to gain the engine-level guarantee.
Choose TigerBeetle for a proprietary storage layer serving a narrow, extreme-volume transaction workload with the engineering staff to build the application layers above it. Choose Formance for multi-rail financial products that need regulatory-grade traceability.
Evaluate TigerBeetle if you are building a proprietary financial database layer for a narrow, high-volume transaction-processing workload measured against your actual ceiling. A TigerBeetle build also requires the engineering staff to build and maintain every application-layer primitive above storage, including the sidecar database, the batching layer, reconciliation pipelines, and a rail adapter per provider.
A narrow, extreme-volume workload with a strong infrastructure team can justify the tradeoff, so you should plan for specialized production operations and a specialized codebase the team will debug.
Evaluate Formance if you are building financial products as a fintech or platform company and need to track fiat and digital assets across multiple payment rails and produce regulatory-grade traceability for auditors.
Formance fits teams that want to ship financial product features while offering traceability backed by SOC 2 Type II, ISO 27001, and support for DORA compliance, GENIUS, and MiCA.
Formance does not hold or move funds (every payout executes through a connected PSP, bank, or custodian), and integration is API-first work for an engineering team.