What does a ledger cost to build, run and replace?
No cost figure can be given without a written scope, and the answer depends on correctness testing, availability targets, audit access and who operates the system. A fintech team choosing between hand-rolling balances in PostgreSQL, running an open source ledger such as TigerBeetle or Blnk, or buying a managed ledger service is really comparing three different sets of recurring work. Neither TigerBeetle nor Blnk is a published price list, and no ledger-specific license fee or staffing figure has been supplied for this page, so the cost components and drivers below are what to price, not a number to plan against. TigerBeetle and Blnk are open source projects, so the software license is usually not the main cost. The work sits in the surrounding system: posting logic, idempotency handling, reconciliation, backups, monitoring, access control and the evidence that goes with them.
Start by separating one-time costs from recurring ones. One-time costs include design, integration with payment providers and the core accounting system, a correctness test suite that covers double-entry invariants, concurrency and failure recovery, and the migration of any existing balances. Recurring costs include infrastructure across the replicas and sites the design requires, on-call operations, upgrades, restore testing, security testing and support. For a hand-rolled PostgreSQL ledger, the largest recurring cost is usually the engineers who must keep correctness guarantees intact as the product changes. For an open source ledger, the largest cost is often the operator's skills and the support arrangement, which is why the quote should name who is paid for each part of the operation.
When requesting quotes, ask each provider for the following in writing: which components are included, who holds the on-call and upgrade duties, what evidence of correctness testing is delivered, how data export works if you leave, and what the fee covers when the ledger changes in production. Ask a managed ledger provider for its data export format and exit terms before you sign, and confirm with TigerBeetle and Blnk documentation which operational tasks they leave to the operator. A quote that cannot answer these questions is not yet comparable with the others.
Which cost components apply to each path?
This table compares three paths to a ledger: an in-house build on PostgreSQL, an open source ledger run with a partner, and a managed ledger service. Read each row as a cost component, then check who pays for it and whether it is one-time or recurring. The main takeaway is that the in-house path moves most cost onto your own engineering and testing budget, while the other two shift some of it to a vendor or partner under a written scope.
| Cost component | In-house PostgreSQL build | Open source ledger with a partner | Managed ledger SaaS |
|---|---|---|---|
| Engineering time for design and posting logic | Your engineers, one-time to build, recurring to maintain double-entry rules and idempotency | Partner scope covers initial design, your team retains ownership of account model and posting rules | Vendor provides the core model; your team still builds integrations and product-specific rules |
| Infrastructure and hosting | Your cloud or data center, paid as recurring infrastructure, sized by your own load tests | Your infrastructure, recurring; partner sizes and deploys it inside your environment | Vendor-hosted, recurring subscription; confirm what is metered and what triggers overage |
| Correctness and failure testing | Entirely your cost, one-time to build a test harness, recurring for regression and concurrency tests | Partner scope can include correctness and recovery test plans, agreed in writing before work starts | Vendor documents its own testing; you still need evidence for your own reconciliation and edge cases |
| Integration with payments and core accounting | Your engineers build every connector and general ledger interface, one-time plus recurring upkeep | Partner builds or customizes connectors within the agreed scope; recurring when upstream APIs change | Vendor may offer standard connectors; custom interfaces remain your cost, confirm what is included |
| Support and upgrades | Your on-call and staff, recurring, with no external party unless you contract one | Retainer or support plan, recurring, separate from the initial fixed-scope build | Vendor support tier, recurring; confirm response commitments and who handles upgrades |
| Compliance evidence | Your team prepares change records, access reviews and retention evidence, recurring at each assessment | Partner can prepare controls and evidence for assessments; auditors and certification bodies issue opinions | Vendor supplies some attestations; you still own evidence for your own controls, confirm what is shared |
| Exit and migration | Lowest vendor lock-in, but any future move requires your own data export and rebuild, one-time | Open source license and self-hosting keep data in your control; migration cost is one-time and scope-dependent | Export formats and termination terms drive cost; confirm data return and deletion terms before signing |
Which costs are one-time and which recur each year?
A ledger built in a relational database front-loads most of its cost into design and proof of correctness. The schema, posting logic, idempotency handling, and the reconciliation build are engineering work your own team or a partner completes once, and the cost of that work is high because every rule must be written, reviewed, and tested by people who will also maintain it. The recurring cost is the team that keeps the ledger correct as products change, along with the database operations that carry it.
- One-time build: Double-entry schema, posting rules, pending and posted transfer logic, and the integration code for payment providers and the general ledger.
- One-time verification: A test harness that replays transactions, checks balances against invariants, and proves that corrections do not silently change history.
- One-time migration: Loading opening balances and reconciling them against the system of record before go-live.
- Recurring operations: Database hosting, backups, failover testing, on-call rotations, and patching of the database engine.
- Recurring change and testing: Every new product or currency reopens posting logic, and annual penetration testing and vulnerability assessments apply to the system under the FTC Safeguards Rule.
Ask your team or partner to separate these items in writing, with the engineers and hours each line assumes, so you can compare them against the other paths on equal terms.
Running TigerBeetle or Blnk moves part of the ledger engineering into a maintained product, so the one-time work shifts toward configuration, integration, and testing of your own posting rules. The infrastructure is still yours to run in your cloud account or data center, which keeps recurring costs in your budget and on your staff. Licensing for the open source software itself is generally not the main cost driver. Operations, support, and upgrades are.
- One-time integration: Account model setup, mapping of your products to ledger accounts, and connections to payment providers and the core accounting system.
- One-time reconciliation and migration: Matching existing balances to the new ledger and building exception handling for unmatched items.
- One-time testing: Correctness, failure, and recovery tests against your own transaction patterns, which the open source project does not run for you.
- Recurring infrastructure: Compute, storage, network, and the replica layout you choose, including multi-site operation if your resilience targets require it.
- Recurring support and upgrades: A support plan from the project or a partner, version upgrades, and security testing of the deployment.
Confirm with the project maintainers or your partner which support tiers exist, what they cover, and how upgrades are tested before they reach production.
A managed ledger service shifts infrastructure and most operations to the vendor, so the recurring cost becomes a subscription or usage fee that scales with activity. One-time costs still remain, because your team must model accounts, connect payment and accounting systems, and migrate balances. The vendor's contract also introduces recurring third-party oversight, since the service becomes part of your ICT risk register and your audit evidence.
- One-time onboarding: Account model configuration, API integration, and migration of opening balances from your existing records.
- One-time contract and due diligence: Review of the service terms, data location, exit provisions, and the vendor's own security evidence.
- Recurring subscription or usage fees: Charges that may rise with transaction volume, account counts, or added environments. Ask for the pricing unit and how it is metered.
- Recurring vendor management: Reviews of the vendor's controls, incident notices, and changes to the service that affect your posting logic.
- Recurring internal work: Reconciliation against settlements, your own security testing of integrations, and the staff who manage the vendor relationship.
Request a written fee schedule with volume bands, overage terms, and the cost of an exit, and confirm which of these items the vendor's price excludes.
What moves the ledger cost up or down?
Ledger cost is set less by the software license than by a handful of requirements that decide how much engineering, infrastructure and testing the build needs. The cards below cover the drivers that move cost most, with the direction each one pushes the total. Settle these before comparing a hand-built PostgreSQL ledger, a self-hosted open source ledger and a managed service.
Transaction volume and latency
Higher sustained write volume and tighter latency targets push cost up because they require more capacity, partitioning, and load testing before go-live. A ledger that posts a few thousand transfers a day on a relational database rarely needs the same design as one posting peak bursts from many payment rails. Ask each option for benchmark results at your peak rate, including the cost of the replicas and storage that rate implies. Peak load, not average load, sets the infrastructure bill.
Availability and recovery targets
Stricter uptime and recovery objectives raise cost in redundancy, failover tests, backup verification and on-call coverage. Each extra site or replica adds hardware or cloud spend, and a hand-built ledger also needs its own runbooks and restore drills. Ask who carries the failover test schedule and what evidence the vendor or partner will hand over after each drill.
Currencies and account types
Each additional currency, asset type and account model (customer wallets, pooled holding accounts, fee accounts) multiplies the posting rules, exchange handling and test cases. Hand-rolled schemas tend to grow these rules in application code, which raises the cost of every later change. Ask whether the candidate platform models accounts and currencies natively and how new account types are added without a schema migration.
Reconciliation depth
Matching ledger entries against bank statements and processor exports is often the largest hidden cost. Simple daily matching with a few timing exceptions costs far less than multi-processor matching with partial settlements, fee splits and an exception queue that finance must work each day. Ask what matching rules ship with each option, what remains custom work, and who maintains the rules when a processor changes its export format.
Audit, retention and change control
Audit duties raise cost through logging, access controls and change management over posting logic. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to log the activity of authorized users and to adopt change management procedures, so those controls apply to a self-built ledger too. SEC Rule 17a-4(b) sets a three-year retention period for broker-dealer records, with the first two years easily accessible, which applies only if your entity is a broker-dealer. Confirm the applicable retention rule with counsel before pricing storage and archive design.
License terms and vendor lock-in
License terms and lock-in affect cost over the life of the ledger, not only at selection. Open source components carry no per-transaction license fee, but support contracts, managed hosting and proprietary add-ons may be priced separately. Check the license of every component you will run, the cost of exporting ledger history in a usable format, and the price and terms of any support plan before committing to an architecture that is costly to leave.
Why correctness testing is the largest hidden cost in a hand-rolled ledger
A relational ledger is only as trustworthy as the tests that prove it cannot drift. On PostgreSQL, the team must enforce that every transfer balances to zero across its debit and credit legs, that a retried API call with the same idempotency key cannot post twice, and that posted entries are never updated or deleted, with corrections made only as new reversing entries. Each rule is typically expressed through constraints, triggers, stored procedures and application code, and each layer can disagree with the others. Proving they agree takes a deliberate test program: unit tests for posting logic, property-based tests that generate concurrent transfers and check the invariants after every run, failure-injection tests for partial commits and retries, and a separate reconciliation job that recomputes balances from the journal. Most of that effort is spent after the first version works, and it recurs with every change to posting logic.
The same test program is what your security assessor will ask about. Under the FTC Safeguards Rule at 16 CFR 314.4, covered financial institutions must log the activity of authorized users and adopt change management procedures, and, absent effective continuous monitoring, must run penetration testing once a year and vulnerability assessments at least every six months (see 16 CFR 314.4). Those tests cover the ledger's application, database and administrative paths, so the testing budget grows with the ledger's attack surface. Confirm with your assessor and counsel whether your entity is a covered financial institution, what counts as effective continuous monitoring in your environment, and whether a ledger holding customer balances falls within the scope of those tests. The answer determines whether testing is a recurring retainer or a one-time project.
How do you build your own ledger cost estimate?
This sequence turns a vague ledger budget into a comparable set of written quotes, so build, open source and SaaS options are priced against the same scope and the same exit assumptions.
Fix requirements and entity scope
Start by writing down what the ledger must do: transaction volume and latency targets, account model, currencies, pending transfers, idempotency rules, history retention and availability targets. Record which legal entities, products and regions the ledger covers, because each added entity usually adds accounts, reconciliation work and audit access. The output is a signed requirements note owned by finance, risk and engineering together. Without it, every later quote is priced against a different system.
List every integration and data flow
Map each system that posts to or reads from the ledger: payment providers, card and payout processors, the core accounting system, bank statement files, fraud and sanctions services, and reporting tools. For each one, note the format, direction, frequency and who maintains the interface. Integration work is often the largest share of a ledger project and the least visible in early estimates. The check is a diagram and an interface table that engineering and finance both sign off.
Choose the operating model
Decide who will run the ledger after go-live: your own platform team, a partner under a support agreement, or a managed ledger service. This decision sets which cost lines exist at all, such as on-call coverage, database administration, patching, backup testing and vendor fees. Record the choice and the reason in writing. The output is a one-page operating model that the cost comparison will reference.
Price each component by who performs it
For each option, list the work items (schema and posting logic, correctness testing, infrastructure, monitoring, reconciliation tooling, security testing, documentation) and name who is paid for each: your internal staff, an implementation partner, a software vendor or a cloud provider. Staff costs come from your own payroll rates, partner rates come from written quotes, and infrastructure costs come from your cloud or data center contracts. Do not reuse a rate you have not confirmed for this scope.
Separate one-time costs from recurring costs
Split the estimate into one-time work (design, build, integration, migration of opening balances, testing and go-live) and recurring work (infrastructure, licenses or subscription fees, support retainers, upgrades, security testing and staff time for operations). Recurring lines usually decide the long-term comparison more than the build. Ask each vendor or partner to show both columns and state which items renew, at what trigger and under which terms.
Add a contingency for migration and exit
Include a separate line for moving ledger data later, whether you move off a hand-built schema, change open source projects or exit a managed service. Ask what export formats exist, how historical balances and transfer identifiers are preserved, and what a parallel run would require. This line is easy to omit and hard to add after go-live. The output is a stated contingency basis agreed with finance, not a percentage copied from another project.
Request written quotes against the same scope
Send the requirements note, integration map, operating model and exit assumptions to each vendor, partner or internal team, and ask for a written quote built on that exact scope. Ask each respondent to state assumptions, exclusions, change-request rates and support terms. The sequence is complete when the quotes can be laid side by side and every difference traces back to a stated assumption. Where a quote cannot be compared, return it for clarification rather than adjusting the numbers yourself.
Questions buyers ask about ledger cost and effort
How much effort does a ledger built on PostgreSQL really take?
The initial schema is the smaller part of the work. A hand-built ledger needs double-entry posting rules, balance calculation under concurrent writes, idempotency keys so retried requests do not post twice, pending and posted states, and a correcting-entry process instead of updates or deletes. Each of these needs tests that replay real failure cases such as timeouts, duplicate webhooks and partial batch failures. Recurring effort then sits in schema changes, performance tuning as volume grows, backups and restore drills, and on-call coverage for balance discrepancies. Ask your engineering lead to estimate these areas separately, because the one-time build and the ongoing operation are paid for from different budgets and by different people.
Does an open source ledger remove the license cost?
It removes the license fee for the software, but not the cost of running it. Licenses for open source ledgers are generally free to use, so the spend moves to infrastructure, staff who understand the ledger's data model, testing, monitoring, upgrades and support. Check the license terms of each component you plan to use, including any commercial add-ons, because a project can be open source at its core while some features sit under a separate license. For example, the Twenty CRM repository states that files marked as Enterprise fall under a commercial license, which shows why the license file should be read for every component rather than assumed from the project name.
How long does migration to a ledger take, and what drives it?
Migration duration depends on the volume of historical entries, how many systems write balances, the number of currencies and account types, and how much history must be reproduced in the new ledger. Teams usually need a period where both systems run in parallel and reconcile, which adds time before cutover. Balances must be proven equal at a defined point, and open pending items must be carried over with their state intact. Ask any provider for a written migration plan that lists the reconciliation checks, rollback steps and the data each stage moves, and do not accept a single duration without that plan behind it.
Can our team run a self-hosted ledger without outside help?
A team can run it alone only if it already has engineers who understand double-entry accounting, database replication, backup restoration and incident response for financial data. The skills gap is usually in reconciliation logic and failure testing rather than in deployment. Be realistic about staffing for on-call, change control and audit requests, since a single engineer leaving can stall the platform. Many organizations split the work: internal staff own posting rules and day-to-day operations, while an implementation partner handles the initial deployment, hardening, testing and documentation. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the split can be agreed in writing before work starts.
What should a support plan for a self-hosted ledger include?
A useful support plan names what is covered and who responds. Look for these parts:
- Written response paths for production incidents, with defined escalation to engineers who can read the ledger's data.
- Patching and upgrade handling for the database, the ledger software and the operating system, with a test environment that mirrors production.
- Backup and restore testing on a schedule, with evidence that a restore reproduces balances.
- Monitoring for replication lag, failed postings and reconciliation breaks.
- Change records for posting logic and configuration.
DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Confirm response times and service levels in the written agreement, since none are published here.
What should we ask a SaaS ledger vendor about exit and data export?
Ask how you would leave before you sign. Request the export format for every entry, balance, transfer state and audit log, and whether the export is complete and documented enough for another system to rebuild balances. Ask how long the vendor retains data after termination, how deletion is certified, and whether exports can be run on demand rather than only at contract end. Confirm which subprocessors and hosting regions hold the data, because these affect your third-party risk review. Finally, request a worked example of re-importing an export into a second system, and ask who pays for that work. The answers determine whether migration later costs days or many months of engineering effort.
What does it cost to move a ledger later?
Moving a ledger later costs more than building it, because the history is the hardest part to carry across. Whether the balances sit in a hand-rolled PostgreSQL schema, a self-hosted engine or a managed service, the target system has to reproduce every posted entry, each idempotency key used to prevent duplicate postings, the mapping between internal account identifiers and processor or bank references, and the audit trail that shows how each balance was reached. Losing any one of these means finance cannot prove that a balance today matches the transactions that produced it. Ask each vendor or implementer, in writing, for the export format (full transaction history, account hierarchy, pending transfers, reversals and metadata), whether the export is complete or sampled, and whether it can be imported into a second system without the vendor's help.
Retention terms decide how long you can rely on that export. Ask what the contract says about data return at termination, how long the provider keeps logs and backups after exit, and who pays for extraction. Then confirm which records your own business must keep and for how long. The SEC retention requirement in 17 CFR 240.17a-4 applies to broker-dealers, so it may not reach your ledger at all; a fintech may instead be bound by bank partner obligations, tax rules or state rules. Check the eCFR text for 17 CFR 240.17a-4 against your own registration status before you set the retention period.
Plan for parallel running before any cutover. Post the same transactions to the old and new ledgers for a defined period, reconcile both against bank and processor records, and treat any difference as a blocking exception until it is explained. Budget engineering time for the mapping work and for the second round of testing, not only for the copy job. Those costs recur with every migration, so they belong in the original build-versus-buy comparison.
How DeployOpen scopes a fixed-price ledger implementation
DeployOpen approaches the build, open source or SaaS decision for a ledger as a written scope before any work starts. We plan, implement, test, document and hand over self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks, so the cost comparison reflects your environment rather than a generic estimate.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
- The written scope covers transaction volume, account model, currencies, pending transfers and availability targets for your ledger.
- We document the engineering effort, infrastructure, correctness testing and support components so you can compare options on equal terms.
How we build
- We deploy the chosen ledger option inside your own infrastructure, including the database, networking and access controls it depends on.
- We test posting logic, idempotency, pending and posted transfers, and reconciliation against the scenarios agreed in the scope.
- We run security testing of applications and APIs around the ledger, including penetration testing and vulnerability assessments.
How we hand over
- You receive documentation of the architecture, configuration, backup procedures and operator runbooks for the ledger.
- Compliance evidence is prepared for the controls you need to show, such as change management and access logging, for your auditors to assess.
- If you move from a hand-built ledger to an open source ledger later, we can scope that migration as a separate written engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope, response expectations and service levels are set out in writing, so you should confirm them before signing.
- Ask any implementation partner, including DeployOpen, to itemize one-time build costs separately from recurring support and hosting.
