TypeScript製ORM「Drizzle ORM」が、待望のv1.0正式版に向けたリリース候補（RC）を公開しました。JITコンパイルによるパフォーマンス革新、Effect v4対応、casing APIの刷新など、正式版を見据えた大型アップデートです。

この記事でわかること：

  • JITマッパーが実現するパフォーマンス改善の中身
  • Effect v4ネイティブ対応で何が変わるか
  • casing APIの破壊的変更と移行方法
  • Netlify Databaseドライバの追加

Drizzle ORMとは

https://github.com/drizzle-team/drizzle-orm

Drizzle ORMはTypeScriptで書かれた軽量ORM（Object-Relational Mapping）です。minify+gzip後のサイズが約7.4KBで、外部依存パッケージはゼロ。PostgreSQL、MySQL、SQLite、SingleStoreなど主要データベースに対応し、サーバーレス環境でもそのまま動作します。GitHubスター数は34,000を超え、PrismaやTypeORMと並ぶTypeScript ORM の選択肢として定着しています。

2025年2月にv1.0.0-beta.1を公開して以降、ベータ版を重ねてきました。今回のRC（Release Candidate）は正式リリース直前の段階で、大きな問題がなければこのままv1.0として公開される見込みです。

JITマッパーでレイテンシ25〜30%削減

https://github.com/drizzle-team/drizzle-orm/releases/tag/v1.0.0-rc.1

今回のリリースで最も注目すべきのはJIT（Just-In-Time）マッパーです。ORMがデータベースからデータを受け取ったあと、行データをJavaScriptオブジェクトに変換する処理（行マッピング）は、リクエストパイプラインの中で最もコストが高い部分です。JITマッパーはこの変換関数を実行時にコンパイルして最適化します。

使い方はシンプルで、Drizzleインスタンスの初期化時にjit: trueを指定するだけです。

const db = drizzle({ ..., jit: true });
const query = db.select().from(users).prepare();

prepare()を呼んだ時点でJITマッパーが生成され、以降の実行で使い回されます。Drizzleチームのベンチマークでは、レイテンシが25〜30%低減し、秒間リクエスト数は14,500から15,300へ約800rps向上しました。生のドライバを直接使って手動マッピングする場合とほぼ同等の速度を実現しています。

あわせて、PostgreSQL向けに「codec」という仕組みを導入しました。ドライバごとに異なるデータ型の返り方（通常のSELECT、JSONオブジェクト、PostgreSQL配列など）を正規化する層で、不要な変換処理をなくすことでパフォーマンス向上に寄与しています。

Effect v4にネイティブ対応

Effect（旧Effect-TS）は、TypeScriptで型安全なエラーハンドリングや依存性注入を実現するライブラリです。Drizzle ORMはこれまでEffect v3との統合を提供してきましたが、rc.1でEffect v4への対応に切り替えました。

import { PgClient } from '@effect/sql-pg';
import * as PgDrizzle from 'drizzle-orm/effect-postgres';
import * as Effect from 'effect/Effect';

Effectのサービスパターンに沿った形でDrizzleのクエリを実行でき、エラー型の追跡やリソース管理をEffect側に任せられます。現時点ではPostgreSQLのみの対応ですが、他のデータベースへの展開も予定されています。

Effect v3はメンテナンスモードに移行する見込みのため、Effectを使っているプロジェクトではv4への移行が推奨されます。

casing APIを根本から作り直し（破壊的変更）

TypeScriptではcamelCase（createdAt）、データベースではsnake_case（created_at）を使うケースは多くあります。Drizzle ORMはこの変換を自動で行うcasing APIを提供してきましたが、従来の実装には問題がありました。drizzle()インスタンスの初期化時とdrizzle-kitの設定ファイルの両方でcasingを指定する必要があり、クエリビルダのあちこちでバグが発生していました。

rc.1ではこのAPIを廃止し、テーブル・ビュー・スキーマの定義段階でcasingを指定する方式に変更しました。

import * as d from "drizzle-orm/pg-core";

const users = d.snakeCase.table("users", {
  id: d.serial().primaryKey(),
  fullName: d.text(), // DBでは full_name
  createdAt: d.timestamp().defaultNow(), // DBでは created_at
});

snakeCase.table()やcamelCase.schema()のように、エンティティ単位でcasing方式を制御します。スキーマ内の全テーブルに一括適用もでき、設定の二重管理が解消されました。既存プロジェクトではcasing周りのコード書き換えが必要です。

Netlify Databaseドライバを追加

Netlifyチームが開発・メンテナンスするNetlify Database向けのドライバが追加されました。@netlify/databaseパッケージをインストールし、drizzle-orm/netlify-dbからインポートすることで利用できます。Netlifyでホスティングしているプロジェクトでは、環境変数から自動的に接続情報を取得する仕組みが組み込まれています。

LLMエージェント向け機能をプレビュー公開

Drizzleチームはrc.1とあわせて、LLMエージェント向けの機能をプレビューとして公開しました。Drizzle ORMは以前からllms.txt形式でドキュメントを提供しており、AIコーディングエージェントがDrizzleのAPIを正しく扱うための情報基盤を整えてきました。今回のプレビューはその延長線上にある取り組みで、LLMがデータベース操作をより効率的に行えるようにする機能と位置づけられています。詳細は今後公開される見込みです。

その他の改善点

RQBv1（Relational Query Builder v1）のdb._queryがPostgreSQLから削除されました。RQBv2への移行がまだの場合はrc.1導入前に対応が必要です。neon-httpのバイナリデータ破損や、bun-sql/postgresのタイムスタンプタイムゾーン切り捨て問題なども修正されています。

v1.0正式リリースへの道筋

Drizzle ORMのv1ロードマップは公式サイトで進捗98%と表示されています。RC版で大きな問題が見つからなければ、正式版のリリースは近いでしょう。ベータ版からRCへの移行にはいくつかの破壊的変更が含まれるため、アップグレードの際は公式の移行ガイドを確認してください。

npm install drizzle-orm@rcで試せます。本番環境への導入前に、JITマッパーの動作やcasing APIの変更点を開発環境で検証することを推奨します。