SQL Libraries in 2026: The Parser Nearly Vanished, the Formatter Grew 659%

Most SQL advice is about which ORM to adopt. The install record is measuring something less flattering and more useful: which packages end up in package.json because a tool needed them.

Data comes from the npm downloads API — window 2024-10-01 to 2026-10-10, pulled 2026-10-12, first 30 days against last 30. Change the package name at the end of that URL to re-check any number here.

The table

Installs, not queries run, and not users. All figures are my own pulls.

Drivers are beating the abstraction

pg at 262.4M and mysql2 at 68.48M are the two largest rows, and both are things you use when you have given up on an ORM generating the query you want. pg grew +890% against knex's +211% — a 4× slope difference between "talk to the database" and "build the query for me."

drizzle-orm complicates that reading and I would not pretend otherwise: +51.6× is the fastest growth of any large row here, and it is an abstraction. The reconciliation I can defend is that Drizzle's pitch is close-to-SQL with types, not Active Record — so it can grow and the drivers can grow, because both are reactions to the same thing: query generation with an escape hatch. The loser in that story is the schema-magic ORM, and there is no row for it on this page because the packages that made that argument famous are not what these numbers are tracking.

SQLite is the quiet story. better-sqlite3 +15.8× and sql.js +51.3×. Two packages whose entire premise is "a database with no server," growing faster than every client-server driver on the page except Drizzle. Local-first tooling, agent memory, desktop apps, and test fixtures all want a file rather than a connection string. sql.js is the SQLite compiled to WebAssembly — a database in a browser tab — at 12.82M installs a month.

The row that makes this site's point

sql-formatter went 2.797M → 21.24M, +659%. Formatting SQL is not a feature anybody's roadmap asks for; it is what happens when a query survives being written once and starts being read — in review, in logs, in an error message pasted into a chat.

node-sql-parser at +15.1× (0.65M → 9.8M) is the same pressure one level down. Formatting needs a parse tree; linting needs one; "explain what this query does" needs one. When a formatter's adoption grows sevenfold and a parser's grows fifteen, the market is not buying prettier queries — it is buying SQL as data, which is what a formatter, a linter, a diff, and a code generator all consume.

I have a bias here: this site formats SQL in the browser. The data does not know which of my pages it is validating, but it is measuring the thing that page exists for.

Choosing

• You know SQL and want it executed: pg or mysql2. The largest rows are the largest for a reason — they are the layer that does not get in the way.
• Types without a learning curve: drizzle-orm. Growth says the market agrees; growth does not say it is right for your team's size.
• Embedded, local, or in-browser: better-sqlite3 for Node, sql.js where you cannot ship a native binding. sql.js is WASM-transpiled SQLite and pays for that portability in speed and memory.
• Migrations across several engines: knex. Slowest-growing builder here, still +211%, and the maturity is the point.
• Just make the query readable: sql-formatter, which is what this site does without installing anything.

What these numbers cannot tell you

• drizzle-orm's base was tiny. +51.6× from 2.174M is a real surge, but multiples off small numbers flatter; compare 112.1M against pg's 262.4M before concluding an ORM has caught a driver.
• node-sql-parser supports a dialect subset, so its 9.8M measures interest in parsing SQL, not the parser's coverage of your query. Check its README before building on it.
• Downloads are not queries. A CI runner installing pg forty times is not forty queries and not one user.

Related

• SQL trends 2026 — the wider adoption picture
• SQL formatter alternatives — offline and editor-based options
• SQL best practices — the rules a formatter cannot enforce