The practical itch behind SQLly, and the kind of workbench it grew into.

I am a .NET developer who spent years working mostly in SQL Server, with useful detours through MySQL, PostgreSQL, Oracle, and MariaDB. My everyday editor was SQL Server Management Studio, until my work moved to the Mac.

The tool I missed was SSMS. It did not do everything, but it was fast and stable, which counts for a great deal when it is open all day. Azure Data Studio offered more on paper, but it is now deprecated and never filled that particular gap.

The Mac editors I tried were perfectly serviceable, but they lacked the thoughtful, advanced touches I had grown used to in tools such as LINQPad. I kept working around the gap for a while and assumed building a real alternative would cost more energy than it was worth.

That calculation changed. Modern LLMs, better documentation, and a decade of sample tooling turned a native, genuinely quick SQL workbench from an impossible side project into a plausible one. So I started building the tool I wanted to use.

That's SQLly.

What I cared about

• Fast and stable: a GPU-rendered native app, not a browser wearing a desktop costume.
• Private by default: no telemetry, opt-in cloud features, and identity checks that remain on your machine.
• Useful context: it reads your data as well as your schema, then explains what it is doing.
• Safety by design: the dangerous action takes a deliberate step; routine work stays out of the way.
• Yours to keep: plain files and no lock-in, free on every major platform.

A guided tour of SQLly, arranged around the work you are here to do.

SQLly is built around one simple idea: the tool should know enough about your database to be genuinely helpful. These guides follow the shape of real work - writing a query, understanding its result, and keeping a collection of connections straight.

These guides explain both shipping features and work still in progress. For the full status-tagged list, visit Features.

A place to write SQL with a little less busywork and a lot more context.

The query editor is where most of the day happens, so it is more than a place to hold text. IntelliSense works from a live model of your schema and data, while SQLly directives use ordinary SQL comments to remember how you want the result to look.

Completions that pay attention to your query, schema, and, when useful, the data itself.

Good completion should feel like a quiet assist, not a slot machine. SQLly builds suggestions from one SQL model engine: a shared view of your schema and data, rather than a pile of disconnected regexes. It can therefore see where the cursor is in the statement and offer the things that belong there.

SQLly

The two ideas below - schema awareness and data awareness - are what let completion work from the database in front of you rather than a generic SQL dictionary.

Suggestions grounded in the tables, columns, routines, and relationships you actually have.

Schema awareness starts with the actual shape of your database: its tables, columns, procedures, and especially its keys. SQLly keeps that picture as a snapshot so suggestions can stay quick and consistent, then refreshes it as the catalog changes.

• Tables and views, with their columns and types
• Stored procedures and their parameters
• Declared foreign keys, pulled in bulk for fast join reasoning
• Name-inferred relationships where no formal key exists

The pages below cover the parts you notice most while writing a query.

Start a JOIN and SQLly can offer the ON clause, favoring real foreign keys and clearly labeling its best guesses.

Start typing JOIN OtherTable and SQLly can offer the ON clause. It follows a deterministic join path through the model, preferring declared foreign keys and using name-based relationships only when needed. Each suggestion includes a confidence signal, so a fact and an educated guess never look the same.

How it decides

1. Declared foreign keys. When a foreign key connects the tables, SQLly uses that exact column mapping first.
2. Name-inferred relationships. With no FK, SQLly can match conventions such as CustomerId to Customer.Id and labels the suggestion as inferred.
3. In-scope joins. It only offers tables already present in the current FROM/JOIN set, so its ON clause resolves in the query you have.

Related: Auto alias suggestion keeps the tables it joins readable.

Keep joins readable with table-name aliases that stay consistent from the first column to the last.

When a table joins a FROM or JOIN clause, SQLly can offer a short, readable alias based on its name. It then uses that alias consistently when it qualifies columns, so the query stays easy to follow.

Why it helps

• Stable. The same table receives the same alias throughout a session, which keeps queries familiar.
• Readable. Aliases come from the table name, not a parade of t1/t2 labels.
• Part of completion. Once an alias exists, column completion uses it automatically, so c. offers Customer's columns.

Related: Auto join suggestion uses these aliases when it writes the ON clause.

Press F2 when completion misses the mark; your report can become the test that keeps the fix in place.

Completion gets better when it meets real work. If a suggestion is wrong, missing, or noisy, press F2 to capture what happened. A useful report becomes a regression test, giving the fix a much better chance of staying fixed.

The feedback dialog

What happens to a report

1. Capture (F2). SQLly saves the statement, cursor context, and the scoped catalog slice needed to reproduce the case.
2. Redact. SQL literals are removed and the catalog snapshot stays scoped before anything leaves your machine. See Privacy.
3. Sign and send. The report uploads in the background with retries, so a flaky connection does not lose your feedback.
4. Triage. Submissions arrive in an admin queue for review.
5. Lock it in. Accepted reports become cases in a dedicated verification suite: a real test that keeps failing until completion is right.

When a column's values matter, SQLly can use them to make the next suggestion more useful.

The schema tells SQLly what a column is; data awareness helps it learn what the column contains. With carefully bounded value introspection, completion can help on the right side of a WHERE clause and, over time, let you work with a readable name instead of an opaque id.

Bring real, distinct values into completion so a WHERE clause is less of a guessing game.

When you are completing a value such as WHERE Status = , SQLly can look into the table and offer the distinct values the column really holds. It saves you from guessing or opening a scratch query just to check a label.

