A small application can keep its business state and ledger in one Postgres transaction. That is a real architectural benefit. A separate financial runtime needs to earn the cost of giving it up. The question is who should implement and operate the posting rules. Postgres supplies transactions, constraints, locks and access control. Your team combines them into a financial posting engine. FRAGMENT supplies a configured ledger runtime, while your team still designs the accounting model and validates the business commands calling it.
Compare a protected ledger, not an unguarded table
A fair Postgres design has immutable journal history, reviewed posting routines, balanced lines, stable posting identities, transactional concurrency controls and permissions preventing ordinary callers from bypassing enforcement. Aggregate invariants generally need more than a row-level check. Concurrent transactions also require deliberate isolation or locking and appropriate retry handling. Postgres constraints, transaction isolation. A fair FRAGMENT design has a complete reviewed schema, eligible strongly updated accounts, correctly scoped conditions, stable ledger keys, appropriate authorization, checked result variants and recovery for uncertain writes. Runtime enforcement applies to the configured rules; a valid but incorrect parameter remains a business problem. Posting, consistency.
The local transaction advantage
With a same-database ledger, an approved business transition, its journal effects and an outbox item can commit together:
BEGIN
accept immutable approved command
apply protected financial transition, if due at this stage
enqueue external work
COMMIT
This is a design sketch, not a complete SQL implementation. Network payment execution happens afterward. An outbox makes work durable; it does not itself guarantee a single external payment. With a remote ledger, local acceptance and financial acceptance are separate stages. Commit the command and outbox locally, attempt the intended financial transition with a stable identity, and record the observed result. If acknowledgement is lost, recover that transition. Expose pending financial acceptance instead of claiming a local commit proves financial success.
flowchart LR
A[Approved business command] --> B[Postgres command and outbox]
B --> C[Financial acceptance]
C --> D[Payment execution if required]
D --> E[Outcome and settlement evidence]
The financial acceptance box can be a protected Postgres routine or a FRAGMENT ledger transition. Those choices have different atomicity and ownership costs.
When delegation is useful
Consider a financial runtime when several application paths or generated callers must obey the same reviewed accounting definitions and balance guards, and your team prefers those rules enforced at a service boundary. This is an ownership argument, not proof that a properly engineered Postgres ledger is unsafe. For supported customer payments, evaluate FRAGMENT's payment interface alongside its ledger. Payment Types associate supported money movements with accounting, and the product documents automatic reconciliation to the ledger. That changes the integration comparison; it does not erase the operational-database boundary or prove every payment-method or payout requirement is supported. Make Payments.
When Postgres can be the better fit
Keeping the ledger local can make sense when accounting needs are stable, the team has the expertise and capacity to maintain the protected engine, and one local atomic commit materially simplifies the workflow. Existing provider requirements, service availability, authorization and schema lifecycle all belong in the decision. Keep payment execution and financial records separate in the comparison. Choosing FRAGMENT as a ledger does not require replacing Postgres as the application database or replacing an existing payment provider. Likewise, a single vendor can fulfill multiple roles.
Use current FRAGMENT pricing for an actual usage model. Do not infer a monthly minimum, payment-associated entry-fee inclusion or comparative total cost from list rates alone.
Implementation references
Use the current API contracts when implementing the architecture: