「Vercel に乗せたら Prisma のコールドスタートが遅すぎる」「Cloudflare Workers に移したいが Prisma が動かない」——TypeScript の業務システム受託で、ここ半年特に増えた相談です。Edge ランタイム前提のアーキテクチャが当たり前になるにつれ、伝統的な ORM の重さが目立つようになりました。
代替の本命として挙がっているのが Drizzle ORM です。SQL に近い記法・薄いランタイム・Edge 対応を売りに、2025 年〜 2026 年で採用事例が急増しました。本記事では、Prisma から Drizzle へ移行を検討する受託案件で、設計判断と見積根拠をどう組み立てるかを整理します。
設計思想の違いを 1 枚で押さえる
両者のもっとも本質的な違いは、「ORM が何を抽象化するか」にあります。
| 観点 | Prisma | Drizzle |
|---|---|---|
| 抽象化レイヤー | DSL（schema.prisma） + クエリエンジン（Rust） | TypeScript の型のみ |
| ランタイム依存 | Query Engine バイナリが必要 | 純 TypeScript / SQL |
| Edge 対応 | Driver Adapters 経由（追加設定必要） | ネイティブ対応 |
| マイグレーション | prisma migrate（管理 UI 寄り） | drizzle-kit（SQL ファースト） |
| 学習曲線 | 緩やか（独自構文） | SQL を知っていれば即戦力 |
| バンドルサイズ | 数十 MB（エンジン込み） | 数百 KB |
Prisma は「ORM がスキーマと DB を管理する」発想、Drizzle は「SQL を TypeScript で書きやすくする」発想と整理できます。受託の現場では、後者のほうがクエリチューニングや障害対応の見通しが立てやすく、運用引き継ぎがスムーズです。
移行コストを支配する 3 要素
Prisma → Drizzle の見積を作るとき、工数を支配するのは次の 3 要素です。
1. スキーマ移行 — 自動化できる
schema.prisma から drizzle-kit introspect で TypeScript スキーマを生成できます。リレーションの定義スタイルが異なるため手直しは必要ですが、100 テーブル規模で 1〜2 人日が目安です。
// drizzle スキーマ例
import { pgTable, serial, text, timestamp, integer } from "drizzle-orm/pg-core";
export const users = pgTable("users", {
id: serial("id").primaryKey(),
email: text("email").notNull().unique(),
createdAt: timestamp("created_at").defaultNow().notNull(),
});
export const orders = pgTable("orders", {
id: serial("id").primaryKey(),
userId: integer("user_id").references(() => users.id).notNull(),
amount: integer("amount").notNull(),
});2. クエリ移行 — ここが本丸
Prisma の findMany({ where, include }) 形式から、Drizzle の select().from().leftJoin() 形式への書き換えが必要です。ロジックの本数 × 1 件あたり 30〜60 分を見積もります。とくに include で多段にネストしているクエリは、JOIN を意識して書き直す必要があり、N+1 問題の点検も同時にやる良い機会です。
3. テスト・QA — 戻り値の形が変わる点に注意
Prisma は LEFT JOIN でも子要素が空配列で返るのに対し、Drizzle は null 行を含む結果セットを返します。JSON レスポンスの shape が変わるため、API 契約に影響しないか E2E テストで全部通すのが安全です。E2E の自動化は Bun と Playwright で組むヘッドレス E2E と組み合わせるとリグレッション検知が早まります。
受託契約で押さえるべき 3 点
技術判断とは別に、受託の契約書面で必ず明記しておきたいポイントがあります。
- マイグレーション戦略の合意 — Big Bang か段階移行か。段階移行なら Prisma と Drizzle が同じ DB を読み書きする期間の不整合リスクをドキュメント化
- パフォーマンス受け入れ基準 — 「一覧 API の P95 が現行比 +20% 以内」など、移行後の SLA を数値で定義
- 学習コストの分担 — Drizzle は SQL 寄りのため、運用を引き継ぐ社内エンジニアへのトランジションプラン（読み合わせ会・コードレビュー伴走）を契約スコープに含める
このあたりを曖昧にしたまま進めると、「移行は終わったが現場が触れない」という レガシーシステムの UX 改善 と同じ罠に陥ります。
どちらを選ぶか — 判断フローチャート
実務では、次の問いを上から順に答えるとほぼ決まります。
- Edge / Workers ランタイムで動かす？ → Drizzle
- 数百 MB のバンドルサイズが許容できない？ → Drizzle
- スキーマ管理用の GUI が組織標準（Prisma Studio 利用中）？ → Prisma 継続
- 開発チームに SQL の素養がない？ → Prisma 継続
- それ以外、新規プロジェクト → Drizzle を第一候補
まとめ — 「ORM の選定」は 5 年後の運用コストを決める
ORM の乗り換えは派手さがない一方で、5 年スパンの運用コストとパフォーマンス天井を決める重要な意思決定です。Prisma が悪いわけではなく、Edge 全盛の今は Drizzle のほうがフィットする場面が増えてきた、というのが正確な現状認識です。
GleamHub では、既存 Prisma プロジェクトの段階移行 PoC、テスト戦略の設計、運用ドキュメント整備までを伴走しています。技術選定の壁打ちからお気軽に お問い合わせ ください。