How it works

1. SQLly recognizes that the cursor is in a value position for a specific column.
2. It samples distinct values for that column and adds them as value-completion metadata to the model.
3. Those values appear in the completion list, ranked and ready to insert.

Look up a familiar name instead of memorizing an id; SQLly follows the relationship for you.

Databases are fond of ids; people are usually fond of names. With column introspection configured, SQLly will let you search by name and insert the id, following the foreign key when you complete WHERE CustomerId = .

Configuring interchangeability

1. Point an id column at the display column on its referenced table, such as Customer.Name.
2. SQLly follows the foreign key when completion is requested for that id column.
3. Type the readable name and SQLly inserts the matching id.

Builds on table value introspection and the declared foreign keys from schema awareness.

Run the statement you mean to run, then stop it cleanly when the plan changes.

Run the whole document or only the selected statement, then cancel a runaway query for real instead of merely looking away from it. Multiple result sets arrive as separate grids, with errors, PRINT output, and timing in the messages pane.

• Run all executes every batch in order.
• Run selection executes only the highlighted text, useful in a scratch file full of statements.
• Cancel asks the server to stop the query on all four engines, rather than only stopping the local view.

Small SQL comments that remember how you want results shaped, formatted, and charted.

A directive is an ordinary SQL comment that SQLly understands. The database still sees only the query you wrote, while SQLly uses the comment to shape or format its result. Because directives live in the query text, they travel with the file and apply again every time you run it.

Every directive shares the same namespace - the word sqlly after the comment marker:

-- sqlly view: pivot
-- sqlly pivot: row:Region; column:Year; value:Sales:sum
-- sqlly chart: kind:bar; label:Region; values:Sales
-- sqlly format: column=Sales; number=2

Turn a familiar result set into a cross-tab with a short, portable comment.

The pivot directive turns a flat result set into a cross-tab without a wizard or separate tool. Use a view directive to open pivot mode and a pivot directive to describe the rows, columns, and values.

Syntax

-- sqlly view: pivot
-- sqlly pivot: row:<cols>; column:<cols>; value:<col>:<agg>

Fields are separated by ; and written as key:value; their order does not matter. These three are required:

Choose count, sum, avg, min, max, or first as the aggregate. Column names are flexible: [Region], `Region`, and "Region" all resolve to the same column.

Examples

-- sqlly view: pivot
-- sqlly pivot: row:Region; column:Year; value:Sales:sum
SELECT Region, Year, Sales FROM sales;

Here is a pivot with two row fields and formatting for its value cells:

-- sqlly view: pivot
-- sqlly pivot: row:Region,Country; column:Year; value:Amount:sum; valueformat:decimals=2, red=true
SELECT Region, Country, Year, Amount FROM ledger;

Optional formatting

Two optional fields format the numbers. valueformat: styles all value cells; format:col: styles one field. Both take either the word default or a comma-separated list of options:

The same cross-tab is available interactively without touching the query - see Results › Pivot, which builds the directive for you as you drag fields.

Give each column the presentation it deserves, automatically whenever the query runs.

Formatting directives describe how one column should look - numbers, dates, booleans, text, and more - and apply every time the query runs. Right-click a column header and choose Set Formatting Override… to have SQLly write the comment for you, or type one by hand when you prefer.

Syntax

-- sqlly format: column=<name>; <rule>[; <option>...]

The first segment is always column=<name>. The second is the format rule:

Trailing options: thousands=true|false and style=fixed|percent|bytes refine a number= rule.

Examples

-- sqlly format: column=Total; number=2
-- sqlly format: column=Qty; number=0; thousands=false
-- sqlly format: column=Created; date=%Y-%m-%d
-- sqlly format: column=IsActive; boolean=Yes/No
-- sqlly format: column=rate; number=1; style=percent
-- sqlly format: column=Card; mask=0/4
SELECT * FROM orders;

These are the same knobs exposed in Results › Formatting - the directive is what the formatting UI writes into your query.

Tell the Chart tab what story to draw before the result even arrives.

The chart directive prepares the result's Chart tab from a comment. It is the same chart you can configure interactively, but the setup travels with the query and comes back on every run. Use a view directive to open the Chart tab and a chart directive for the type, labels, series, and aggregation.

Syntax

-- sqlly view: chart
-- sqlly chart: kind:<type>[; label:<col>][; values:<cols>][; aggregate:<agg>][; order:<order>][; top:<n>][; navigate:<true|false>]

Fields are separated by ; and written as key:value; order does not matter. Only kind: is required, and the rest use the chart's defaults when omitted. Column names are flexible, so [Region], `Region`, and "Region" all resolve to the same column.

Examples

-- sqlly view: chart
-- sqlly chart: kind:bar; label:Region; values:Sales
SELECT Region, Sales FROM sales;

For two series, summed per category and shown largest first:

-- sqlly view: chart
-- sqlly chart: kind:line; label:Month; values:Revenue,Cost; aggregate:sum; order:value; top:12
SELECT Month, Revenue, Cost FROM monthly;

Chart types

Each kind: value draws a different mark. The gallery below names what to expect; its screenshot placeholders are waiting for their real captures.

The same chart is available interactively without touching the query - right-click the grid and choose Chart…, or click the Chart tab. Saving from the Chart sidebar writes the directive back into your query for you. See also Results › Pivot, the other in-grid view of your rows.

