Drizzle ORM keeps a thin typed layer over SQL

A 7.4kb headless layer with zero dependencies sets the footprint

Drizzle presents itself as a headless ORM for NodeJS, TypeScript and JavaScript, and as a thin typed layer on top of SQL. The footprint claim is concrete: only about 7.4kb minified plus gzipped, tree shakeable, with exactly 0 dependencies. For readers that number sets expectations about bundle cost and install weight, since there are no Rust binaries to download and no serverless adapters to add. The repository metadata around that claim is Apache-2.0 licensed, default branch main, homepage https://orm.drizzle.team, last push 2026-09-27, with recent releases 0.45.3 and drizzle-kit at 0.31.11 both dated 2026-09-21 and a v1.0.0-rc.4 dated 2026-06-27. The monorepo root is private under pnpm workspace with packageManager pnpm at 10.6.3, turbo orchestration, TypeScript 5.6.3 and dprint for formatting. Bundle size and dependency count are the only size facts given, so plans that depend on throughput or latency numbers need measurements outside what the README provides.

One package addresses Postgres, MySQL and SQLite serverless hosts

Drizzle supports every PostgreSQL, MySQL and SQLite database, including serverless ones named as Turso, Neon, Xata, PlanetScale, Cloudflare D1, FlyIO LiteFS, Vercel Postgres, Supabase and AWS Data API. The sentence that follows matters for operations: no bells and whistles, no Rust binaries, no serverless adapters, everything just works out of the box. A team running Postgres on Neon for one service, MySQL on PlanetScale for another and SQLite on Turso or Cloudflare D1 at the edge keeps one ORM package instead of one driver wrapper per host. The trade is scope: the README names hosts and database families but gives no per host connection string, no failover behavior and no host specific tuning flag, so each deployment still needs the host docs alongside the Drizzle docs. Version movement also splits across two lines, with drizzle-orm at 0.45.3 and drizzle-kit at 0.31.11 released the same day, which means upgrades touch the ORM and the migration CLI as separate packages rather than one lockstep version.

Edge and serverless runtimes run with no data proxy in between

Drizzle is serverless-ready by design and works in every major JavaScript runtime named as NodeJS, Bun, Deno, Cloudflare Workers, Supabase functions, any Edge runtime, and even in browsers. With Drizzle a project can be fast out of the box and save time and costs while never introducing any data proxies into infrastructure. The no proxy point has a direct architectural consequence: there is no extra hop to deploy, monitor or pay for between the function and the database, which keeps serverless bundles and cold start paths free of a sidecar process. The runtime list also widens where the same query code ships, from long lived NodeJS servers to short lived edge functions and browser contexts. What the README does not give is a runtime compatibility matrix with version floors, so Bun, Deno or Workers users still need to check the docs site for the exact driver import that matches their runtime before assuming one import covers all of them.

TypeScript schema declarations feed relational and SQL-like queries

Drizzle works as a JavaScript library, yet it shines with TypeScript. It lets developers declare SQL schemas and build both relational and SQL-like queries, while keeping the balance between type-safety and extensibility for toolmakers to build on top. That sentence defines the intended split: schema declarations carry types forward, relational queries express nested reads, SQL-like queries stay close to SQL shape, and the extension surface stays open for tool authors. The monorepo backs that reading with validation bridges kept as sibling packages: drizzle-zod, drizzle-valibot, drizzle-typebox and drizzle-arktype sit next to drizzle-orm, drizzle-kit, drizzle-seed and eslint-plugin-drizzle, with integration-tests, changelogs and docs directories beside them. The consequence for plain JavaScript teams is a thinner return: the queries still run, but the typed schema declarations and type carried query results that justify the package choice only pay off once TypeScript types the project.

Drizzle Kit turns schema edits into files or direct applies

Drizzle ORM remains a thin typed layer on top of SQL, and the project ships a set of tools for developer experience around it. Drizzle Kit is the CLI companion for hassle-free migrations: it can generate SQL migration files or apply schema changes directly to the database. That pair of modes matters because generated files suit reviewed deploys where SQL passes through pull requests, while direct applies suit local iteration where the schema changes fast. Drizzle Studio is the other companion: it browses and manipulates data in the database of choice, which covers inspection and small data fixes without opening a separate database client. Neither tool lives inside the ORM package itself. drizzle-kit has its own release line at 0.31.11, and the root package.json pins drizzle-kit at ^0.19.13 for development while referencing drizzle-orm through the workspace build, so migration behavior can shift with a Kit upgrade even when the ORM version stays fixed.

The README alone cannot install or query anything

The README is short, about 292 words of description plus links, and it cannot take a project from zero to first query on its own. It gives no install command, no import line, no connection example and no schema snippet. It instead points outward: full documentation lives on the website at https://orm.drizzle.team/docs/overview, with get started pages per database and per host. A newcomer who stays inside the README will find the footprint claim, the host list, the runtime list and the Kit and Studio paragraphs, then hit a wall at the point of typing an actual command. The fix is to start from the docs site and the package listings for drizzle-orm and drizzle-kit rather than from the README text. Repository scripts also assume contributor tooling rather than end user setup: build:orm runs turbo run build filtered to drizzle-orm, build runs turbo run build with type tests, test runs turbo run test, and lint runs dprint check, all under pnpm 10.6.3. Those scripts build and verify the monorepo itself, not a user project.

Thin layer scope leaves migrations, browsing and types to companions

Several gaps fall out of the thin layer positioning, and each has a cost for planning. First, JavaScript without TypeScript runs but loses the typed schema and typed result payoff that the project centers on, so a team that will not adopt TypeScript gets less reason to choose this package. Second, migration and browsing depend on companions: schema file generation and direct applies need Drizzle Kit, data browsing and manipulation need Drizzle Studio, so a minimal install of the ORM alone covers queries without covering change management or inspection. Third, the README gives no error catalog, no rollback procedure for a failed migration and no support window per release, which means incident handling and upgrade timing need answers from the docs, changelogs directory and release notes rather than from the front page. Fourth, the monorepo build path with pnpm workspaces, turbo pipelines and workspace linked drizzle-orm applies to contributors, not to application installs, so cloning the whole repository to use the ORM adds weight that application teams should skip in favor of the published packages.

Editorial conclusion

Pick Drizzle ORM if you write TypeScript against PostgreSQL, MySQL or SQLite and want a thin Apache-2.0 licensed layer with Kit migrations and Studio browsing, last pushed 2026-09-27 as 0.45.3. Skip it if you need a full platform inside one package or plain JavaScript without types, and before starting confirm your database host and runtime appear on the supported lists in the docs.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes