Double-entry mutation core
Move value with atomic debit and credit updates, posted and pending balances, account limits, ordered mutation, and deterministic duplicate handling.
Private preview · ledger database engine
Financial state that stays balanced.
TulaDB is a ledger-first database engine for value-exchange systems. It owns the part your platform can't afford to improvise — balances, holds, reversals, rejected transactions, and immutable history — and keeps every debit reconciled against its credit, close to the write path.
Available for architecture review, performance review, and controlled integration pilots. Production use requires deployment-specific security review, operational drills, and validation.
debit = credit
operationdebitcreditoutcome
transfer−1,250.00+1,250.00POSTED
reserve−400.00holdPENDING
transfer−90.00limitREJECTED
- Double-entry
- Atomic debit and credit, always reconciled
- Reserve · Commit · Rollback
- Holds are first-class, not a flag in a column
- Idempotent
- Durable operation identity; retries resolve the same
- Replayable
- Snapshot and replay recovery with evidence
The engine
A ledger core for systems where balances must stay explainable.
TulaDB is for teams that need more than “insert a row and reconcile later.” It owns the balanced state transitions, durable identity, pending holds, rejected outcomes, and queryable history that value-movement systems depend on.
Explicit reservation lifecycle
Reserve, commit, and rollback are first-class operations. A reserve holds the debit side; commit posts the credit; rollback releases the hold — no orphaned state.
Tiered settlement model
Model position and settlement flows together, so direct and indirect settlement patterns don't split correctness across separate services.
Rejected transactions are records
Failed business decisions stay visible as durable records — for audit, duplicate protection, customer support, and operational reconciliation.
SDK integration path
Evaluators review integration through SDK and gateway-oriented access surfaces built around a stable ledger contract.
Read path, separated
Read balances, history, pending reservations, rejected records, and accounts through a read-only path that never opens the mutation surface.
Why not a transaction table
Correctness belongs below your application — not remembered by every service.
Generic databases let you insert rows. TulaDB enforces the financial lifecycle beneath the application: reservations move through explicit states, rejected transactions stay visible, position and settlement update atomically, and retries resolve deterministically.
The product difference: TulaDB is not a table pattern. It's a mutation runtime for financial state that shouldn't be accidentally bypassed.
Generic transaction table
Application-owned safety
Rows represent intent, but lifecycle, ordering, duplicate handling, rejected visibility, and cleanup all live in services above the database.
TulaDB
Ledger-owned safety
Transfer, reserve, commit, rollback, and reject are first-class durable outcomes enforced by the ledger runtime itself.
Mental model
Every outcome has a durable shape.
A retry returns the same outcome. A rollback leaves an explainable trail. A rejected transaction stays searchable when operations teams investigate what happened.
OperationDebitCreditOutcomeWithout TulaDB
transferposted debitposted creditPOSTEDApp-level insert, no ordering guarantee
reservepending holdno credit yetPENDINGA flag in a column, easily orphaned
commitrelease holdposted creditPOSTEDSecond write, async failure window
rollbackrelease holdno creditVOIDEDManual cleanup, reconciliation risk
rejectunchangedunchangedREJECTEDDropped error, invisible to ops teams
Write path
A narrow path with a clear ledger contract.
The write path stays explainable end to end: validate the request, order the mutation, persist the outcome, and project it into queryable history.
Validate
Request shaping and idempotency checks on a stable operation identity.
Order
Deterministic, account-level sequencing of the balanced mutation.
Persist
Durable, append-only financial outcome written ahead of acknowledgement.
Project
Balances, holds, rejected records, and history for the read path.
API
Client & SDK layerApplication-facing integration around a stable ledger contract.
core
TulaDB CoreAccounts, duplicate protection, reservations, tiered flows, ordered mutation.
dur
Durability planePersistent outcomes, recovery artifacts, and replay review.
read
Query & audit planeImmutable history, account state, pending reservations, rejected records.
repl
Replication modelLeader/follower operation and controlled recovery for evaluation.
Architecture position
A balance system beneath workflows and above reporting.
Fraud checks, routing, customer orchestration, compliance, and network adapters stay outside the ledger. TulaDB owns the part those systems should not improvise: durable, idempotent, balanced financial state.
This keeps the ledger core small, deterministic, and reviewable while business workflows stay configurable above it.
Trust posture
Serious ledger systems need evidence, not adjectives.
Verification targets are part of the private-preview evaluation package. They exist to produce evidence for correctness, recovery, and operational review.
Core correctnessBalanced mutation, durable outcomes, reservation lifecycle, and failure handling.
Model validationDeterministic correctness gates, restart equivalence, and replay checks.
Recovery evidenceCrash/restart and replay behavior under controlled validation.
Replication reviewLeader/follower behavior, quorum progression, and recovery review.
Runtime checksMemory and undefined-behavior checks used as release evidence.
Store verificationOffline consistency probes for review workflows.
Private preview
Bring the ledger correctness argument to your architecture review.
TulaDB is ready for architecture review, performance review, controlled integration experiments, and design-partner discussions.