Tidy up a query without changing what it means. The formatter is careful on purpose.

The formatter is configurable, but it is deliberately cautious. SQLly re-lexes and compares its output token by token with the input; any mismatch leaves your SQL untouched. It can reindent, recase keywords, and align clauses without taking chances with comments or literals.

Mark a region to leave exactly as written when the formatter should keep its distance:

-- formatter:off
SELECT weird , hand_aligned
       , columns   -- left exactly as typed
-- formatter:on

One fuzzy-search stop for commands, connections, settings, and places you need to get to.

Commands, connections, preferences, and navigation are all one fuzzy search away. Open the palette with ⌘⇧P or Ctrl+Shift+P, start typing, and it narrows the list to what you mean. Each row shows its category and, when there is one, its shortcut.

File

Edit

Query

View

Tools

Window, Help & Quick Actions

Two categories are generated from your setup: Switch to Connection 1-9 and Quick actions, which surface the snippet quick-actions you've assigned. Detach / re-attach results are desktop-only and don't appear in the in-browser preview.

Pair it with customizable keybindings and the tab switcher for an entirely keyboard-driven workflow.

Keep the shortcuts your hands already know, or make a new set that fits your workflow.

Your shortcuts should fit your hands, not the other way around. Rebind editor and app commands to match the muscle memory you already have; bindings live as plain, version-controllable configuration alongside the rest of your settings.

Reading the tables: ⌘/Ctrl means ⌘ on macOS and Ctrl on Windows/Linux - the same physical role. A few chords use the real Ctrl on both platforms; those are written out in full. Chords joined by “or” are alternates for the same action. Everything below ships as the default - all of it rebindable in Preferences ▸ Keybindings unless noted.

Running queries

IntelliSense & editing help

Comments & folding

Find & replace

Selection & multiple cursors

Line operations & clipboard

Cursor movement

Panels & view

Output tabs

Results grid

Tabs, windows & app

A few defaults differ by profile: the SSMS keybinding profile maps Execute Query to F5 only. A handful of app chords (zoom, quit, preferences, output-tab selection) are fixed rather than rebindable; everything in the editor and query tables above can be remapped.

Move between open queries with Ctrl+Tab and a preview that helps you pick the right one.

Once a few query tabs are open, titles alone stop being much help. Hold Ctrl and press Tab for a most-recently-used list with a live preview of the highlighted query. Keep tapping Tab to move through the list, then release Ctrl to land where you need to be. Your last two queries are always one flick apart.

What each entry shows

The switcher has two panes: a compact list of open queries on the left and a preview of the highlighted query on the right.

The preview, top to bottom

1. Title. The engine glyph and the query's name.
2. AI summary. A one-line, plain-language description of what the query does - so you recognise it by intent, not just by filename.
3. Query body. The SQL itself, rendered as text in the editor font, so you can confirm you've got the right query at a glance. Long queries are clipped with a “… N more lines” marker.
4. Run line. How long ago the query last ran and how much it returned - e.g. “Ran 3m ago · 1,240 rows · 2 result sets” - or “Not run yet” for a query you haven't executed.

Turn an execution plan into useful findings, a navigable tree, or a diagram you can follow.

A query plan is the database explaining how it intends to answer your query: which indexes it uses, how it joins, and where the cost goes. SQLly turns that explanation into plain-language findings, an operator tree, and a node-and-edge diagram. One shared model keeps a PostgreSQL plan and a SQL Server plan readable in the same way.

Capturing a plan

Findings - the plan in human terms

The default view isn't a wall of operators - it's a ranked list of findings, worst first. Each one is written in plain language with a summary, a why, and a suggested action - often with ready-to-run SQL you can copy or open in a new tab, plus the technical detail one expand away.

• Table scan - “Scans every row in dbo.Orders to find matches.”
• Missing index - with a generated CREATE NONCLUSTERED INDEX statement.
• Estimate vs actual divergence - “Estimated 10 rows but read 48.2K → update statistics” (actual plans only).
• Implicit conversion, key lookup, spill to tempdb, missing statistics, cross product (no join predicate), row goals, and spools - each with its own explanation and fix.

Below the findings, an Operators list shows every operator most-expensive-first - “Index Seek — 4 rows estimated, 91% of cost, read 7” - with full per-operator detail (node id, physical/logical operator, CPU/IO cost, actual rows, warnings, output columns) on expand.

Tree & diagram

Tree view is the operator hierarchy as an indented, collapsible tree - each row showing the operator, its share of cost, estimated rows, the → actual count (highlighted when it diverges), and a ⚠ warning tally - with keyboard navigation.

Diagram view draws the plan as a top-down node-and-edge canvas. Each node is a box with the operator name, a cost% · estimated rows → actual line, and a cost bar whose length tracks the operator's cost share and turns amber when it carries a warning. Edges are drawn parent-to-child with arrowheads; you can pan the canvas and click any node to select it and see its full detail below - the same selection the tree shares.

Batches, clean plans, and comparison

• Multi-statement batches get a per-statement tab strip - findings stay grouped by statement rather than mixed together.
• Clean plans say so plainly: “This plan looks good. No issues detected.” The Operators list is still there when you want it.
• Comparison mode keeps recent captures and diffs a baseline against a later run - highlighting operators that regressed, improved, or were added/removed - so you can prove a tuning change actually helped.
• An AI explain action hands a bounded digest of the plan to the assistant for a natural-language walkthrough.

