PostgreSQL Consistency Model: COMMIT or ROLLBACK

PostgreSQL is an ACID-compliant relational database, which means it guarantees Atomicity, Consistency, Isolation, and Durability. At the heart of this model are transactions, and each transaction has only two possible outcomes:

✅ COMMIT

• This means the transaction succeeded.

• All changes made during the transaction are permanently written to the database.

• PostgreSQL ensures durability: even in the event of a crash, committed changes are safe and will persist.

• In the Formance Ledger, a successful transaction means:

  • Balances are updated.

  • Logs are inserted.

  • Any triggers (like hashing) are executed.

  • Any side effects (e.g., volumes, metadata updates) are finalized.

❌ ROLLBACK

• This means the transaction failed or was explicitly canceled.

• All operations done during the transaction are undone.

• PostgreSQL discards any intermediate state, so no partial updates ever reach the database.

• In Formance, if an error occurs (e.g., insufficient funds, validation failure, concurrency conflict), the ledger returns an error to the client, and no changes are committed.

🔢 PostgreSQL Sequences & Gaps in IDs

In PostgreSQL, sequences are used to generate unique identifiers (e.g., for transaction_id or log_id). These sequences are not transactional. That is:

• When you request the next value from a sequence (nextval('sequence_name')), PostgreSQL increments the sequence immediately, outside the current transaction.

• If the transaction later rolls back, that value is lost forever — it is not reused.

• This is by design, because sequences are intended to produce unique, ever-increasing values efficiently without rollback overhead.

🧱 Why This Matters for the Ledger

Because Formance wraps every ledger operation inside a single PostgreSQL transaction, this gives you strong consistency guarantees out of the box: