DBeaver Save vs Commit: A Guide to Transaction Modes

Save in DBeaver submits unsaved grid edits. Commit finishes supported pending work in the associated transaction. Whether Save also commits depends on the effective transaction mode and database behavior, as the Data Editor reference and transaction-mode reference explain.

Consider a hypothetical development task: change a label on a disposable record. The grid now shows the right value. That is a useful start, but it does not establish whether the edit reached the database or whether its transaction finished.

This guide explains how to tell those states apart before reporting work done. It assumes authorized access to a disposable development database. The exercise below has not been executed for this article.

Recognize the three states of a DBeaver edit

Unsaved changes in the grid

An edited cell can still be local, unsaved work. Save submits unsaved additions, edits and deletions; Cancel discards unsaved modifications. The documented controls distinguish those actions. A changed cell alone proves neither submission nor commitment.

For developers building similar status indicators, our Tiptap persistence guide examines the gap between local edits and backend acknowledgments. Its document-storage model is separate from SQL transaction control.

Executed changes in an open transaction

Manual commit introduces another boundary. Supported data changes can execute successfully yet remain pending until you finish their transaction. Save can clear the unsaved grid edits without committing the database work. That is expected Manual commit behavior.

Committed changes and what remains to verify

Commit finishes supported pending work. Ordinary Auto-commit commits statements after execution, following the transaction-mode rules. You still need to check that the intended record changed on the intended target.

The diagram covers successful, supported row changes. It leaves out execution errors and statements with different transaction behavior.

Save, Commit, Cancel and Rollback: choose the right action

The controls operate at different points in the edit lifecycle. This table combines the Data Editor controls with DBeaver's transaction semantics.

With ordinary Auto-commit, Save commits the resulting statements. Manual leaves supported changes pending. Enabled Smart commit can switch to Manual before submission. A disabled Save button therefore tells you too little to report the change as committed.

Preview the SQL before saving

After editing a cell, move focus to another cell. The editing reference describes Save and Cancel becoming enabled after that focus change. Open Save's dropdown, choose Generate Script, and review Preview Changes.

Look closely at how the statement identifies the record. Does it target the intended row, and does the change match your task? The preview helps with review; it establishes neither authorization nor successful execution. If colleagues need a record-editing workflow instead of SQL access, the Baserow create, edit and view guide compares those sharing actions.

Choose the transaction mode before editing

DBeaver documents Auto-commit and Manual as transaction modes. Smart commit modifies behavior while Auto-commit is active. Choose the finish point you intend, using the transaction-mode reference to check the settings.

A small edit does not automatically call for Auto-commit. Nor does Manual make production experimentation acceptable. The useful question is where this authorized change should finish and what else belongs to its transaction.

Smart commit can change the answer mid-workflow

With Auto-commit active, Smart commit switches to Manual before recognized modifying statements such as UPDATE, INSERT, DELETE, UPSERT and MERGE. Saving table-data edits follows the same documented rule. Ordinary SELECT handling normally does not trigger that switch. See the Smart commit documentation.

That classification is no blanket assurance about procedures, CTEs or every SQL dialect. It also does not establish that every SELECT is read-only or lock-free at the server.

The optional Return to Auto-commit on transaction end setting switches back after Commit or Rollback. Check again before the next operation. The built-in connection-type comparison lists Smart commit as off, so its availability is not evidence that your connection uses it.

Check the connection behind the label

The documented Production connection type defaults to Manual; Development and Test default to Auto-commit. Those types are customizable, and connection initialization can use a default or explicit mode. Read the effective toolbar state.

Before editing, establish the endpoint, database, schema, user and permissions. Check the active editor's connection too. A connection color or label is a reminder. It does not establish server-side authorization or prove that you reached the intended host.

A tab is not a transaction boundary

Review pending work on the associated connection. DBeaver describes Commit as applying all pending changes in the current transaction, so the scope can extend beyond the visible cell. Another tab does not establish an independent transaction; consult the transaction documentation before making that assumption.

In issue 37599, TanguyP reported telling a colleague a task was done while changes remained uncommitted after choosing the Production connection type. This is one attributed report. It supplies neither a frequency estimate nor a reason to enable production Auto-commit.

A clean grid is a poor completion criterion. Report the transaction outcome and the readback instead.

Apply the Target, State, Finish, Verify checklist

