SQLlyWrite the query. Trust the answer. Get it out.
You don’t need to know what a generation counter is to get value out of SQLly. This guide covers the three things you actually do all day: writing queries without fighting the editor, reading results without squinting, and exporting data without a second tool.
Find your tables before you write a line of SQL
The Servers panel on the left groups every connection the way you actually think about your data - not just by hostname.
The Servers panel, an empty query tab, and the results pane - the three panes you’ll live in.
Client, project, environment, or raw server
Flip between grouping modes across the top of the panel - None, Client, Project, Env, Server - so a scattered list of hostnames turns into “Acme Corp → Reporting → Prod.”
One tab per train of thought
Every query lives in its own tab with its own server and database selection, so a quick lookup in one tab never bleeds into the report you’re building in another.
Your tabs come back
Close SQLly, reopen it, and your open tabs - query text, layout, everything - are exactly where you left them. Nothing to save, nothing to lose.
Autocomplete that knows your data, not just your schema
Most SQL editors autocomplete table and column names. SQLly goes one level deeper.
Keyword and clause completion shows up as you type - no manual trigger.
Autocomplete for column values
Start typing inside a WHERE clause and SQLly suggests real values pulled from that column’s actual data - filtered live as you keep typing.
-- as you type, it filters live WHERE CompanyName = 'Acme␣' ⟶ Acme Corp, Acme Labs…
Type the name, not the key
Hunting for a row behind a foreign key? Type the human-readable name you’re actually after - SQLly resolves it and wires up the join, so you’re not hand-writing JOINs just to filter by customer name.
It still helps on a half-finished schema
If a table’s definition is still rough - a teammate’s draft migration, a sketch that doesn’t fully parse yet - SQLly overlays its best guess and keeps completions coming instead of giving up.
See names, not IDs, in results
Where SQLly can figure out the natural “display value” for a foreign key, it shows you Acme Corp in the grid instead of customer_id = 4827 - configurable per column when it guesses wrong.
A result grid built for actually reading the data
Large result sets stay smooth because SQLly only renders the rows on screen - it doesn’t choke rendering 500,000 rows into the DOM at once.
Clean syntax highlighting for the query you actually wrote - keywords, functions, and identifiers in distinct colors.
Smooth scrolling, even on big result sets
The grid is virtualized - it only ever renders the slice of rows currently on screen, so paging through a six-figure result set feels the same as paging through ten rows.
Results come back in pages, not all at once
SQLly pages large result sets instead of trying to hold everything in memory at once, so a query that returns way more than you expected doesn’t stall the whole app while it streams in.
Format columns the way your team reads them
Set per-column formatting preferences - money, rounding, date shape - once, from the Preferences panel, instead of wrapping every query in FORMAT() calls.
Pivot results with a comment
Annotate the query and SQLly reshapes rows into columns right in the result grid - no wizard, no export to a pivot tool.
--! pivot rows=region cols=quarter value=revenue
Edit a row without writing UPDATE by hand
Right-click any result row and SQLly builds a per-column edit form from the table’s own metadata - types, defaults, and constraints included. Edit, insert, duplicate, or delete rows with guarded, parameterized writes, and jump to related rows in their own tab.
Read JSON and XML, not a wall of text
Cells holding JSON or XML open in a structured, pretty-printed viewer you can expand and collapse - instead of a single unreadable line crammed into a grid cell.
Arrange multiple result sets your way
Stop scrolling through result sets stacked one after another. Switch between tabbed, stacked, and free-form canvas layouts - or set rows and columns from a comment (-- sqlly 4x2) so several sets land where they make sense.
Export in whatever shape the next step needs
The report is rarely the query result itself - it’s a spreadsheet, a Slack message, or a migration script. SQLly exports straight into all of them.
CSV, TSV, JSON, Markdown, HTML
Pick the shape that matches where the data is going next - a spreadsheet, an API payload, a README table, or a quick paste into a doc.
Straight to XLSX
Export directly to an Excel file when “send me the numbers” means an actual spreadsheet, not a CSV someone has to reformat.
Copy results as INSERT statements
Need to hand a developer a handful of rows to seed a test environment? Export the result set as ready-to-run INSERT statements instead of a CSV they have to reformat by hand.
Diff two result sets
Ran the same query before and after a change? Compare the two result sets and see exactly which rows were added, removed, or left alone - schema mismatches get called out, not silently mis-compared.
You shouldn’t have to think about performance. You won’t.
Autocomplete doesn’t wait on your database
SQLly keeps its own model of your schema in memory and refreshes it in the background, so IntelliSense stays instant even against a large or slow server - it’s not sending a live query to the database every time you type a letter.
It only re-checks what actually changed
Instead of re-scanning your entire schema on every keystroke, SQLly tracks what changed and re-validates just that - which is why it stays snappy even on databases with thousands of objects.
That’s the whole workflow.
Connect, write a query with real help, read the results without a headache, export it wherever it needs to go. No fourteen-step onboarding required.