Engine support

Every dialect is parsed into the same plan model, so findings - table scans, cost shares, estimate-vs-actual - read consistently no matter which engine produced the plan.

Open an object's definition right from the query instead of going on a tree-hunting expedition.

Reading a query and need to see what an object really looks like? Cmd-click on macOS or Ctrl-click on Windows/Linux to open its definition directly. No tree hunting and no emergency sp_help required. Hold the modifier first and resolvable names underline, so you know what will open.

What you can click

Tables, views, stored procedures, functions, and user-defined types. You can also open the same view from the data-model rows in the open dialog.

What it shows

A read-only, syntax-highlighted definition, with a header naming the object, where the source came from, the database, and the connection:

• Views, procedures, and functions - the server's own stored definition.
• Tables - a CREATE TABLE with columns (type, nullability, identity, collation, defaults) and the primary key, then appended Indexes, Foreign Keys, and Triggers sections. It's labelled “Generated from catalog metadata” when SQLly builds it from the catalog rather than a stored definition.

Each section is best-effort: if one can't be read it appends a -- … unavailable comment instead of failing the whole view. A toolbar gives you Copy and Open as Query - the generated DDL is never dropped into an editable tab unless you ask.

How to configure it

Under Settings › DDL navigation you can enable or disable it, choose the activation modifier, and pick where it opens - a new tab (the default), a side panel on the current tab, or a popup window.

Supported on SQL Server (the fullest - generated tables with index/FK/trigger sections, plus routines, views, and types), PostgreSQL, MySQL/MariaDB, and SQLite.

Find SQL files and database definitions with fuzzy search and a preview before you commit.

Opening SQL should not mean playing hide-and-seek in a stock file panel. SQLly's Open dialog searches your project with the same fuzzy logic as the editor, previews a file before you open it, and can jump straight to a database object's definition.

Two ways to browse

• Folder - walk one directory at a time, with a parent (..) row and an Up button. Choose Root… points it at a new project folder.
• Project SQL - recursively finds every .sql file under the project root at once, each row tagged with the schema and object it defines and whether it was indexed or scanned.

Search that thinks like IntelliSense

The search box uses the same fuzzy matching as code completion, so you type initials and it finds the name: PuOr matches PurchaseOrder, SOH matches SalesOrderHeader, and case never matters. Every whitespace-separated term has to match, so you can narrow quickly.

Prefix a term to scope it to one kind of object:

Preview, reveal, and open

• Syntax-highlighted preview - select a .sql file and its contents render, line-numbered and colorized, before you commit to opening it. Big files preview a slice with a Load Full File button.
• Data-model rows - flip on the DDL toggle and the list also offers your live tables and views; choosing one opens its definition directly.
• Reveal in the OS file browser and Copy Path from the preview pane; toggle Show Hidden to include dotfiles.
• New SQL File… creates an empty query file to start from.

