Skip to main content
Six levels, one per connection, set in the Customization pane of its edit form. The level decides what stands between a query and the server: nothing, a confirmation, Touch ID, or a refusal.

​
Levels

New connections start at Silent, which is the right choice for a local database you own. Move a shared staging connection to Alert and anything with real customer data in it to Safe Mode or Read-Only. Four things the table cannot carry. The confirmation dialog shows the whole statement, syntax highlighted and scrollable, with a Copy All button and a line naming the connection and whatever asked to run it. Touch ID falls back to your macOS password on a Mac without it.
Confirmation dialog over a query tab, showing a fourteen line UPDATE with Cancel and ExecuteConfirmation dialog over a query tab, showing a fourteen line UPDATE with Cancel and Execute

The statement arrives whole, however long it is

Silent is not a free pass: DROP, TRUNCATE, and a DELETE with no WHERE still raise the built-in dangerous query warning even there. And Read-Only goes past queries to the interface itself, disabling inline cell editing, adding, deleting and duplicating rows, table truncate and drop, and import.

​
Connections that are always read-only

A connection that cannot take a write runs at Read-Only whatever level it was given. Its edit form shows the level as fixed text, and every other level is dimmed in the toolbar padlock and in Database > Safe Mode Level. The level you chose stays saved and applies again once the condition no longer holds.

​
What the level gates

Safe Mode sits in front of query execution, saving cell edits, structure and table changes, sidebar operations, imports, and maintenance jobs, including the ones the AI assistant and the MCP tools ask for. It does not sit in front of reading metadata. Loading the sidebar, opening a table’s structure, and exporting data are never confirmed, which is why a backup stays available on a Read-Only connection.

​
What always counts as a write

The Redis, MongoDB, and etcd drivers cannot open a read-only session, so Safe Mode treats every query on those connections as a write: the Alert and Safe Mode levels confirm everything, and Read-Only blocks everything. Every other driver classifies reads and writes normally. The server runs the text inside a MySQL conditional comment, /*! ... */ or MariaDB’s /*M! ... */, so a statement holding one counts as a write even when the rest of it only reads. Remove the comment to run the statement on a Read-Only connection.

​
Changing the level while connected

A padlock in the toolbar carries the current level: open for Silent, closed for the rest. Click it for the six levels with the current one ticked. Database > Safe Mode Level is the same list.
Toolbar padlock with the six Safe Mode levels listed beneath itToolbar padlock with the six Safe Mode levels listed beneath it

The padlock reads the level without opening the menu

There is no session-only override. A change here writes back to the saved connection, so it holds across tables and tabs, shows up on the Options section, and reaches your other Macs when iCloud Sync is on. Editing the level in the form works the same way round and reaches an open connection right away.

​
Server read-only is not Safe Mode

Safe Mode runs inside TablePro. It cannot make a server accept a write the server itself refuses, and the wording tells you which one refused. “Cannot execute write queries: TablePro’s Safe Mode is set to read-only for this connection” is the app. Anything else is the server, and the usual causes are these:
  • You are connected to a read replica or a reader endpoint rather than the primary.
  • The server runs with read_only or super_read_only turned on.
  • The server or the session opens new transactions read-only.
TablePro opens its write transactions as read-write, so a server that only defaults new transactions to read-only accepts the save anyway. On MySQL and MariaDB this narrows down the rest:
innodb_read_only set to ON means you are on a replica. Connect to the primary to write.

​
Execution log

TablePro records each authorization decision, allowed or refused, to a local log: the time, the connection, the kind of operation, whether it was a write, and the outcome. The statement is stored as a SHA-256 digest, so the log is not a second copy of your data. Each record carries the hash of the one before it, so recomputing the chain shows whether a record was edited, reordered or removed.
This is tamper evident, not tamper proof. Anyone who can write the file can recompute every hash after the record they changed, and truncating the end leaves a chain that still verifies. Only storing it somewhere the audited person cannot write would fix that.
The log is local. It is not synced and not sent anywhere.

​
Managed by an organization

An administrator can impose a minimum level through a macOS configuration profile, delivered by an MDM such as Jamf or Kandji. The profile targets the com.TablePro preference domain with one flat key: A connection set below the floor runs at it, and a stricter choice is left alone: the policy is a floor, never a ceiling. A value TablePro does not recognize imposes no floor at all. While the policy is in force, the levels below the floor are dimmed in the toolbar padlock and in Database > Safe Mode Level, and the connection form lists only the levels at or above it. The level you chose stays saved and applies again once the profile is removed. This is a floor on TablePro’s own behavior, not on the database. It stops the app issuing a write; it does not stop the same person connecting with psql. Pair it with server-side privileges for anything that has to hold.

​
External clients

A write from an external client (Raycast, Cursor, Claude Desktop, any MCP client) clears three locks in order:
  1. External Clients (per connection: Blocked / Read Only / Read & Write), in the connection form’s Advanced pane. A Read Only connection rejects a write before the request reaches the database.
  2. Token scope (per integration: readOnly / readWrite / fullAccess), issued by the pairing flow. The effective permission is MIN(token.scope, connection.externalAccess).
  3. Safe Mode, per query. Everything on this page then applies, Touch ID prompts and confirmation dialogs included.
DROP and TRUNCATE always go through the confirm_destructive_operation tool, which needs a fullAccess token and the user’s approval every time. No token scope skips it. See the External API security model. A client that answers its own approval prompt has only answered its own. Only a fullAccess token stands in for TablePro’s dialog. On every other token the dialog still appears on the Mac, so a readWrite client asks twice.