Drizzle ORM v1 is Imminent - and it's a Big Deal
A GitHub issue sat open for almost a year. No response from the team. Just a growing pile of +1 comments and npm audit warnings piling up in CI pipelines everywhere.
The issue? drizzle-kit has a dependency on @esbuild-kit/esm-loader - a package that had been deprecated and merged into tsx. That pulled in an old version of esbuild with a known security vulnerability. Nothing catastrophic, but enough to flag red in most enterprise pipelines and annoy anyone running npm audit as part of their build.
The community got creative with workarounds - overriding esbuild versions in package.json, swapping the package out with a pnpm alias. But the fix never landed. The team went quiet.
V1 Rewrite
In April, Andrii Sherman posted a thread explaining the silence. The team had been running parallel rewrites across four major branches for eight months. Abandoning the 0.* branch has caused some animosity but the V1 release is exciting:
drizzle-kit got a near-total rewrite - 167,000 lines added, 67,000 removed. The test suite went from 600 tests to roughly 9,000. The headline feature is commutative migrations: a new migration folder structure that lets teams work on schema changes in parallel without creating conflicts when branches merge. This seems to be incompatible with Wrangler - more on that later.
drizzle-orm got a complete internal type system rewrite. The result is a 21x reduction in TypeScript instantiations on real production schemas - we’re talking 728,000 down to 34,000.
Relational Queries v2 The old db._query API for postgres is gone.
What’s in the RC
The project is now at v1.0.0-rc.2, which shipped May 5. The RC added a few things worth knowing about:
JIT mappers - opt-in with drizzle({ jit: true }). Benchmarks show 14,500 - 15,300 requests per second. Off by default while they gather feedback.
Casing API is a breaking change. The old drizzle({ casing: 'camel' }) config option is gone. Casing is now declared at schema definition time: snakeCase.table(...) and camelCase.table(...). This sounds like a step backward but it actually fixes a class of bugs that came from casing being applied at query time rather than schema time.
drizzle-zod is absorbed into the main package. Zod 3.25+ is required. createSelectSchema now accepts views.
Two new dialects - CockroachDB and MSSQL - are in.
The PlanetScale Angle
In March, the entire Drizzle core team joined PlanetScale. The project stays open source, but it now has a well-funded corporate backer with an obvious interest in seeing Drizzle ship a stable v1. PlanetScale’s platform is MySQL-based, which gives the new MySQL/CockroachDB dialect work some context.
Before the acquisition, Drizzle had quietly reached profitability through a mix of Drizzle Studio licensing (embedded in Neon, Replit, Turso and others), sponsorships, and a consulting business that was funding OSS work on the side.
What About Cloudflare?
Worth knowing if you’re on CF/D1.
The old workflow was clean: drizzle-kit generate produced flat timestamped .sql files, and wrangler d1 migrations apply consumed them. Many CF projects were built on exactly this pattern.
v1 breaks it. The new migration structure wraps each migration in its own timestamped folder - 20260508135710_name/migration.sql - which is what makes commutative migrations possible. But wrangler only reads flat .sql files. It doesn’t traverse subdirectories. So wrangler d1 migrations apply simply doesn’t work with Drizzle v1 migrations.
The workaround: use drizzle-kit migrate directly (which works locally, but needs extra setup for remote production D1).
More on this in the NiteCal Fullstack Astro on CF series.
The prod workarounds aren’t ideal:
- Write a script to flatten the migrations back out for wrangler.
drizzle-kit migratehas ad1-httpdriver - applies directly to remote D1 over HTTP, no wrangler needed.
No sign Wrangler is fixing this anytime soon. Check before you upgrade.
Not all bad news for CF though. beta.18 added node:sqlite - the built-in Node 22.5+ driver, no native compilation. drizzle-kit migrate and Drizzle Studio auto-detect it at runtime. beta.22 fixed a D1 migration failure that was actively blocking people.
The team hasn’t dropped CF since the PlanetScale acquisition. PlanetScale is serverless - they want Drizzle running everywhere, CF Workers included.
As for alternatives: Prisma has D1 support but it’s heavier and the CF integration is clunkier. Kysely has no migration tooling. Raw D1 API has no type safety. Drizzle is the de facto standard and CF treats it that way.
When Does Stable Land?
No official date. There’s no public v1 milestone.
The RC cadence has been fast: rc.1 to rc.2 in under a week. If that holds, stable could be weeks away.
The upgrade guide is already live. If you’re not using casing: 'camel', most of it is a straightforward drop-in. The casing API is the one to check.
Subscribe to Skills Weekly, a digest of the hottest plugins & industry news. Only one email a week.
We respect your privacy. Unsubscribe anytime. Privacy Policy
Questions or feedback? Reach out on X @GetSkillsdev
← Back