Memory vs. Latency Tradeoff in Large Transactions

Last updated: July 24, 2025

When submitting very large transactions, there are a few key areas where hardware and system configuration influence performance:

Memory Consumption (RAM)

Each posting in a transaction consumes memory during:

  • JSON parsing (in the API layer).

  • Transaction preparation (in the ledger engine).

  • SQL execution planning and batching.

What this means:

A transaction with 10,000 postings will build a large in-memory structure before it’s written to the database.

This can temporarily use tens or even hundreds of MB of memory depending on posting size and metadata.

Make sure the host running the ledger has enough free RAM to avoid excessive GC or swap. Memory pressure in PostgreSQL (e.g.,work_mem,shared_buffers) can also affect sorting and row locking logic.

Transaction Latency

PostgreSQL guarantees ACID properties — so:

  • The full batch of SQL statements (posting entries + volume updates + log inserts) is processed inside a single SQL transaction (see 📄 PostgreSQL Consistency Model: COMMIT or ROLLBACK)

  • The transaction can’t commit until all rows are written, any constraints are validated, and indexes are updated.

  • Advisory locks (e.g., from log hashing) can add a small queueing delay if enabled too.

Impact:

  • Latency tends to grow linearly or sub-linearly with the number of postings.

  • Baseline: 1-posting transaction = ~30ms latency (under optimal conditions)

  • Sub-linear behavior assumes batch processing efficiencies, e.g., preparing a single SQL transaction with many inserts is cheaper than N separate ones.

  • PostgreSQL and the Formance Ledger optimize internal writes and avoid redundant locks, especially when assets/accounts differ.

Estimating Latency (under testing for consolidated metrics)

  • Use fast NVMe storage for PostgreSQL WAL/log writes.

  • Monitor for checkpoint I/O stalls or buffer eviction under large transactional load.

  • Consider splitting extremely large operations into batches (if atomicity across all postings isn’t required).

Failure Surface Area

The more postings per transaction:

  • The greater the risk that one small issue (INSUFFICIENT_FUNDS on a single account) causes the entire operation to rollback.

  • The higher the retry cost, since retries repeat the entire batch.

If failure tolerance is key, consider chunking into multiple transactions — even if performance is good.