SQLlyThe knobs, the guardrails, and why it doesn’t choke on your schema
You’ve been burned by tools that autocomplete against a stale schema cache, or that
let a junior dev fat-finger a DELETE against prod. This is the tour for
you: what SQLly lets you tune, what it does to keep people out of trouble, and enough
of the “why” to trust it’s not just marketing copy.
IntelliSense is a setting, not a black box
Preferences β Editor β General lets you choose the completion engine and see exactly what it's doing.
The IntelliSense Source dropdown: Built-in (local parser) vs. Rust engine (the fuller, ffi-backed parser).
Pick your completion engine
The built-in source uses a fast local parser good enough for most editing. Switch to the Rust engine source when you want the fuller, FFI-backed parser driving completions - more accurate on gnarly, deeply nested SQL, at a small startup cost.
It tells you when it’s guessing
When SQLly is working from schema it can’t fully validate yet - a rough DDL sketch, a migration in progress - it tracks that internally as an incomplete region with its own provenance and confidence, rather than silently pretending the completion is authoritative.
Local files can outrank the live database
SQLly builds its schema model from your live database and a filesystem overlay at the same time. When a local DDL file is newer than the database object it describes - by modification time - SQLly prefers the file. That means IntelliSense reflects the migration you just wrote, not the table as it exists until you run it.
Only the changed part gets re-checked
Schema changes are tracked incrementally, so editing one table doesn’t force a full model rebuild - the engine re-validates just what moved and leaves the rest of the cached model alone.
Make the dangerous thing require a deliberate step
SQLly's connection model carries safety policy alongside credentials - set once per client, project, environment, or server, and inherited down the tree.
Wrap non-SELECT statements in a transaction automatically
Turn on auto-wrap for a connection and anything beyond a plain read runs inside an outer transaction scope you can review - and roll back - before it commits for real.
Lock a connection to reads, period
Block everything but SELECT on a given connection. Perfect for a read replica, an analyst-facing environment, or a server you never want a stray script touching.
Force a confirmation before it runs
Require an explicit “yes, really” before executing non-SELECT statements against a connection - the extra half-second that catches the query you meant for staging.
Refuse an UPDATE or DELETE with no WHERE
Per-connection policy can block unconstrained UPDATE and DELETE statements outright - the classic “forgot the WHERE clause” mistake, stopped before it reaches the server.
Require an AI review of data-changing queries
Turn it on per server, database, environment, or project and SQLly asks the on-device model to explain a query’s side effects in human terms before it runs - with a big, explicit WE WILL MAKE UPDATE AND DELETE CHANGES. banner and a critical warning when there’s no WHERE. Detection, gating, and the review dialog are in; the model that writes the explanation is being wired up.
Color prod an angry red
Give each client, project, environment, or server its own color and icon, so the “wait, that was prod?” moment gets intercepted by your peripheral vision before it reaches your fingers. Production connections also surface a PRODUCTION chip in the status bar.
prod) and every connection under it picks it up
automatically - override a single connection when you genuinely need to.
Prove it’s really you before prod runs
Wire your OS-native identity verification - Touch ID on macOS, Windows Hello on Windows - into the exact places a mistake hurts. The policy engine underneath already ships; the identity layer is being wired up now.
Verify to connect
Require your OS-native identity check before SQLly will even open a connection - set at any level of the hierarchy, so you can lock a single touchy server or an entire client’s prod environment with one switch.
Identity check for anything but a SELECT
Reads stay frictionless; the moment a statement has teeth - INSERT, UPDATE, DELETE, DDL - SQLly asks you to verify first. The statement classification is done; the OS-native prompt is the in-flight piece.
Your prod, your paranoia dial
Decide how long a verification is good for - every statement on the scariest boxes, or once per session / N minutes on the friendlier ones.
Tamper-evident verification log
Every gated action records who verified, what statement, which target, and when - a local, tamper-evident trail for when someone asks “who ran that against prod?”
Know what the server will do before it does it
Execution plans, parsed in-process
SQLly captures the SHOWPLAN_XML for your query, parses it in the Rust engine (no subprocess), and renders a structured operator report - every operator with its properties, ready to inspect. Actual plans (run the query, real row counts) are the dependable path today; estimated-plan capture has a known SQL Server bug being fixed, and the graphical node-and-edge canvas is the piece still being drawn.
A formatter that can’t corrupt your SQL
Configurable pretty-printing with a hard safety contract: output is re-lexed and compared token-by-token against the input, and any mismatch returns your SQL untouched. Mark -- formatter:off regions to keep hand-tuned layout verbatim.
Built for more than one server
If you manage connections for a team, a hostname list stops working around server #15.
Client Γ project Γ environment Γ server
Connections are organized along four independent axes at once. Filter the Servers panel by any of them, or all of them, to get from “every server we manage” down to “this one client’s prod database” in two clicks.
Real Entra ID auth, not a workaround
Connect to Azure SQL with device-code or browser-based Entra authentication - no storing a service principal secret just to get IntelliSense working. SQLly can also discover your Azure SQL servers and databases and help you add a firewall rule when the server says no.
Reach a database without the VPN ritual
Connect from wherever you are through an end-to-end encrypted tunnel that runs over a relay which can route your traffic but never read it - here’s exactly how it works. Part of SQLly Cloud; direct connections stay free.
The mechanics, one level down
Enough of the "why" to trust it - the full architecture lives in the engineering deep dive.
Querying and IntelliSense don’t share a thread
The query/IntelliSense engine is a separate, multithreaded Rust process. A slow query executing in the background doesn’t make your typing lag, and a schema refresh doesn’t block a query that’s already running.
The schema model swaps atomically
Schema collection runs in the background and builds a new model snapshot; the running app only ever sees the old snapshot or the fully-built new one - never a half-updated model mid-refresh, and never a stall waiting for one.
Completions are held to a real latency budget
The completion path is tested against an explicit latency ceiling as part of the engine’s own test suite - “feels instant” is a checked property, not a vibe.
The result grid renders what’s visible, not everything
Large result sets are paged from the server and virtualized in the grid, so scrolling stays smooth whether the query returned 50 rows or 500,000.
Want the full architecture?
Lexers, parsers, the model engine, the on-device AI stack - the engineering deep dive covers all of it, with code-level detail.