Can a committed transaction be rolled back normally?

No. A later correction generally requires another transaction or a recovery mechanism.

Does commit always make changes visible to every reader immediately?

Visibility depends on isolation, snapshots and replication behavior.

What if the connection drops during commit?

The client may not know the outcome and should use the application's defined reconciliation process rather than guessing.

AI Glossary / Data engineering and architecture / Beginner

Commit (data management)

Definition

In data management, a commit is the successful completion of a transaction that makes its changes part of the database's accepted state under the system's guarantees. It marks the point at which the transaction is no longer merely a set of tentative changes that can be rolled back normally. Exact durability and visibility behavior depends on the database and configuration.

What it means

A transaction groups related operations so they can succeed or fail as a unit. Before commit, a transaction may be abandoned with a rollback. After a successful commit, reversing its business effect normally requires a new corrective transaction or a recovery process, not an ordinary rollback of the already completed transaction. The word also appears in version control, but a database commit and a Git commit are different operations with different semantics.

How it works

The database checks the conditions required to finish the transaction, which can include constraints and concurrency-control rules. It records information needed by its recovery mechanism and completes the commit according to configured durability settings. Other transactions observe results under their isolation rules; an existing snapshot may not immediately show a newly committed change. The client then receives a response. If that response is lost, the client can be uncertain whether the commit happened even though the database reached a definite outcome.

Three practical examples

An order transaction inserts an order and its line items, then commits only after the required database operations succeed.
A data-cleaning job updates several related records within a transaction so an error can trigger rollback before acceptance.
An AI annotation tool saves an approved label and its audit metadata together, preventing one from being recorded without the other within the chosen transaction boundary.

Think of it this way

Think of drafting a set of ledger entries and then formally posting them as one accepted update. Until posting, the draft can be discarded. The analogy is limited because database systems enforce precise recovery and isolation rules, and a client may lose its connection while the system is completing the posting.

Worked example

Suppose a database stores two internal balances, A = 100 and B = 40. A transaction subtracts 10 from A and adds 10 to B. Before commit, the intended tentative state is A = 90 and B = 50. If the second update fails and the transaction rolls back, the accepted state remains 100 and 40. If both updates successfully commit, the accepted state becomes 90 and 50, preserving the total 140. This is a simplified data-consistency example, not a complete financial transfer design; real systems require additional controls and business rules.

Illustrative case study

Fictional case: Hazel Records saves a form and displays success before waiting for the database commit result. A later constraint failure leaves the user believing the record exists. The team changes the workflow so the interface distinguishes pending work, confirmed completion and uncertain outcomes after connection loss. It uses stable request identifiers where appropriate to avoid duplicate retries. The case illustrates accurate status reporting rather than a claim that one UI change solves all transaction failures.

Common misconceptions and mistakes

Do not assume that executing an update statement means the enclosing transaction has committed. Some environments use autocommit, while others require explicit transaction completion. A successful commit does not guarantee that every replica or previously opened snapshot immediately shows the change. Conversely, a client timeout does not prove rollback. Database transactions also do not automatically cover an external email, API call or file write unless the system includes an appropriate coordination design.

Business use

Businesses should define transaction boundaries around meaningful consistency requirements and make completion status clear. For important operations, plan how clients detect and reconcile uncertain outcomes. Test constraint failures, connection loss and retry behavior in controlled conditions. For AI workflows, consider whether a model output, review decision and provenance record need to be accepted together. Do not assume a database commit makes the content factually correct; it confirms an operation under database rules.

Check your understanding

A client receives no response after sending COMMIT. Is it safe to conclude that nothing changed?

Answer: No. The transaction may have committed before the response was lost. The application needs an outcome check or a retry design that handles this uncertainty.

Related terms

Durability (database systems)
Isolation (database systems)
Autocommit
transaction
rollback
ACID
durability
isolation
idempotency

Learn next

In a disposable test database, perform two related updates within one transaction, then compare rollback and commit outcomes. Observe the data from a second connection under the documented isolation level. Finally, review how the application reports a lost connection at the commit boundary.

Sources

Primary implementation references: PostgreSQL COMMIT documentation, https://www.postgresql.org/docs/current/sql-commit.html ; transaction tutorial, https://www.postgresql.org/docs/18/tutorial-transactions.html . Official COMMIT page opened and transaction search excerpts consulted; database-specific durability, isolation and editorial review remain pending.

Previous: Commissive speech act Next: Commitment ordering