Target, State, Finish, Verify is this guide's editorial checklist. It combines the documented behaviors into a review sequence; it is not a DBeaver feature or a tested deployment method.

Target: establish the disposable fixture

For this hypothetical exercise, an authorized developer changes a fictional task label in an existing disposable fixture. DBeaver and authorized database access are already available.

Establish each checkpoint before touching the grid.

Record the label's baseline value. If you cannot explain existing pending work, stop there. Switching modes to make the interface look ready does not resolve that uncertainty.

State: inspect what Save submitted

Edit the intended cell, move focus, and preview the generated SQL. Check the record predicate and proposed change before Save. At this point, you are reviewing an unsaved grid edit.

After Save with effective Manual mode, inspect the execution feedback. Supported successful changes remain pending in the transaction under the documented Manual behavior. An error calls for investigation before any decision to commit. A changed display cannot settle an uncertain execution outcome.

Finish: decide after reviewing the whole transaction

Review all associated pending work. DBeaver's Transaction Log helps inspect operations and their status in the current session.

Commit only work whose scope and purpose you understand. If abandoning it, Rollback applies to supported uncommitted operations. An unexpected statement or target is reason to stop. Do not finish unfamiliar work just to clear an indicator.

Verify: read the record after finishing

Refresh or read back the intended record after the chosen transaction finishes, checking the target again. A separately understood connection can help assess visibility; a second tab alone proves no independence. Check your backend's isolation and snapshot rules. For a backend-specific example, consult the PostgreSQL isolation reference, not a universal visibility rule. If application verification is part of your task, check its refresh and cache policy separately rather than promising visibility from the grid.

Use the following measurement plan to record a disposable exercise. This article contains no collected observations.

Compare two separate paths against the recorded baseline. First, edit the fictional label, leave the cell, inspect the preview, and choose Cancel without Save. The expected local result is abandonment of the unsaved edit. Refresh and check the record as well; button state is insufficient evidence.

In a separate pass, edit the same disposable record and preview the change. Confirm effective Manual mode before Save, then inspect execution feedback and pending work. To abandon this change, review its transaction scope before Rollback and read the record again. Compare that value with the baseline. Keep unrelated pending work out of the exercise.

If an observation contradicts the expectation, retain the error and connection context. Establish whether work was submitted and whether the transaction finished before trying anything else. Blindly repeating Save can make an uncertain outcome harder to explain.

This JSON records the checklist and its evidence status. It is neither a database request nor a test result.

{
  "checklist": "target-state-finish-verify",
  "steps": [
    "target",
    "state",
    "finish",
    "verify"
  ],
  "evidenceStatus": "not-collected"
}

What teams get wrong about scripts and pending work

Statement execution and script execution differ

Execute SQL Statement acts on the query under the cursor or selected text. Execute SQL Script processes the editor's script or selected queries. Check the action and selection before running either, as described in the SQL execution reference.

Script processing has its own Commit type settings: At script end, After each query, After each N-th query and No commit. Error handling offers Stop + rollback, Stop + commit and Ignore. Read both settings. Manual toolbar mode alone cannot establish that an arbitrary script will be atomic. Native-client execution needs its own policy review.

An indicator is a prompt to investigate

Do not treat Save as unconditional commit. Treating Cancel as rollback makes the opposite error: it assigns a database action to a control for unsaved grid edits. Both misunderstand where the work currently sits.

The Pending transactions window shows active transactions across connections in the current session. Transaction Log reviews session operations. Neither is a complete durable server audit or proof that every relevant lock is visible.

Finish deliberately instead of relying on configurable idle settings. For transaction-related PostgreSQL migration waits, the separate concurrent-index diagnostics guide addresses the backend investigation. It gives no permission to commit unfamiliar pending work.

Limits and recovery decisions

Rollback assurances apply only to supported uncommitted operations. Database, statement and driver behavior determine the actual transaction boundary; a toolbar cannot add capabilities the backend lacks. Consult the deployed database's documentation for visibility and resource-retention semantics.

Check your installed DBeaver version, edition, driver and customized settings against the current client documentation. An online reference does not establish identical behavior in your installation.

After commit, transaction Rollback cannot undo the change. A mistake then needs a separately authorized remediation or recovery decision. Avoid improvising a production repair from this development checklist.

Before sharing SQL previews or logs, remove customer data and credentials while retaining enough context to explain the transaction outcome. If readback remains unresolved, say so in the status report. That uncertainty matters more than whether the grid looks tidy.