SQLly logoSQLly

Safety & guardrails

Put a thoughtful pause in front of risky work while keeping ordinary reads pleasantly boring.

Good safeguards should catch the expensive mistake without making every ordinary read feel like paperwork. Set a policy on a client, project, environment, server, or database, and it flows down the connection tree until you deliberately change a branch.

The layers, in the order they apply

  1. The editor warns. While you type, validation flags the shapes that tend to go wrong - an UPDATE or DELETE with no WHERE, an identity-column INSERT with no SET IDENTITY_INSERT - as squiggles, before you have run anything.
  2. The run gate asks. On Run, SQLly analyses the batch and decides whether it needs a confirmation, an AI review, or a refusal. Nothing has been sent yet.
  3. The driver enforces. Read-only and rollback-wrap are applied per GO batch inside the driver, on the way out. They are the last word, and they apply no matter which part of the app started the run.

Splitting it this way is deliberate: the two layers that can be fooled by clever SQL only ever warn or ask, and the layer that decides what actually reaches the server is the simple, boring one.

What you can turn on

Read-only

Refuse anything that is not a read, including read-shaped statements that reach the server's file system.

Rollback wrap

Run the change inside a transaction SQLly rolls back, so you can watch it happen without keeping it.

Confirmation

An explicit yes, with the verbs spelled out, before a data-changing batch runs.

Unbounded-change guard

Warn about - or block - an UPDATE or DELETE that has no WHERE.

Environment cues

Colors and badges so production looks like production before you touch it.

AI review

A plain-language read on a query's side effects before it runs somewhere protected.

Production is its own layer

A connection marked as a Production environment is read-only by default, whatever its own flags say. When you genuinely need to write, unlock writes for 1, 5, or 15 minutes from the status-bar chip or the command palette. While the window is open the chip counts down (4:59), and every data-changing batch still has to be confirmed with the exact SQL in front of you. When it expires, the connection locks itself again.

The unlock never outlives the app. It is held in memory for the session only - never written to disk, never restored on the next launch. Closing SQLly re-locks production, always.

Policies combine with environment defaults: Production forces read-only and rollback-wrap on, and Staging forces the rollback wrap. Where a mistake would be expensive, add an identity gate on top.

In this section