パフォーマンス ── 本当に速くなったのか
ここまでの章で見た「境界の引き直し」は、理屈としては筋が通っていた。問題は、実測で果実が出ているかである。Rust を捨てて遅くなったら、ただの敗北だ。本章では Prisma 公式ベンチマーク、第三者の実測、Drizzle との比較を順に見ていく。
数字の見取り図
v7 の性能改善は、単一の指標ではなく、複数の軸で表れている。
quadrantChart
title v7 での性能改善の全体像
x-axis "実行時のスループット" --> "起動 / バンドル"
y-axis "ほぼ同等" --> "大幅改善"
quadrant-1 "大幅改善 × 起動系"
quadrant-2 "大幅改善 × スループット"
quadrant-3 "ほぼ同等 × スループット"
quadrant-4 "ほぼ同等 × 起動系"
"findMany 大量取得": [0.25, 0.85]
"include 付き m2m": [0.2, 0.95]
"単純な CRUD": [0.15, 0.35]
"バンドルサイズ": [0.85, 0.95]
"コールドスタート": [0.85, 0.8]
"TS 型チェック": [0.75, 0.8]端的に言えば、「大きな仕事・起動周り・開発体験」で明確に勝ち、「小さな仕事」では互角──これが v7 の戦績である。
1. クエリ実行時スループット（公式ベンチマーク）
Prisma は prisma/query-compiler-benchmarks という専用リポジトリでベンチマークを公開している。ここから代表的な結果を並べる。
結果テーブル（Rust 版 vs v7 WASM + TS）
| シナリオ | Rust 版 | v7 (WASM + TS) | 改善率 |
|---|---|---|---|
findMany 25,000 件（単純） | 163ms / 185ms | 77ms / 55ms | 2.1〜3.4x |
findMany + include m2m（take 2,000） | 1,539ms | 136ms | 11.3x |
findMany + where + include m2m（take 2,000） | 82ms | 38ms | 2.2x |
| 複雑な JOIN（複数テーブル） | 207ms | 130ms | 1.6x |
出典：公式ベンチマーク記事 および ベンチマーク repository。
特に劇的な「11 倍」の正体
findMany + m2m の include で 11 倍という数字は目を引くが、これは前章で見たシリアライズコストの具体例である。
v6 の処理フロー（簡略）：
1. Rust エンジンが複数テーブルから結果を取得
2. m2m リレーションを Rust 側で組み立てる
3. 組み立てた JSON を Node.js に送る（大きい）
4. Node.js がパースしてオブジェクトツリーを作る
v7 の処理フロー：
1. Query Compiler（WASM）がクエリプランを生成（小さい）
2. TypeScript Executor が複数クエリを発行
3. 結果（JS オブジェクトのまま）を TS でツリー構造に組み立てる
4. そのままユーザーに返す（シリアライズなし）結果サイズが大きく、かつ複雑なオブジェクトツリーを返すケースほど、v7 の**「そのまま JS オブジェクトで扱える」**利点が効いてくる。11 倍はこの設計判断が最も効くケースでの数字である。
「Rust 版の方が速いケース」は存在する
誤解を避けるため書いておくと、単純な findUnique や小さな結果セットでは Rust 版が数%〜十数%速いケースがある。Prisma 公式はこれを次のように整理している。
「小さなクエリでは Rust 版がわずかに速いことがあるが、マイクロ秒レベルの差であり、実用上は無意味。」
v7 の勝ちパターンは「クエリが複雑 / 結果が多い / オブジェクトツリーが深い」ケースで、v6 的な最適化のスイートスポットがずれていると理解しておくと使い分けの感覚が掴める。
2. バンドルサイズ：90% 減は誇張ではない
ここは誰が測っても同じ結果が出る、地味だが確実な勝ち筋である。
Prisma Client のバンドルサイズ（公式計測）：
v6 までのインストール（Rust バイナリ同梱）：
- 展開後 約 14MB
- gzip 後 約 7MB
v7：
- 展開後 約 1.6MB（-88%）
- gzip 後 約 600KB（-91%）体感できる場面は次の通り。
2.1 サーバーレスのパッケージ制約
AWS Lambda の zip アップロードは 50MB 上限。v6 時代は「Prisma で 7MB 食った残りで全部収める」という制約で苦戦していた。v7 では予算が大幅に増える。
2.2 コンテナイメージ
Node アプリのコンテナイメージ（典型的な構成、概算）：
ベース Alpine Node 20 ~180MB
+ node_modules（v6 Prisma） +350MB
+ アプリ本体 +20MB
= 約 550MB
v7 に切り替え：
- node_modules +335MB（v6 比 -15MB）
- Rust バイナリ 12MB が減る効果はそこまで大きくないが
- ランタイムの OpenSSL 依存が消えるのでベースイメージが選びやすくなる「Alpine で動かない」「OpenSSL のマイナー違いで動かない」系のトラブルが消える方が、サイズ以上の価値がある。
2.3 エッジランタイム
Cloudflare Workers / Vercel Edge は Worker サイズに厳しい上限がある（Workers は Free 1MB、Paid 10MB）。Prisma 自体が数 MB 取ると他の依存を入れる余地がなかったが、v7 では現実的な選択肢になった。
3. コールドスタート
サーバーレスで効く指標。公式ブログと第三者記事（InfoQ 等）の計測を合わせると、概ね次のようになる。
コールドスタート時間（Lambda / Workers での実測系、概算）：
v6 時代（Rust バイナリ）：
- バイナリロード + OpenSSL 初期化 + 接続確立
- 典型 500〜800ms、複雑なケースでは 1s 超
v7：
- WASM インスタンス化 + Driver Adapter 初期化 + 接続確立
- 典型 100〜200ms、条件が良ければ 90ms 台
改善率：おおよそ 3〜9 倍コールドスタートはネットワーク条件や DB 側の準備時間にも左右されるので、自分の環境で測るのが基本。ただし「Rust バイナリのロード時間分」がなくなるだけで、数百 ms の固定コストが減るのは大きい。
4. TypeScript 型チェック：開発体験の最大改善点
ここを最も評価している開発者は多い。スキーマが大きいほど効く。
公式発表の型システム改善：
✅ スキーマ評価で生成される型の数 〜98% 削減
✅ クエリ評価で生成される型の数 〜45% 削減
✅ フル型チェック 70% 高速化体感できる場面
大規模スキーマ（50+ モデル）のプロジェクトで起きていたこと：
- tsc の初回フル型チェックに 30〜60秒
- VSCode の補完がカクつく
- IDE でホバーすると数秒フリーズ
- PrismaClient の型が「赤くならないと気が済まない」
v7 でこれが：
- tsc 初回 10〜20 秒
- 補完は即応
- ホバー遅延なしPrisma 公式は Drizzle との型チェック速度比較記事 で「v7 は Drizzle より型チェックが速い」と主張している。この主張については第三者の追試が分かれるところだが、少なくとも「v6 より v7 の方が速い」ことは広く追認されている。
5. Drizzle・Kysely との比較
「じゃあ結局、今から選ぶなら？」という問いには、一次情報だけでは答えきれないので、二次情報（第三者ベンチマーク、比較記事）を合わせて参考値として提示する。
比較サマリー（2026 年 4 月時点の概算）
| 指標 | Prisma v7 | Drizzle | Kysely |
|---|---|---|---|
| バンドルサイズ | ~1.6MB | ~7KB（極小） | ~80KB |
| コールドスタート | ~90ms | 10〜20ms | 20〜40ms |
| 型チェック速度 | 高速（公式主張） | 中〜遅（大規模時） | 高速 |
| 開発体験（補完・ドキュメント） | 最強 | 強い | やや地味 |
| マイグレーション | 公式ツール充実 | drizzle-kit で可 | 別ツール必要 |
| GUI（Studio） | 有（v7 刷新） | Drizzle Studio（別） | なし |
| リアルタイム / 接続プール | Pulse / Accelerate | 自前 | 自前 |
選定の目安
Prisma v7 を選ぶと良い：
✅ 大規模スキーマ・チーム開発・長期運用
✅ 型補完 / ドキュメント / GUI を重視
✅ マイグレーション運用まで公式ツールで揃えたい
✅ Accelerate / Pulse / Prisma Postgres を使う
Drizzle を選ぶと良い：
✅ バンドルサイズが最優先（Workers 等の極小環境）
✅ SQL に近い書き味でも構わない
✅ ORM の抽象を最小化したい
Kysely を選ぶと良い：
✅ 型安全な SQL ビルダが欲しい（完全 ORM は求めない）
✅ スキーマをコードで生成しない派v7 によって、Prisma が「遅い・重い」という Drizzle 推しの主要な論拠が相当程度無効化されたのは事実。ただし「数 KB と 1.6MB」「10ms と 90ms」の差は依然残り、エッジ極小環境では Drizzle のほうが有利な場面もある。
6. ベンチマークを読むときの注意
数字を見るときに気をつけたい点を三つ。
① 「倍速」はシナリオ依存
11 倍という数字は特定のクエリ形状での結果。自分のワークロードがそれに近いとは限らない。必ず自分のクエリでベンチする。
② 環境変数の比重が大きい
DB までの RTT、コネクションプールの暖まり具合、Driver Adapter の実装差（pg / postgres.js / @neondatabase/serverless）で結果が揺れる。公式ベンチは「同一条件で Rust 版 vs v7」を比較しているので、公平性は保たれているが、「あなたの本番環境」には違う要素がある。
③ 最悪ケースに目を向ける
平均 3 倍速くなっても、p99 が悪化していないかは別問題。大規模なクエリで GC プレッシャーが増えるケースはありうる。v7 では多数のクエリを TS 側で組み立てるので、オブジェクト生成コストは増えている。現状、公式は平均値でアピールしているが、自前の負荷試験で p95 / p99 を確認するのが安全。
本章のまとめ
✅ クエリ実行：
- 単純な findMany 25k：2.1〜3.4 倍
- include 付き m2m 大量：11 倍
- 複雑な JOIN：1.6 倍
- 小さなクエリは互角（Rust が微差で勝つケースあり）
✅ バンドルサイズ：14MB → 1.6MB（-90%）
サーバーレス・コンテナ・エッジで恩恵が大きい
✅ コールドスタート：500〜800ms → 90〜200ms（3〜9 倍）
✅ 型チェック：70% 高速、スキーマ型数 98% 削減
→ 大規模スキーマで最も体感できる勝ち筋
✅ 競合比較：
- Drizzle：バンドル / コールドスタートで依然優位
- Kysely：軽量 SQL ビルダとして別領域
- Prisma v7：「重さ」の論拠を相当無効化した
✅ 注意点：
- 自分のクエリで測る
- p95 / p99 を確認するここまでで「Why（Ch.1〜4）」「What（Ch.5）」「数字（Ch.6）」が揃った。次章は角度を変えて 「How」──どうやってこれを OSS として世に出したのかを見る。Manifesto の告白から、3 ヶ月ロードマップ、Early Access、GA、そしてデフォルト化まで、18 ヶ月の段取りは OSS メジャーバージョンアップの教科書的事例である。