Safe editing

Changes made through the grid are held locally until you apply them. SQL and Redis commands you write are not staged and run directly against the connection the tab names.

Staging

Editing is available on real tables that expose a usable row identity. It is type-aware, and it covers inline edits, full-value edits, inserts, duplicates, and deletes.

The review tray counts what is pending and shows each original value beside its replacement. Apply or revert the whole batch or part of it, and copy the exact SQL or Redis commands Tablify would run.

Editing is disabled with a stated reason on views, generated columns, unknown types, and read-only connections. The server enforces the refusal, not the disabled control alone.

Applying

A batch applies atomically. If a row changed underneath you, Tablify reports the conflict and offers to reload, compare, or discard. A change that fails stays staged and tied to its target row, so nothing is silently dropped. Closing dirty work always requires a decision.

Risk

Action	Risk	Requirement
Browse, filter, sort, inspect, copy	Read	None
Insert or update rows, edit Redis values, rename, change TTL	Row write	Stage, review, apply
Delete rows or keys, bulk changes, TRUNCATE, Redis flush	Destructive	Review, plus the exact target confirmed
Create, alter, or drop schema objects, administrative commands	Schema	Outside the beta interface

A read-only connection rejects everything above Read at the server boundary.

A write against a production connection carries a persistent visible warning and a confirmation. That confirmation is the one prompt you can turn off, and the warning stays either way. A destructive action always requires its exact target typed back, on every environment and whatever the preference says, so the setting can only make Tablify stricter than the table above.

A statement whose effect is unclear is classified at the highest plausible risk, never as a read.