Keyboard throughout: ↑/↓ move, Enter opens the file (or descends into a folder, or opens an object's DDL), and Escape clears the search before it closes the dialog.

Read the answer, shape it for the task, and take it with you when you are done.

A query returning rows is usually the beginning of the work, not the end. The result grid is where you read, reshape, compare, and share the answer. These are the main ways SQLly helps with each result set.

Try the real result grid in your browser, no installation ceremony required.

This is not a mock-up. It is the real SQLly result grid, running in your browser against bundled sample data. Give it a proper poke: sort, resize, scroll, and move between the Grid, Pivot, and Chart tabs just as you would in the desktop app.

Runs entirely in your browser via WebAssembly + WebGPU - it needs a recent Chrome/Edge, Safari, or Firefox with WebGPU enabled, and it never talks to a server. The build loads only when you open this page and unloads automatically the moment you navigate away, so it never sits idle in the background.

This is the grid you'll read every result in - see Formatting, Pivot, and Export for what it can do with real data.

Make numbers, dates, ids, and text easier to scan without changing the data beneath them.

Formatting helps a result set read like an answer instead of a raw data dump. SQLly starts from the column type, then lets you set defaults or make a deliberate per-column exception. Both paths feed the same formatting model:

1. Type defaults. Open Settings › Results to choose how each type appears across SQLly.
2. Per-column override. Right-click a header and choose Set Formatting Override…. SQLly writes a -- sqlly format: directive into the query, so the choice travels with the file.

Numeric and temporal types also share an alignment option (left, center, or right), so it does not need repeating on every page below.

Choose the grouping, sign, and units that make whole numbers quick to read.

For whole-number columns, Settings › Results › Integer holds the choices that make counts, quantities, and large values easier to scan.

Integer grouping always uses a comma. If another thousands character is important, use the Decimal options.

Show the precision, rounding, and currency cues that make fractional values make sense.

For fractional values, Settings › Results › Decimal lets you choose a presentation that matches the people reading the result.

Read dates your way: absolute, relative, or with a format that suits the job.

Dates become much easier to trust when their format and time zone are clear. Set both in Settings › Results › Dates.

Dates use the pattern you choose; there is no relative “2 hours ago” mode. To turn an integer epoch into a date, use an epoch= format override.

Keep long identifiers recognizable without letting them take over the grid.

UUIDs are long enough already. In Settings › Results › UUIDs, choose whether their dashes help readability or simply add noise.

Dashes are the only UUID display option here. To shorten or transform an id, use a Template override.

Tame casing, truncation, and whitespace so text columns stay useful at a glance.

Text arrives as stored, with no one-size-fits-all defaults pane. When a column needs help, right-click its header and choose Set Formatting Override…. The picker keeps its options in three focused tabs.

Template

Use a {value} placeholder with pipe helpers for casing, truncation, padding, and the other small adjustments that make text easier to read:

-- sqlly format: column=code; template={value|upper}
-- sqlly format: column=notes; template={value|trunc:40}

JSON path

Extract a useful leaf from a JSON text column, such as $.customer.name or $.items[0], and provide a fallback when the path is missing.

Number

Apply numeric styling to any column: fixed, percent (×100 with a % suffix), or bytes (B / KiB / MiB / GiB / TiB), with your chosen decimals and separators.

Related: sensitive text can be redacted with a mask= override, which can also gate exports.

Build a cross-tab by moving fields around, then keep the setup as a reusable directive if you like.

Every result grid has a Pivot tab alongside Grid and Chart. Open it to turn a flat result into a cross-tab by moving fields around; the query itself stays untouched.

Building a pivot

The sidebar lists the available columns and four drop zones. Drag a field into the place where it should do its work:

• Rows and Columns - the axes of the cross-tab.
• Values - the measure to aggregate. The value chip carries a dropdown to pick the aggregate; it reads e.g. “Sum of Amount”.
• Filters - restrict which rows feed the pivot, with a per-field value picker.

Choose from Count, Sum, Avg, Min, Max, and First. Layout options add subtotals, grand totals, and flat rows; per-field formatting handles decimals, separators, negative values, and alignment.

Drill down

Double-click a pivot cell to return to the Grid tab filtered to the rows behind it. SQLly labels the view “Filtered from pivot” and provides a one-click Clear filter.

Prefer to keep it in the query? The pivot directive expresses the same cross-tab as a comment - and dragging fields here can write that directive for you.

Edit, insert, duplicate, and delete rows through a form that understands the table you are in.

Right-click a result row and choose Edit Row… to get a form built from the table's metadata, including data types, defaults, nullability, and constraints. It gives you a clear way to inspect and change data without hand-writing every UPDATE.

What you can do

• Edit, insert, duplicate, and delete rows; every write is guarded and parameterized, never string-concatenated.
• Foreign-key fields become searchable dropdowns of real referenced values, so you can choose a customer by name rather than guess an id.
• CHECK constraints are checked in the form before a save leaves the app.
• Related rows are one click away in their own tab.

Commit now, or stage your changes

Save one edit immediately, or stage edits, inserts, and deletes to commit together in one transaction with a generated rollback script alongside. Staged saves use the same safety gates as normal queries: a read-only or production connection blocks the write until you unlock it, and an AI-reviewed connection asks for that review before committing.

Row edits reuse the connection's live authentication, so a token-authenticated (Entra) connection edits with the same freshly-minted token it queries with.

Send results onward in the format the next person or tool will actually appreciate.

One Export… command, from the grid menu or toolbar, opens a single dialog for any result set. Pick a format, choose Copy to clipboard or Save to file…, and you are done. Standard data formats and programming-language generators live together, and unused formats can be hidden in Settings › Results › Export.

Every example below exports this small two-row result set:

SELECT id, customer, amount, created FROM orders;
-- id | customer | amount  | created
--  1 | Acme     | 1250.00 | 2026-09-01
--  2 | Globex   |  890.50 | 2026-09-02

Standard formats

id,customer,amount,created
1,Acme,1250.00,2026-09-01
2,Globex,890.50,2026-09-02

id	customer	amount	created
1	Acme	1250.00	2026-09-01
2	Globex	890.50	2026-09-02

[
  { "id": 1, "customer": "Acme", "amount": 1250.00, "created": "2026-09-01" },
  { "id": 2, "customer": "Globex", "amount": 890.50, "created": "2026-09-02" }
]

{"id":1,"customer":"Acme","amount":1250.00,"created":"2026-09-01"}
{"id":2,"customer":"Globex","amount":890.50,"created":"2026-09-02"}

| id | customer | amount  | created    |
| -- | -------- | ------- | ---------- |
| 1  | Acme     | 1250.00 | 2026-09-01 |
| 2  | Globex   | 890.50  | 2026-09-02 |

<table>
  <thead><tr><th>id</th><th>customer</th><th>amount</th><th>created</th></tr></thead>
  <tbody>
    <tr><td>1</td><td>Acme</td><td>1250.00</td><td>2026-09-01</td></tr>
    <tr><td>2</td><td>Globex</td><td>890.50</td><td>2026-09-02</td></tr>
  </tbody>
</table>

<rows>
  <row>
    <id>1</id>
    <customer>Acme</customer>
    <amount>1250.00</amount>
    <created>2026-09-01</created>
  </row>
  <row>
    <id>2</id>
    <customer>Globex</customer>
    <amount>890.50</amount>
    <created>2026-09-02</created>
  </row>
</rows>

INSERT INTO orders (id, customer, amount, created) VALUES
  (1, 'Acme', 1250.00, '2026-09-01'),
  (2, 'Globex', 890.50, '2026-09-02');

CREATE TABLE #orders (
  id        INT,
  customer  NVARCHAR(4000),
  amount    DECIMAL(18,2),
  created   DATE
);
INSERT INTO #orders (id, customer, amount, created) VALUES
  (1, 'Acme', 1250.00, '2026-09-01'),
  (2, 'Globex', 890.50, '2026-09-02');

