SQL Tooling in 2026: What the Download Numbers Actually Show

Every "state of SQL tooling" post I read is built on a survey. Surveys ask developers what they use, and developers answer with what they meant to adopt. This page uses a different source: the npm downloads API, which counts what CI machines actually installed. It is not a measure of people — a package pulled by every container in a build farm counts every time — but it is honest about direction, and direction is the useful part.

The window below is 2024-10-01 to 2026-10-10. "Month" means the first and last 30 full days inside that window. The figures are monthly totals, and each one matches the single-day point/last-month endpoint when cross-checked, so they are reproducible rather than remembered.

The formatter and parser both roughly quintupled

For context, prettier — the biggest formatter in the ecosystem by a wide margin — went 176.1M → 615.4M, +249%, in the same window.

Two things worth pulling apart here, because it is tempting to read the headline wrong.

First, this is not evidence that more people write SQL. A formatter going up 659% while the general-purpose formatter market goes up 249% says SQL formatting is catching up to a formatting norm that JS and JSON already live inside. The shape of the change matters more than the number: the whole ecosystem inflated, and SQL tooling inflated harder within it. Something is filling a previously-unfilled niche, not just riding a wave.

Second, the parser growing faster than the formatter is the more interesting signal. A formatter is a cosmetic dependency; you can skip it forever and nothing breaks. A parser is a structural commitment — you reach for it when you need to transform SQL, not just print it. When parse-time dependencies outgrow print-time ones, that usually means tooling is moving upstream: formatters embedded in editors, migration diff tools, linters that run in CI, agents that rewrite queries rather than just reformatting them. I'd expect the parser line to keep outpacing the formatter line for that reason.

One honest caveat on my own methodology: sql-formatter is a transitive dependency of a lot of editor plugins and higher-level tools, so part of its growth belongs to things built on top of it rather than to someone choosing it directly. I can't separate those with this API, and I'd rather say so than attribute it all to taste.

Where a browser tool sits in that picture

This site is keyword-anchored and has no parser, which is the opposite architectural choice to the fastest-growing package above. That's worth explaining rather than burying, because it defines what this page can and can't do for you — and it's covered in detail on the gotchas page.

Short version: a formatter that understands SQL can promise it won't change your query's meaning. A formatter that pattern-matches keywords is faster, tolerates garbage input, runs in 40 KB of JavaScript with no server, and cannot promise anything at all. For a production migration I want the promise. For pasting a query out of a log at 2 a.m. I want the speed, and I'll read the result with my own eyes.

The adjacent numbers, for pattern recognition

The SQL-specific trend is easy to over-read on its own. Wider, so you can tell how much is SQL and how much is "everything that gets run through a formatter":

Two patterns I'd act on:

Rust-in-the-backend is eating the parsers. lightningcss is a CSS parser written in Rust; its ~130× is the single largest move in this table, and the interesting part is how it grew — by being fast enough to be vendored wholesale into other tools rather than chosen by end users. When a low-level dependency grows faster than anything built above it, the tools above it are silently swapping internals. Expect the same pressure on SQL: a fast native parser underneath an editor is a different product from a slow one, and it changes which features are affordable.

Repair is a real category now. jsonrepair at +14.9× measures a specific pain: things that are almost JSON. LLM output, truncated API responses, hand-edged config files, log lines with commas in them. The fact that a repair library grew ~15× while a validator-shaped ecosystem grew ~3× tells you the average input got messier, not that people got clumsier. SQL has exactly the same failure mode — a missing comma from a copy-paste, a dropped paren — and it's why this page's minifier is defensive about unterminated strings instead of throwing.

The counter-example is the useful one: stylelint grew "only" +144%. It is not the slowest row here — axios is, at +125% — but an HTTP client grows with every program that talks to a server, which makes it closer to a tax on networked code than a signal about SQL. Among the tools whose job is to judge rather than transform, stylelint is the floor. Lint-adjacent tools grow with the number of projects, not with the number of generated files. Generation-heavy tooling — formatters, parsers, repair utilities, ID generators — grew +249% to +130×. Lint grew 122%. Whatever you think caused that, it is the sharpest signal in the table, and it points the same direction as the parser number above.

What I'd actually do with this

• If you write SQL in a team: put a real formatter in pre-commit, not on a website. sql-formatter has a CLI, pre-commit.com exists, and the argument for either is the same: reviewers should not be reading formatting diffs. The website stays useful for the one-off paste, which is most of what I personally use it for.
• If you build developer tools: buy the parser, don't write one. The +15.1× on node-sql-parser is a market telling you the boring version is solved. Spend your effort on the transform layer above it, which is where the unsolved problems are.
• If you're deciding whether to adopt formatting at all: the number that should convince you isn't in this table. It's that formatting is now cheap enough that "we don't need it" costs more than the setup.

Numbers pulled from the npm downloads API on 2026-10-11, 30-day windows, cross-checked against the point/last-month endpoint. Download counts are installs, not users — read them as direction, never as audience size.