目次を表示する

Prisma v7 — なぜRustから撤退したのか、OSSの構造改革として読み解く

各領域の変更マップ ── v7で何がどう変わったのか

各領域の変更マップ ── v7で何がどう変わったのか

ここからは「What」に入る。v7 では広範な変更が入っており、ひとつひとつは独立して見えるが、前章で見た境界の引き直しという設計思想で貫かれている。領域ごとに整理しよう。


変更マップの全体像

graph TD
    Root[Prisma ORM 7.0]
    Root --> A[Query Engine]
    Root --> B[Schema / Client 生成]
    Root --> C[CLI / Migration]
    Root --> D[Driver Adapters]
    Root --> E[エコシステム]
    Root --> F[データベース対応]

    A --> A1[Rust バイナリ撤去]
    A --> A2[WASM Query Compiler]
    A --> A3[TS Executor]

    B --> B1[generator が prisma-client に]
    B --> B2[output 必須化]
    B --> B3[ESM ネイティブ]
    B --> B4[型システム大改善]

    C --> C1[自動 generate 廃止]
    C --> C2[自動 seed 廃止]
    C --> C3[prisma.config.ts へ移行]

    D --> D1[全 DB で必須]
    D --> D2[SSL / プール挙動が変化]

    E --> E1[Accelerate 統合変更]
    E --> E2[Studio 刷新]
    E --> E3[Pulse 統合]

    F --> F1[MongoDB 未対応]
    F --> F2[Prisma Postgres 深化]

1. Query Engine:Rust バイナリが完全に消えた

v6 までの node_modules/.prisma/client/ には、OS × OpenSSL 別の Rust バイナリがずらりと並んでいた。v7 ではこれが一掃される。

v6(典型的な構成):
  node_modules/.prisma/client/
    ├── index.js
    ├── query-engine-darwin-arm64    (Rust バイナリ)
    ├── query-engine-linux-musl       (Rust バイナリ)
    ├── query-engine-windows.exe      (Rust バイナリ)
    └── ...

v7:
  src/generated/prisma/
    ├── index.ts
    ├── query-compiler-bg.wasm        (Query Compiler WASM)
    └── runtime/                       (TS の実行時コード)

バンドルサイズは約 14MB → 約 1.6MB(90% 減)、gzip 後は 7MB → 600KB ほどになった(Prisma 公式ベンチマーク)。サーバーレスで効いてくるのはもちろん、モノレポやコンテナイメージでも体感できる差である。


2. Schema / Client 生成

2.1 Generator の provider が変わった

// v6 まで
generator client {
  provider = "prisma-client-js"
}

// v7
generator client {
  provider = "prisma-client"   // ← 新しい generator
  output   = "../src/generated/prisma"   // ← output が必須に
}

新しい generator は node_modules には出力しない。ソースディレクトリに出す。これは破壊的変更だが、合理的な理由がある。

node_modules に出力するのをやめた理由:
  ① モノレポで node_modules の位置が変動する問題
  ② npm / pnpm / yarn / bun で解決挙動が違う問題
  ③ CI で毎回 generate するコストを減らしたい
  ④ 型情報がソースコードの一部として扱える

結果:
  - 生成物を Git にコミットするかどうかは選べる
  - コミットすれば CI で generate が不要に
  - しない場合も出力先が一意に決まる

2.2 ESM ネイティブへ

v7 のクライアントは ESM ネイティブで生成される。

// package.json に必須
{
  "type": "module"
}
// import はファイル拡張子付き
import { PrismaClient } from './generated/prisma/client.js';

CommonJS でどうしても動かしたい場合の interop は用意されているが、原則 ESM 前提。TypeScript は "module": "NodeNext""ESNext" + bundler リゾルバが推奨される。この強制移行は後述する現場の痛みの源でもある(Ch.8 で詳述)。

2.3 Node / TypeScript の最低バージョン引き上げ

最低要件(v7):
  Node.js     ≥ 20.19.0
  TypeScript  ≥ 5.4.0

Node 20 は 2024 年 10 月に LTS 化、2026 年 4 月には LTS 終盤に差し掛かっている。実質的には Node 22 以上で使うのが無難。

2.4 型システムの大幅改善

地味だが、開発体験に最も効く変更がこれである。ArkType の作者 David Blass とのコラボレーションで、Prisma Client の型が根本から書き直された。

公式発表の計測値:
  ✅ スキーマ評価の型数  〜98% 削減
  ✅ クエリ評価の型数   〜45% 削減
  ✅ フル型チェック     70% 高速化

v6 時代、巨大スキーマ(数十〜数百モデル)を持つプロジェクトで tsc の遅さや IDE の補完遅延に悩まされたことがある人には、ここが最大の利点に映るはずだ。VSCode の TypeScript Server が重くなる問題もここで緩和される。


3. CLI / Migration

3.1 自動 generate の廃止

v6 まで、以下のコマンドは暗黙的に prisma generate を実行していた。