VALUES
  (1, 'Acme', 1250.00, '2026-09-01'),
  (2, 'Globex', 890.50, '2026-09-02')

Programming formats

These generators emit ready-to-paste source code that embeds the result rows as data - handy for fixtures, seed data, and quick scripts. One example per language:

var rows = new[]
{
    new { Id = 1, Customer = "Acme", Amount = 1250.00m, Created = "2026-09-01" },
    new { Id = 2, Customer = "Globex", Amount = 890.50m, Created = "2026-09-02" },
};

rows = [
    {"id": 1, "customer": "Acme", "amount": 1250.00, "created": "2026-09-01"},
    {"id": 2, "customer": "Globex", "amount": 890.50, "created": "2026-09-02"},
]

struct Order { id: i64, customer: &'static str, amount: f64, created: &'static str }

let rows = vec![
    Order { id: 1, customer: "Acme", amount: 1250.00, created: "2026-09-01" },
    Order { id: 2, customer: "Globex", amount: 890.50, created: "2026-09-02" },
];

const rows = [
  { id: 1, customer: "Acme", amount: 1250.00, created: "2026-09-01" },
  { id: 2, customer: "Globex", amount: 890.50, created: "2026-09-02" },
];

interface Order { id: number; customer: string; amount: number; created: string; }

const rows: Order[] = [
  { id: 1, customer: "Acme", amount: 1250.00, created: "2026-09-01" },
  { id: 2, customer: "Globex", amount: 890.50, created: "2026-09-02" },
];

data class Order(val id: Int, val customer: String, val amount: Double, val created: String)

val rows = listOf(
    Order(1, "Acme", 1250.00, "2026-09-01"),
    Order(2, "Globex", 890.50, "2026-09-02"),
)

struct Order { let id: Int; let customer: String; let amount: Double; let created: String }

let rows = [
    Order(id: 1, customer: "Acme", amount: 1250.00, created: "2026-09-01"),
    Order(id: 2, customer: "Globex", amount: 890.50, created: "2026-09-02"),
]

record Order(int id, String customer, double amount, String created) {}

List<Order> rows = List.of(
    new Order(1, "Acme", 1250.00, "2026-09-01"),
    new Order(2, "Globex", 890.50, "2026-09-02")
);

type Order struct {
    ID       int
    Customer string
    Amount   float64
    Created  string
}

rows := []Order{
    {1, "Acme", 1250.00, "2026-09-01"},
    {2, "Globex", 890.50, "2026-09-02"},
}

$rows = [
    ['id' => 1, 'customer' => 'Acme', 'amount' => 1250.00, 'created' => '2026-09-01'],
    ['id' => 2, 'customer' => 'Globex', 'amount' => 890.50, 'created' => '2026-09-02'],
];

struct Order { int id; std::string customer; double amount; std::string created; };

std::vector<Order> rows = {
    {1, "Acme", 1250.00, "2026-09-01"},
    {2, "Globex", 890.50, "2026-09-02"},
};

The exact field names, types, and value quoting follow the result's columns and your connection's dialect - the samples above are representative. Any format you don't use can be hidden under Settings › Results › Export.

Put two result sets side by side and see what changed without doing row-by-row detective work.

When the question is "what changed?", put two result sets together and let SQLly answer it plainly. Rows are marked added, removed, or unchanged, and schema mismatches are called out rather than quietly producing a misleading comparison.

Capture a query before and after a change, then compare the two runs to prove what moved. No spreadsheet export, no side-by-side squinting.

Open JSON or XML cells as tidy, explorable structures instead of a wall of punctuation.

JSON and XML deserve better than being squeezed into a grid cell. Open either in a structured, pretty-printed viewer, then expand only the branches you need until the field you came looking for is right in front of you.

Describe a transformation once, then let SQLly apply it across the columns that need it.

Repeating the same transformation across thirty columns is a fine way to lose an afternoon. This planned templating language will let you describe the change once and apply it consistently, keeping result shaping readable and repeatable.

Give multiple result sets the layout that makes the comparison or review easy.

A query can return several result sets at once, and the useful layout depends on what you are comparing. Choose one from the grid's Layout submenu; the toolbar toggle moves quickly between Tabbed and Stacked.

Keep the workspace calm by looking at one result set at a time.

Tabbed is the default for a reason: each result set gets a tab and only the active one is visible. It is the calmest choice when you are focused on one answer at a time.

Switch to it from the grid's Layout submenu, or flip between Tabbed and Stacked with the layout toggle in the toolbar and results chrome. Your choice is remembered per editor tab when session resume is on.

Keep every result in view on one scroll when the whole batch matters.

Stacked keeps every result in one scroll as a resizable, collapsible card. It is useful when several sets need to stay in view together: collapse the finished ones and keep moving.

Each card has its own collapse control and an inline clear affordance; drag a card's edge to resize it. Reach it from the Layout submenu or the toolbar toggle.

Arrange result panes freely when the answer is easier to understand side by side.

Canvas lays result sets onto a grid you define with comments. It is for dashboard-style queries where a summary belongs in one place and detail sets belong somewhere else.

Placing result sets

Declare the grid size, then give each result set a cell:

-- sqlly 4x2
-- sqlly result: row:1 col:1
SELECT ...;   -- lands in the top-left cell

