RowDex
Documentation

Safe mode: read-only and production guardrails

How RowDex protects production data: read-only connections, the production flag, confirmation for risky SQL, Redis and MongoDB commands, and guarded grid edits.

2 min readUpdated

On this page

Most database disasters are small slips: a DELETE without a WHERE, a DROP in the wrong tab. RowDex gives each connection a safety mode so those slips are caught before they run.

Screenshot placeholder

A confirmation dialog titled Save changes to production listing the UPDATE statements that are about to run.

public/docs/safe-mode-confirm.png
On production, RowDex shows what will run and asks first.

Two flags, set per connection#

Both are checkboxes in the connection form:

FlagEffect
Read-only modeThe connection refuses anything that changes data. Grid edits, inserts and deletes are blocked, and the session itself is read-only.
Mark as production databaseRisky statements and grid writes show exactly what is about to run and need your confirmation.

What counts as risky#

SQL#

StatementRisk
INSERT, UPDATE, DELETE, REPLACEMedium: a data write.
CREATE, ALTERMedium: a schema change.
DROP, TRUNCATEHigh: permanently removes objects or rows.
DELETE or UPDATE with no WHEREHigh: affects every row.

Redis#

  • High: FLUSHALL, FLUSHDB and KEYS *.
  • Medium: DEL, HDEL, LREM, SREM, ZREM, RENAME, EXPIRE and PERSIST.

MongoDB#

  • High: deleteMany or updateMany with an empty filter, and aggregation stages $out and $merge that write to another collection.
  • Medium: any other write method such as insertOne or updateOne.

What you see#

When a flagged statement is about to run on a production or read-only connection, RowDex pauses, lists the reasons it was flagged, for example DELETE without WHERE can remove all rows, and asks you to confirm. Nothing runs until you do.

Grid edits are guarded too#

Saving cell edits, inserting rows, deleting rows and restoring deleted rows from the results grid get the same treatment. On production you see the actual statements, up to the first several, and confirm before they run.

Try changes safely#

  • Use Begin and Rollback in the editor to run a write, check the result, and undo it. See Query editor.
  • Run EXPLAIN instead of the query to see what it would do, without executing it. See Explain plans.

Was this page helpful?