Drizzle ORM v1.0.0-rc.1: JIT mappers, Effect v4, new casing…

Drizzle's team published v1.0.0-rc.1 as a prerelease — the last meaningful step on the road to a stable 1.0. The release combines a serious performance push on the row-mapping path with new ecosystem hooks (Effect, Netlify) and a long-overdue cleanup of the casing API. Read it as a "no surprises in 1.0" release: most of the breaking changes you'd want before a major land here.

Drizzle ORM now has an opt-in API for JIT (just-in-time compiled) mappers which make the most expensive part of the db request pipeline (row mapping) as fast as humanly possible.

TL;DR

`jit: true` — opt-in JIT-compiled row mappers, the headline performance feature.
Internal codec rewrite — driver-specific normalization moved into a single layer, fixing inconsistencies and unlocking ~25–30% latency wins on the team's benchmarks.
Effect v4 integration — first-class effect-postgres path for teams on Effect.
New casing API — casing: "camel" on the db instance is gone; tables, views, and schemas now declare casing through snakeCase / camelCase namespaces.
Netlify DB driver — new drizzle-orm/netlify-db entry, maintained by Netlify.
RQB v1 removed for Postgres; RQBv2 mappers optimized in line with the JIT work.

Why JIT row mappers matter

Row mapping — turning the raw arrays a database driver hands back into typed JS objects — is the most expensive part of a typical query in any ORM. For each row you iterate columns, parse values, and assemble nested relations. In Drizzle's profile, mapping was often the single biggest CPU consumer at the application layer, especially on read-heavy services.

JIT mappers flip that. When you opt in:

import { drizzle } from "drizzle-orm/postgres-js";

const db = drizzle(client, { jit: true });

Drizzle generates a specialized mapper function the first time a prepared query runs. Subsequent invocations skip the generic, branchy mapping loop and call straight into the compiled function. The trade-off is a small first-call cost (function generation) in exchange for steady-state throughput that approaches the theoretical floor of the driver itself.

Codec rewrite, internal but visible

Around the JIT work, the team rewrote the internal codec layer that normalizes driver-specific quirks. Some examples of what got cleaned up:

Postgres numeric columns previously returned strings in some paths and JS numbers in others depending on the driver — now consistent.
bigint handling unified across drivers, with explicit configuration for "always BigInt" vs "Number when safe".
Boolean coercion no longer differed between pg and postgres-js for edge cases.

The release notes cite ~25–30% latency improvement on the benchmark suite and a large +rps jump. Those numbers are workload-dependent — if your queries are dominated by network or by JOINs the database itself struggles with, the wins shrink. If you're returning thousands of rows on a hot endpoint, the wins can be larger than the headline.

Effect v4

If your codebase is on Effect (typed, structured, fp-flavored programming for TypeScript), this RC ships first-class integration:

import { Effect } from "effect";
import { drizzle } from "drizzle-orm/effect-postgres";

const program = Effect.gen(function* () {
  const db = yield* drizzle.client;
  const users = yield* db.select().from(usersTable);
  return users;
});

You get Effect-aware error channels, dependency injection through Effect's Layer system, and resource management through Scope. Teams that picked Drizzle precisely because it composed with their other TypeScript primitives finally have an Effect story that doesn't require hand-written wrappers.

The casing migration

The most visible breaking change. v1 retires the global casing: "camel" option on the db instance:

// Before (v0.x)
const db = drizzle(client, { casing: "camel" });

In its place, casing is declared per-schema or per-table through namespace helpers:

import { snakeCase, camelCase } from "drizzle-orm/casing";

export const users = snakeCase.pgTable("users", {
  id: serial("id").primaryKey(),
  fullName: text(),
  createdAt: timestamp(),
});

The motivation: real codebases mix conventions. Legacy tables stay snake_case; new ones go camelCase; some live in a different schema with its own rules. Forcing a global toggle made every escape hatch awkward. The new namespaces let each table state its convention exactly once, in one obvious place.

Migration takes time but follows a clear pattern:

1. Remove casing from the drizzle() call. 2. Wrap each pgTable / mysqlTable / sqliteTable in the appropriate snakeCase / camelCase namespace. 3. Run the type checker — Drizzle's types narrow the column names so any place you accessed a property that no longer matches will fail at compile time.

Netlify DB driver

drizzle-orm/netlify-db is a new entry point, maintained by Netlify themselves. If you're deploying to Netlify Functions and using their managed Postgres, the driver gives you the connection-pooling and serverless-friendly behavior you'd expect, without hand-wiring pg or another driver.

RQB v1 removed for Postgres

Relational Queries (RQB, the high-level relational API) had two versions co-existing: v1 (._query) and v2 (the new mapper-aware path). The RC1 removes the v1 entry point for Postgres. If you're calling ._query anywhere, replace it with the v2 form (the docs include a side-by-side table). Other dialects (MySQL, SQLite) still ship v1 in the RC, but expect the same removal in subsequent prereleases.

Stability notes

This is still an rc. Practical advice:

Pin exact versions in production. ^1.0.0-rc.1 will pull future RCs that may shift APIs again.
Read the full release notes — every breaking bullet matters.
The 0.45.x stable line continues; if you cannot adopt the casing migration this quarter, stay on 0.45 with the recent 0.45.2 security fix.
File issues with reproducible repros if you hit a regression — the team has been responsive on the RC branch.

Where this connects

If you're still on the 0.45.x line, the Drizzle 0.45.2 security fix landed in late March 2026 and matters even if you don't plan to bump to v1 yet. The codec rewrite in v1 also resolves several of the long-running issues filed around numeric and bigint handling — worth scanning the GitHub issue queue if you've worked around those.

References

Source / further reading: Drizzle ORM (GitHub release)

Drizzle ORM v1.0.0-rc.1: JIT mappers, Effect v4, new casing API