How fresh is the data when I query it right after a transaction commits?

Summary

• Transaction databases guarantee Read Committed or Serializable isolation, meaning queries see changes from committed transactions but not in-flight work from other sessions.
• In Lakebase (Postgres-compatible), after a transaction commits, the data is immediately visible to new queries in the same session and to all other sessions (no other threads see uncommitted data).
• The freshness you see depends on your isolation level: Read Committed shows all committed changes as of query start time; Serializable sees a consistent snapshot from the beginning of the transaction.
• Lakebase uses MVCC (multi-version concurrency control) to maintain consistent snapshots, so queries never block waiting for writers, but different sessions may see different snapshots depending on their isolation level and when they started.
• For applications requiring strict consistency (banking, inventory), Serializable isolation guarantees that your transaction sees a consistent view; for high-throughput applications, Read Committed offers lower latency with eventual consistency.

How fresh is the data when I query it right after a transaction commits?
When a transaction commits in Lakebase, its changes become immediately visible to new queries. The freshness you see depends on your isolation level. In Read Committed mode (the default), each query sees all changes committed before it started. In Serializable mode, your entire transaction sees a consistent snapshot from start time. Either way, you never see uncommitted data.

Transaction isolation levels

Lakebase offers multiple isolation levels, each with different freshness and consistency trade-offs:

Isolation Level	Visibility	Best For
Read Committed (default)	All committed data as of query time; each query sees a fresh snapshot	High-throughput apps where eventual consistency is acceptable
Repeatable Read	All queries see the same snapshot within the transaction	Applications needing consistency within a transaction
Serializable	Transaction executes as if it ran alone; consistent snapshot from start	Critical systems that can't tolerate anomalies (banking, inventory)

Choosing an isolation level

For the freshest data, use Read Committed with short transactions. Each query sees committed changes. For consistency, use Serializable, accepting that conflicts may force transaction retries. An inventory system checking stock, deducting it, and updating shipment should use Serializable. An analytics system running hourly reports can use Read Committed.

How Lakebase handles freshness

Lakebase uses MVCC (multi-version concurrency control) to maintain snapshots. When you start a transaction, it captures the database state at that moment. In Read Committed mode, each new query gets a fresh snapshot seeing all committed changes. In Serializable mode, all queries see the same snapshot from transaction start. MVCC allows reads and writes to run concurrently without blocking. When your transaction commits, its changes become visible to new transactions immediately. Sessions in Serializable transactions won't see those changes until starting new transactions.

Use cases

Banking. Money transfers use Serializable isolation to ensure debits and credits are atomic. No other transaction sees funds in an inconsistent state.
E-commerce inventory. Order processing uses Serializable to prevent overselling. The transaction checks stock, reserves it, and updates inventory in one view.
Analytics. Hourly reports use Read Committed. Each query sees committed data; consistency across all queries isn't required.
Session management. Web apps storing session state use Serializable to update multiple fields atomically (balance, transaction history).

FAQs

For the freshest data, should I use Read Committed?

Yes. Read Committed shows all committed changes as of query time. Serializable is fresher only if you need all queries in a transaction to see identical data.

Can I change isolation levels mid-transaction?

No. Set it at connection or transaction start and apply it throughout. Changing mid-transaction causes inconsistencies.

Does querying right after a commit guarantee I'll see the change?

Yes, if you start a new transaction after the commit completes. Your new snapshot includes the committed change. You never see uncommitted data.

What if my transaction runs too long?

Old transactions hold snapshots that prevent cleanup of old row versions, degrading performance. Keep transactions short; run long analytics separately with appropriate isolation levels.