Why SQLly

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.