-- sqlly result: row:1 col:2
SELECT ...;   -- next cell across

SQLly builds the board from the result sets and directives, and flags placement problems, such as two sets claiming the same cell, directly in the editor.

Revisit recent results without rerunning a query just to see what happened last time.

Run a query, run another, and the first answer is still nearby. SQLly keeps a cache of recent runs, including the result rows and exact SQL, so you can revisit a previous result without executing it again.

The run history strip

After more than one run, a strip of chips appears above the results. Current holds the live run; retained runs appear newest first with time, row count, and elapsed time, such as “14:32 · 1,240 rows · 84 ms”. Select a chip to view that run read-only, return with Current, and pin or close each retained run as needed.

What's cached per run

• The SQL text that produced the run.
• The result set(s) - columns and the actual rows.
• Row counts, rows-affected, elapsed time, and completion time.

How many, and what's kept

• How many runs - default 5, adjustable from 0 to 20 in Settings › Results, with a master on/off switch.
• What counts as a new run - a capture mode controls whether a run is retained when the query changed, when the results changed, on either (the default), or only on both.
• Eviction - the oldest un-pinned run drops off once you exceed the limit or the memory budget.
• Pinning - a pinned run is protected from eviction. Pin the run you want to keep comparing against. If every retained run is pinned and the strip is full, SQLly hints to unpin one so history can stay bounded.
• Scope - history is per editor tab; each query tab keeps its own runs.

Related: Layouts for arranging the sets a run returns, and Export to get any run's rows out.

See which engines SQLly can connect to today and how it keeps their differences from getting in your way.

SQLly understands 30 database engines. Twenty connect today through native Rust drivers, grouped around the four wire protocols those engines actually speak. The remaining ten are fully profiled: SQLly knows their capabilities, quoting, row limits, and type storage, with live connectors still to come.

Connect today - native drivers

Wire-compatible engines share a driver: PostgreSQL-protocol engines use the PostgreSQL connector, and the MySQL family shares MySQL's. Compatibility stays explicit, so a hosted or distributed engine says which first-party wire it uses.

TDS - SQL Server family

PostgreSQL wire

MySQL wire

In-process file

Modeled - drivers on the way

These engines are fully described in the capability model, so SQLly can generate their SQL, quoting, and type mappings. They do not yet have native connectors, which means a live connection from the app is not available today.

One intent, per-engine SQL

Because engine rules live in the model, one UI action can render the right dialect wherever you run it. Row limiting is a familiar example: “view top 1000 rows” becomes:

The same per-engine handling covers identifier quoting, string, boolean, and binary literals, upserts (ON CONFLICT, ON DUPLICATE KEY, or MERGE), and how all 15 logical types map to native storage.

Related: the Rust engine that runs all of this, and Connection Organization for grouping the databases you connect to.

Tools that help SQLly explain your database in plain language without pretending it knows more than it does.

A schema can tell you what a column is called; it cannot always tell you what the column means. SQLly's intelligence work is about closing that gap carefully. The live value-aware completion features are under IntelliSense › Data awareness; this section covers the next layers taking shape.

Get a plain-language preview of a query from a model you control, before you have to parse every clause yourself.

Before you run a query, it helps to know what it is about to do in ordinary human language. SQLly's summary bar is built for that quick confidence check; the UI, per-query preferences, and saved metadata are ready while generation backends are still being connected.

Use a local model through Ollama or the MLX sidecar on Apple Silicon, or deliberately opt into a cloud provider such as OpenRouter, OpenAI, or Claude. No cloud, no API key, and no data leaving your laptop unless you choose it.

Trace an unexplained value through DDL and leave behind a useful note for the next person, possibly future you.

Found a mystery code in a result set? When SQLly can follow it through DDL introspection, it can leave an inline note explaining where the value came from, so the query answers a little more of its own trivia.

SELECT status /* ← enum: orders.status_id → status_codes.code */

Search across your schema and data by intent, not only by the exact SQL words you happen to remember.

You should be able to search for the idea in your head, not only the exact table name you happen to remember. Planned grep-ai-style semantic search will help you find the relevant table, column, or row from a simple fuzzy query.

Bring live databases, local DDL, work in progress, and Git context into one useful picture.

A live database is the truth today, but it is rarely the whole story. Start there, then layer in local files, work in progress, and Git history to explore the schema as it is heading, with the uncertainty kept visible.

Layer local files over the live database so the model can include the changes you are actively shaping.

Keep the live database as the baseline, then bring your checked-in DDL along for the ride. Where the engine exposes modification times, SQLly compares them with local files and uses the newer file for that table, view, procedure, function, or query in the overlay.

• A real-time local file overlay for Git-based schema management.
• Work against checked-in DDL before it is deployed.
• The query can still fail against the live database until the schema catches up. That distinction stays explicit; the overlay is helpful, not make-believe.

Get help from rough DDL before it is valid enough to deploy; SQLly keeps that uncertainty visible.

A DDL sketch does not need to be deployment-ready before it can be useful. SQLly can read a clearly unfinished definition and overlay its best interpretation on the real schema, without presenting that interpretation as fact.

That means help with column names, keys, indexes, and data types before the model is valid. SQLly tracks the material as an incomplete region with its own provenance and confidence, so you always know what is solid and what is still a well-informed draft.

Help foreign keys show the human-friendly value behind the id, not just another opaque number.

