Drizzle ORM - TypeScript ORM for SQL Databases

Drizzle ORM calls itself a “Headless ORM for NodeJS, TypeScript and JavaScript” and makes an unusually checkable claim about its own weight: “at only ~7.4kb minified+gzipped, and it’s tree shakeable with exactly 0 dependencies.” Most projects make claims you have to take on trust. This one can be audited from a terminal in under a minute, so we did — and the result is more interesting than a simple pass or fail.

Checking the headline numbers

Two commands against the npm registry, run while writing this:

npm view drizzle-orm dependencies
npm view drizzle-orm dist.unpackedSize dist.fileCount

The first prints nothing at all. There is no dependencies field in the published manifest, so “exactly 0 dependencies” is literally true — not “few”, not “only small ones”. For anyone who audits their own supply chain, that is the single most valuable fact in the README, because a zero-dependency data layer cannot pull a transitive surprise into your lockfile.

The second command reports something that looks contradictory: 10.5 MB unpacked across 2,690 files. That is not a broken promise, and it is worth understanding why. The package ships every dialect — PostgreSQL, MySQL, SQLite and their serverless variants — in several module formats with type declarations alongside. Your bundler keeps only the dialect and the functions you import; the 7.4 KB is what survives tree-shaking, while the 10.5 MB is what sits in node_modules.

The practical consequence: the small number is the one that matters for a browser or edge bundle, and the large one is the one that matters for cold-start image size and CI install time. If you deploy to a platform that charges you for either, measure your own build rather than quoting the README.

The version number nobody mentions

At the time of writing, drizzle-orm is at 0.45.4 and drizzle-kit at 0.31.11. Both are still pre-1.0, years into wide production use.

In practice the project has been stable across minor releases, but semver below 1.0 makes no compatibility promise, and that belongs in an architecture decision record rather than a footnote. Pin exact versions and read the release notes before bumping — the same discipline you would apply to any 0.x dependency that sits underneath your entire data access layer.

A licence detail that will come up in review

The two halves of the toolchain are not licensed the same way. drizzle-orm is Apache-2.0; drizzle-kit, the migration CLI, is MIT.

Both are permissive and neither should block adoption, but if your organisation runs a licence inventory, they are two separate entries, not one. It is the sort of thing that is trivial to record on day one and tedious to reconstruct during a due-diligence questionnaire.

Where the real compatibility surface lives

The README’s database list reads as a simple promise: “Drizzle supports every PostgreSQL, MySQL and SQLite database,” plus serverless targets including Turso, Neon, Xata, PlanetScale, Cloudflare D1, Vercel Postgres, Supabase and the AWS Data API, with the claim that “Drizzle is serverless-ready by design.”

The manifest shows what that actually means. Drizzle declares 29 optional peer dependencies — pg, postgres, mysql2, better-sqlite3, sqlite3, sql.js, expo-sqlite, @libsql/client, @neondatabase/serverless, @planetscale/database, @electric-sql/pglite, @vercel/postgres, @aws-sdk/client-rds-data, @cloudflare/workers-types and more, each with its own minimum version.

That list is the honest compatibility matrix, and reading it is the fastest way to answer “will this work with my setup?” Drizzle does not talk to your database; your driver does, and Drizzle states which driver versions it expects. If your driver is older than the declared floor, that is your upgrade before anything else. Turso appears here through @libsql/client, which is why the two pair cleanly.

No install command, on purpose

The README gives no npm install line, which looks like an omission until you notice the peer list. There is no single correct install command, because the second half depends on your driver: the ORM plus pg, or plus better-sqlite3, or plus @libsql/client. Start from the driver you already use and work backwards.

What it is actually for

Drizzle is a typed layer that leaves SQL visible rather than a framework that hides it. If you can read a query plan and want the compiler to catch a renamed column, that is the trade it makes. If you want relations, lifecycle hooks and conventions generated for you, a heavier ORM — or a backend platform like Supabase — fits better; Drizzle expects you to know your schema.

The finding from this audit: the dependency claim is exactly true, the size claim is true of your bundle and not of your node_modules, and the version and licence split are the two things worth writing down before you adopt it. None of that argues against Drizzle. It argues for spending the sixty seconds on npm view before you quote anyone’s README — including this one. Note too that it is an ORM, not an analytics engine: for columnar workloads you are in ClickHouse territory, not this one.