Platform

How SQLly is built: the layers, the crates behind each one, and the tests that keep them honest.

SQLly is a Rust workspace: every layer of the product, from the SQL tokenizer to the interface you type into, is a crate under client/. The work is arranged so the same core can serve the desktop app, the browser preview, the language server, and the CLI engine - and so each layer can be tested on its own.

Three ideas hold it together

• The UI is a face, not the product. The real logic - tools, editing, plans, exports, safety - lives in a headless service layer with no interface attached. The desktop app, the WebAssembly preview, the CLI, and the MCP server call the same code, so a feature cannot behave one way in one of them and differently in another.
• SQL knowledge lives in one place. One statement model, one tokenizer, one set of dialect rules, shared by completion, the formatter, the safety gates, and the language server. It is why a change to how SQLly understands a statement improves all of them at once.
• The engine can be somewhere else. Database work speaks a compact binary protocol over a transport, which is what lets the same path run in-process, in a subprocess, or across an encrypted relay to a bridge inside your network - without the layers above knowing which.

This section is here because “it feels fast” and “it seems careful” are claims, and claims should be checkable. 7,413 tests run against these crates; the per-crate breakdown is on The crates.

In this section

• How the app is built — One Rust workspace, a native GPU interface, a headless service core, and an engine subprocess - and how the pieces talk.
• The crates — All fifteen crates with what each one does, what lives inside it, and how many tests stand behind it.