Foreign keys are useful to the database but not always kind to human eyes. SQLly uses DDL introspection to identify the likely human-friendly display value for each relationship. The row editor already offers searchable referenced values; bringing those names into the grid is the remaining work.

Bring Git timing and authorship into the overlay when the history is part of the answer.

Filesystem timestamps are not always the best historians. The overlay will also use Git modification times, so it can pick the right version even when a file's mtime tells a less useful story.

It will also offer live database DDL git blame with notes: hover an object to see who changed it, when, and why.

Type the name you know; SQLly can add the join and make sure the comparison still means what you intended.

Looking for a value hidden behind a foreign key? Type the name you know. SQLly will add the relationship it needs and compare against the readable value, saving you a round of manual JOIN gymnastics.

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.

These policies combine with environment defaults - Production, for instance, forces read-only and rollback-wrap on automatically.

Make a connection genuinely read-only when browsing is all it should ever do.

Make a connection truly read-only: SQLly blocks everything except SELECT. It is a good fit for a replica, an analyst-facing environment, or any server that should never be at the mercy of a stray script.

Put non-read work inside a transaction you can inspect and roll back before it becomes permanent.

With auto-wrap on, anything beyond a plain read runs inside an outer transaction. You get a chance to inspect the result and roll it back before a change becomes permanent.

Ask for an unmistakable "yes, really" before a non-SELECT statement gets to run.

Ask for an explicit “yes, really” before a non-SELECT statement runs. It takes a half-second and can save the moment when a production query was meant for staging.

Catch, warn about, or block broad UPDATE and DELETE statements before a tiny omission becomes a very long afternoon.

Before a batch runs, SQLly checks for UPDATE and DELETE statements without a WHERE clause. It masks strings and comments first, so a keyword inside a literal does not create a false alarm. Connection policy can warn about these statements or block them outright.

DELETE FROM orders  → ⚠ affects every row

Give production the visual warning it deserves so your peripheral vision can save the day.

Give clients, projects, environments, and servers their own colors and icons. The point is simple: your peripheral vision should notice production before your hands get a chance to make it exciting.

Colors are set on connection organization entities and surface as badges in the explorer and status bar.

Ask for a plain-language read on a query's side effects before it runs in a protected place.

In a protected context, require a plain-language review of a query's side effects before it runs. SQLly already detects and gates the work, and the review dialog makes the stakes unmissable with its WE WILL MAKE UPDATE AND DELETE CHANGES. warning. The on-device model that writes the explanation is still being connected.

Uses the same on-device model plumbing as query summarization.

Use your operating system's identity check where a mistake would be expensive, and leave routine work alone.

Use the identity check your operating system already knows how to do - Touch ID on macOS and Windows Hello on Windows - only where an extra pause is worthwhile. The underlying safety policy is already in place; the native identity prompts are still on their way.

Require an OS-native identity check before SQLly opens a connection that deserves extra care.

Require an OS-native identity check before SQLly will even open a connection. Apply it to one sensitive server or an entire client's production environment; the hierarchy does the repetitive part for you.

# inherits down the tree, override anywhere
client:    Acme Corp   identity=connect
env:       prod        identity=connect
server:    db-01.prod  identity=inherit

Keep reads frictionless; ask for verification before an action with real teeth.

Reads stay easy. When a statement is not a plain SELECT - an INSERT, UPDATE, DELETE, DROP, TRUNCATE, or other DDL - SQLly will ask you to verify first. Statement classification already knows which operations need that pause; the native prompt is the remaining piece.

SELECT * FROM orders        ✓ runs
UPDATE orders SET …         ☝ identity check required

Set identity rules at the level that makes sense and let them follow the connection hierarchy.

Identity rules use the same multi-dimensional hierarchy as the rest of connection policy. Set one on a client and its projects, environments, and servers inherit it until you deliberately change a branch.

Lock down production with one switch, then make a deliberate exception for a read replica if you need one. No copy-pasting the same rule across fifty connections.

Decide whether verification happens for every statement, every session, or somewhere comfortably in between.

Choose how long a verification remains valid. Ask for it on every statement for the most sensitive targets, or once per session / N minutes for friendlier ones. It is your production environment; you get to set the comfort level.

Keep a local, tamper-evident record of who verified a gated action, where, and when.

Every gated action records who verified, which statement, which target, and when. The result is a local, tamper-evident audit trail for the inevitable question: “who ran that against production?”

Use the device passcode or OS sign-in when biometric hardware is unavailable or simply not your thing.

No biometric hardware, or a sensor having a bad day? SQLly can fall back to your device passcode or OS account sign-in. A gate should be a deliberate pause, not a lockout, and SQLly explains why it appeared before you approve it.

Keep connections and their schema close at hand, organized for the way you think about your work.

Server Explorer is the tree on the left: connections at the top and a live view of schemas, tables, views, procedures, and more beneath each database. You decide how to group connections and arrange objects, while a local cache keeps the whole thing quick to open.

The header's overflow menu holds the grouping choices plus Manage Connections, Collapse All, and Refresh. Most of the tree's organization is configured in Settings › Data Model › Server Explorer.

See connections flat or grouped by client, project, environment, or server when a longer list needs a little order.

The explorer starts as a flat list. Use the header's overflow menu to switch the grouping view and arrange connections around the dimension that is useful right now.

Group folders are alphabetical with “Unassigned” pinned last. Each carries the matching entity color and icon, so a client's group looks familiar wherever it appears.