The Best-Maintained Category on This Site, and Why That Is a Problem

Download counts tell you how many people pull a package. They cannot tell you whether anyone is still home. This page measures the second thing, and in the SQL category it says something different from every other category here.

Every metadata cell is the registry's own value for the package's latest dist-tag, read on 2026-10-13 from registry.npmjs.org/<pkg>. Ages are stated against that fixed date and never as "X days ago", because a relative cell is true the day it is written and wrong every day after. Download cells are the published window 2024-10-01 to 2026-10-10 (first 30 days against last 30), pulled 2026-10-12 — same numbers as the libraries page.

The ten packages, as the registry has them

Nothing here is stale, and that is the finding

Count the packages whose latest release is more than a year old: zero. The oldest latest in this table is node-sql-parser at 2026-01-12, 274 days, and five of the ten shipped inside 30 days of the measurement date. Compare the JSON set, where the biggest package last shipped in 2022, or the HTTP clients, where 913M monthly downloads sit on a 2023 release. (Both are covered by the same maintenance measurement on their own sites; each app is a separate domain, so there is no link to give you here.)

Every one of these ten is also growing hard, from +211% to +890%.

So the normal failure mode of this page's argument — "nobody will fix it" — does not apply here. What applies instead is its inverse, and for database code the inverse is worse:

If everything is actively releasing, everything is able to change under you this quarter. For a UI library that means a restyle. For a driver it means connection semantics, transaction boundaries, or how a NULL arrives in your result object.

The rows that carry real weight

pg: +890% growth — the largest multiple in the table — with one publish account and six runtime dependencies. It released 2026-09-30, 13 days back, so it is maintained. It is also the package through which most Node Postgres traffic now flows, at 262.4M downloads a month, and its maintainer count is 1. A fresh date and a single credential are not contradictions; prettier has 11 accounts and postcss has one while shipping 1.342B.

mysql2: released 2026-10-13, the day this was pulled, one publish account, seven dependencies, +476%. Same profile, one day fresher, and the dependency weight matters more than it looks — the driver is the module every query passes through, and whatever it pulls is now in that path.

knex is the table's counter-example: the most maintainers (5), the oldest release (109 days), and the heaviest tree by far (14 dependencies). Team size and freshness move independently of dependency weight, and knex gets the worst score on the axis that actually determines what breaks in a release: how much other code has to be right for it to work.

drizzle-orm is the one to watch: 4 maintainers, zero dependencies, released 2026-10-08, and +51.6× growth — 2.174M to 112.1M. It is the healthiest cell on the page and the least proven at that volume, which is the combination that gets adopted fastest and audited least. A query builder is not a neutral dependency; the ORM-generated SQL it emits is where the surprises live, and +51.6× means a lot of people are learning where, right now.

Why "actively maintained" is the wrong thing to check

The question these cells can answer is narrower than the one people ask with them, and it is the one worth asking: who would fix it, and when did they last have to.

This table answers the first half strongly and the second half in an unsettling way. Nobody here has gone quiet — but a package that ships every two weeks has also had twenty chances to change what SELECT gives back. The minify page on this site documents a real instance of exactly that shape: a formatter's reasonable default quietly altering the semantics of the input.

The mitigation is the same one that has always worked and is unfashionable: pin exact versions, and upgrade deliberately. Five of these ten shipped inside 30 days. A floating range across a driver, a query builder, and a formatter means three independent ways for your build to change meaning between Monday and Friday, none of which is a breaking-version headline you would notice in a changelog skim.

Zero dependencies is the other clean property in this table and it is rarer than in the JSON category: drizzle-orm, nanoid, papaparse, and sql.js have nothing below them. Those four cannot be broken by anyone else's release.

What this does and does not prove

A release date is a fact; what it implies is not.

npm's maintainer count measures publish access, not effort — one account can sit behind a hundred committers, and knex's 5 may be a roster that never reviews. pg reading 1 at 262.4M monthly is an organisational fact, not a risk rating. And zero dependencies is a genuine supply-chain property, not a quality score; sql.js is a WASM build, which is its own category of "nothing below it but something inside it".

What the dates do establish is narrow and useful: this category has no abandonment problem. So spend your maintenance attention somewhere else — on the pinning discipline, and on the four packages here that combine a single publish account with real weight: pg, mysql2, better-sqlite3, node-sql-parser.

Related: SQL libraries in 2026, ORM-generated SQL gotchas, SQL alternatives, SQL migration safety, Postgres vs MySQL dialects.

Metadata came from registry.npmjs.org on 2026-10-13 and is re-checked cell-by-cell by scripts/verify-registry-meta.mjs. Download cells are verified by scripts/verify-npm-figures.mjs against the window above. Ages were computed against the fixed date 2026-10-13, not against "today". Prose readings ("load-bearing", "unsettling", "healthiest") are argument, not measurement, and the verifier deliberately leaves them alone.