v6 の暗黙挙動:
  prisma migrate dev    → 内部で generate
  prisma db push         → 内部で generate

v7:
  上記は generate を「実行しない」
  → 自分で prisma generate を明示的に呼ぶ必要あり

--skip-generate フラグは削除された(不要になったため)。

3.2 自動 seed の廃止

v6 まで:
  prisma migrate dev    → package.json の prisma.seed を自動実行
  prisma migrate reset  → 同上

v7:
  どちらも seed を自動実行しない
  → npx prisma db seed を明示的に実行
  → --skip-seed フラグは削除

挙動としては素直で予測可能になった一方、CI やローカル開発スクリプトで暗黙に依存していたケースでは壊れる。移行時に気づきにくいタイプの変更である。

3.3 prisma.config.ts への移行

v6 まで、データソース URL はスキーマ内に書いていた。

// v6(非推奨)
datasource db {
  provider          = "postgresql"
  url               = env("DATABASE_URL")
  directUrl         = env("DIRECT_URL")
  shadowDatabaseUrl = env("SHADOW_URL")
}

v7 では prisma.config.ts に移す。

// prisma.config.ts
import { defineConfig } from 'prisma/config';
import { PrismaPg } from '@prisma/adapter-pg';

export default defineConfig({
  schema: './prisma/schema.prisma',
  migrations: {
    adapter: async () => new PrismaPg({
      connectionString: process.env.DATABASE_URL,
    }),
    shadowDatabase: async () => new PrismaPg({
      connectionString: process.env.SHADOW_DATABASE_URL,
    }),
  },
});

prisma migrate diff--from-url / --to-url / --shadow-database-url フラグも削除され、--from-config-datasource / --to-config-datasource に置き換わっている。


4. Driver Adapters:必須化

v5 で Preview、v6 で GA、v7 で必須という三段階で昇格した。

4.1 基本パターン

// PostgreSQL
import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from './generated/prisma/client';

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
});
const prisma = new PrismaClient({ adapter });
// SQLite(ローカル開発 / テスト)
import { PrismaBetterSQLite3 } from '@prisma/adapter-better-sqlite3';

const adapter = new PrismaBetterSQLite3({ url: 'file:./dev.db' });
const prisma = new PrismaClient({ adapter });

4.2 挙動が変わる二つの点

Driver Adapter 化で、アプリ側の挙動が変わるポイントがある。これは移行時の落とし穴なので押さえておきたい。

① SSL 検証がデフォルトで有効になる

v6 まで(Rust エンジン):
  DATABASE_URL に sslmode=require があっても、
  証明書の検証は Rust 側のデフォルトに依存
  → 自己署名証明書でも通ることが多かった

v7(Driver Adapter / node-pg):
  node-pg のデフォルトで証明書を検証する
  → 自己署名証明書はエラーになる
  → rejectUnauthorized: false を明示する必要があるケース
// 自己署名証明書を使う場合(例:Supabase / 一部の RDS 構成)
const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
  ssl: { rejectUnauthorized: false },
});

セキュリティ的には厳格化して正しい挙動だが、**「今まで動いていたのに v7 にしたら繋がらない」**となりやすい。

② コネクションプールは Driver 側の設定になる

v6 時代、接続プールのチューニングは DATABASE_URL のクエリパラメータ(connection_limit=10 など)で行えた。v7 では Driver Adapter に渡す。

const adapter = new PrismaPg({
  connectionString: process.env.DATABASE_URL,
  max: 10,                    // プール上限
  idleTimeoutMillis: 30000,   // アイドル切断
  connectionTimeoutMillis: 5000,
});

connection_limit のような URL パラメータに頼っていたコードは、明示的に書き換える必要がある。

4.3 環境変数の自動ロード廃止

Rust エンジンは起動時に .env を勝手に読んでいた。v7 ではこれをやめた。

// v7:明示的に dotenv をロードする(Node.js の場合)
import 'dotenv/config';   // ← これを付ける
import { PrismaClient } from './generated/prisma/client';

Bun は組み込みで .env をロードするので不要。Node.js 20.6+ の --env-file=.env フラグを使う手もある。


5. エコシステム:Accelerate / Pulse / Studio

5.1 Prisma Accelerate

Accelerate は「グローバルな接続プーリング + クエリ結果キャッシュ」サービス。v7 では初期化方法が変わった。

// v7
import { PrismaClient } from './generated/prisma/client';
import { withAccelerate } from '@prisma/extension-accelerate';

const prisma = new PrismaClient({
  accelerateUrl: process.env.DATABASE_URL, // Accelerate 経由の URL
}).$extends(withAccelerate());

Driver Adapter と Accelerate URL の関係が明示的になり、「ローカルは pg ドライバ、本番は Accelerate」の切り替えがコードとして素直に表現できるようになった。

5.2 Prisma Pulse

リアルタイム DB 変更ストリームを提供する Pulse も、Driver Adapter を通じた接続形式に統一された。v7 本流のアーキテクチャに揃えた形である。

