TulaDB ships the ledger engine, the operations tooling and the Iceberg analytics pipeline as one self-hosted product. Your team builds the product; money stays exact under retries, failures and peaks. First use case: real-time posting in front of a batch core, for institutions joining FedNow and Canada's Real-Time Rail.
Developer preview: 0.0.1-preview is a signed download; evaluating it is covered by the licence's evaluation grant. The engine, console, exporter and operations tooling run today; rail and core connectors are built with design partners. Not yet certified for production.
What you no longer build
Every payment, wallet or settlement system ends up building the same plumbing: a ledger in a general-purpose database, services to make it safe, a dashboard to run it and a pipeline to report from it. Each piece is re-implemented, re-tested and re-learned in production. TulaDB ships it as one product — each item links to its proof.
See it run · 48 seconds
A real-time payment is held, a second rail is refused, a resent message is answered once, and the hold posts — shown in the TulaDB operations console on a local stack built from source. Nothing is simulated.
Lead use case · instant-payment rails
Instant rails settle in seconds, around the clock, while most cores post in batches. FedNow is live today; Canada's Real-Time Rail launches in phases from late 2026. TulaDB sits in front of the core and keeps one real-time balance per account across every rail. These are the failures it removes. How it fits beside your core →
The rail runs at 3 a.m. on a holiday; the core is mid-batch. TulaDB posts every payment the moment it arrives. Your core is updated from the ledger's history on its own schedule, through a feed built with each design partner.
A timeout and a resend are one payment. Give each rail its own source and pass its message ID as the reference: a resend returns the original outcome instead of moving money again. That holds through crashes and failovers.
Funds held for a payment on one rail are unavailable to every other rail at the same instant. A second payment against them is refused when it arrives, not discovered at the next batch.
Your settlement position gets a floor no payment can cross, known obligations are set aside until they are paid, and each sponsored client gets its own cap. All three are configured from the ledger's limits and holds and enforced on every payment.
Who it's for
Credit unions, community banks, and the sponsor banks and aggregators that give them access: real-time posting in front of a batch core, one balance across rails, and a liquidity cap per client enforced on every payment.
Payment providers, payment-hub vendors, switch builders and bank platform teams: ship the product on a ledger that is already correct, operable and reportable, instead of building and owning that layer yourselves.
Proof, not adjectives
Design partners
Run TulaDB in your environment on replayed or anonymised traffic, compare it with your existing books, and shape the rail adapters and liquidity layer that come next. We reply within one business day.