5.3 Prisma Studio 刷新

GUI ツール Studio は v7.0 に合わせて新デザインで同梱された。主な新機能は以下。

新 Studio の目玉機能:
  ✅ マルチセル選択(スプレッドシート的な一括編集)
  ✅ 横断検索(テーブル横断で値を探せる)
  ✅ 生 SQL フィルタ(Where 節を自然言語に近く書ける)
  ✅ SQL タブ(ad-hoc SQL を実行できるエディタ)

6. Middleware 廃止と Client Extensions

v6 まで、横断的な処理を挟み込むために $use ベースの Middleware があった。

// v6 まで(v7 で削除)
prisma.$use(async (params, next) => {
  const start = Date.now();
  const result = await next(params);
  console.log(`${params.model}.${params.action} took ${Date.now() - start}ms`);
  return result;
});

これが v7 では完全撤廃された。代替は Client Extensions

// v7 の Client Extensions
import { PrismaClient } from './generated/prisma/client';

const prisma = new PrismaClient({ adapter }).$extends({
  query: {
    async $allOperations({ model, operation, args, query }) {
      const start = Date.now();
      const result = await query(args);
      console.log(`${model}.${operation} took ${Date.now() - start}ms`);
      return result;
    },
  },
});

Client Extensions は Middleware より型安全で、query 以外に model(カスタムメソッド追加)、result(計算フィールド追加)、client(クライアント全体の拡張)という粒度を持つ。既存 Middleware を移植する際、ロギング用途なら query.$allOperations に素直にマッピングできる。


7. 削除された環境変数とフラグ

Rust エンジンを前提に存在していた環境変数/フラグが、v7 で軒並み削除された。

削除された環境変数(主なもの):
  PRISMA_CLI_QUERY_ENGINE_TYPE
  PRISMA_CLIENT_ENGINE_TYPE
  PRISMA_QUERY_ENGINE_BINARY
  PRISMA_QUERY_ENGINE_LIBRARY
  PRISMA_INTROSPECTION_ENGINE_BINARY
  PRISMA_MIGRATION_ENGINE_BINARY
  PRISMA_SCHEMA_ENGINE_BINARY
  PRISMA_FMT_BINARY
  ... 計 12 種類以上

削除された CLI フラグ:
  --skip-generate
  --skip-seed
  --schema(多くのコマンドで)
  --url(一部のコマンドで)

これらに依存したデプロイスクリプトは、移行時に必ず書き換えが必要になる。


8. データベース対応の変化

8.1 First-Class Databases

v7 で First-Class Databases(FCDB) として明示的にサポートされるのは以下。

First-Class Databases(v7.0 時点):
  ✅ PostgreSQL
  ✅ Prisma Postgres(Prisma 自家製マネージド PG)
  ✅ MySQL / MariaDB
  ✅ SQLite

8.2 MongoDB は一時ドロップ

⚠️ MongoDB は v7 では未対応
  → v6 を継続使用
  → v8(Prisma Next)で復活予定

これは意図的なフォーカスの結果であり、コミュニティから批判もあった(Ch.8 で触れる)。現時点で MongoDB を使うプロジェクトは、v7 移行を保留するのが素直な選択である。

8.3 SQL Server・CockroachDB

継続サポートされるが、FCDB には含まれない。Driver Adapter 経由で使える。

8.4 Prisma Postgres の深化

Prisma Postgres は 2024 年後半から提供されていたマネージド DB サービスだが、v7 では統合がさらに深まった。

Prisma Postgres(v7 時点):
  ✅ Unikernel microVM 基盤(起動が速い)
  ✅ npm create db でワンコマンド作成
  ✅ ネイティブ Postgres プロトコル対応
     → Cloudflare Hyperdrive, TablePlus, psql 等で直接接続可能

「Prisma 専用の閉じた DB」から「普通の Postgres として扱える」方向に進化している。


本章のまとめと次章への接続

✅ Query Engine:Rust バイナリ撤去 → WASM Compiler + TS Executor
   バンドルサイズ 14MB → 1.6MB

✅ Schema / Client:generator 刷新、output 必須化、ESM ネイティブ、
   型評価 〜98% 削減、tsc 70% 高速化

✅ CLI / Migration:自動 generate・自動 seed 廃止、prisma.config.ts へ集約

✅ Driver Adapters:全 DB で必須化
   SSL 検証デフォルト有効化、コネクションプール設定の移動に注意

✅ Middleware 廃止 → Client Extensions
✅ Accelerate / Pulse / Studio は Driver Adapter 前提に統合
✅ MongoDB は v7 で未対応(v6 継続 or v8 待ち)

ここまで来ると、「で、結局どれくらい速くなったの?」が気になる。次章は徹底的にベンチマークを見ていく。公式レポジトリの数字、コールドスタートの実測、Drizzle との比較 ── 数字で v7 の果実と限界を確かめる。

参考文献