昨年の春、SaaS側プロジェクトの3週間目で、Supabaseをセットアップしていた時、十字路に立たされました。DrizzleかPrismaか。Seahawkで40以上のクライアント構築でPrismaを使った経験がありました。居心地の良い領域です。しかしプロジェクトの後輩開発者がDrizzleを推し続けていました。正直なところ、最初は少し軽視していました。「新しいし、実績も少ない。Prismaにしよう。」
軽く流すべきではありませんでした。
結局、同じコードベースの異なる部分で両方を試しました（雑ですが、勉強になります）。学んだことはORM選択について、私の考え方を完全に変えました。Supabaseで構築していて、どちらを選ぶか本当に迷っているなら、これが私が欲しかった記事です。
---
あなたが実際に選ぶもの
これら2つのツールは同じ表面的な問題を解決します。データベースに触れるたびに生SQLを書きたくないということです。しかし、根底にある哲学はまったく異なります。
Prismaはあなたのスキーマを唯一の情報源として扱います。schema.prismaファイルを定義し、prisma generateを実行し、完全型付きクライアントを取得します。SQLをほぼ完全に抽象化します。テーブルと結合で考えることはめったにありません。モデルとリレーションで考えます。
Drizzleはかなりサーバー側のSQLに近い場所にあります。スキーマはTypeScriptで定義され、クエリはSQLのように見え、その中に別のCLI生成クライアントはありません。「SQLのように感じるTypeScript ORM」と説明されており、それは本当に正確です。
どちらが客観的に優れているわけではありません。完全に終わりです。選択は、あなたのチーム、クエリパターン、およびSupabase独自のツールに重い仕事をさせることをどの程度信頼するかに依存します。
---
Supabaseコンテキストはすべてを変えます
ほとんどの比較記事が見逃していることはここです。Supabaseはブランクなpostgresデータベースではありません。行レベルセキュリティ、リアルタイムサブスクリプション、自動生成されたREST API、GraphQL API、および独自のJavaScriptクライアントが付属しています。ORM に触れる前に、すでにsupabase-jsを通じて多くのことをしていることが多いです。
つまり本当の問題は「どのORMが優れているか」ではなく「クエリロジックをORMで処理すべきか、それともSupabaseクライアントで直接処理すべきか」ということなんです。
Prismaを選んでsupabase-jsをほぼ無視し、RLSポリシーが発動していない理由に困惑するチームを何度も見てきました。原因はPrismaが接続文字列を使ってPostgresに直接接続するからです。Supabase PostgRESTレイヤーをバイパスしてしまいます。RLSルールが強制されるのは、セッションレベルでPrismaに`SET LOCAL role = authenticated`を実行させる場合だけです。セットアップ自体は難しくありませんが、それが必要なことを知っていなければ話になりません。
Drizzleも同じ問題を抱えています。Postgresへの直接接続で、同じバイパス動作を示します。ただしDrizzleはよりSQL的な感触なので、開発者はSupabase抽象化ではなく生のPostgresと話しているという認識が強い傾向にあります。
---
バンドルサイズとコールドスタート：サーバーレス論の視点
Vercel Edge Functions、Cloudflare Workers、あるいは標準的なVercel Serverless Functionsにデプロイしている場合、バンドルサイズは実際の懸念事項です。
Prismaの生成クライアントは…重いです。クエリエンジン単体がバイナリで、デプロイメントに同梱されます。ある時期Prismaのデプロイメントはに40MBを超えるバンドルを生成していました。Prisma AccelerateとNewer Engineオプションでかなり改善されましたが、それでも重さで不利な状況が残っています。2023年後半にShawkで送出したあるFinTechプロジェクトではサーバーレス関数のコールドスタートが明らかに遅くなりました。計測値は：Prismaではおよそ800msのコールドスタート、Drizzleに移行した特定サービスは200ms未満でした。
Drizzleは小さいです。本当に信じられないほど小さい。バイナリエンジンなし。ランタイムコード生成なし。最小限のJavaScriptにコンパイルされてデプロイメントがスリムなままです。Edgeランタイムにとっては、今のところ明白な選択肢です。
ただし伝統的なNode.jsサーバー（Express、Fastify、通常のVPS上の標準的なNext.jsアプリ）を実行している場合、このギャップはずっと重要性が低いです。永続接続プールはコールドスタートを気にしません。
---
開発者体験：Prismaまだ優位な領域
率直に言います。Prismaの開発者体験は比較しがたいレベルです。
スキーマファイルは本当に心地よく作業できます。マイグレーションは`prisma migrate dev`で処理され、うまくいきます。Prisma Studio（GUI）はSupabaseダッシュボードでデータを素早く検査する必要があるときに何時間も無駄にするのを救ってくれました。生成されたクライアントから出力されるTypeScriptの型は十分です。ネストされたリレーション、`where`句、`select`形状でオートコンプリートが得られます。
DrizzleのTypeScriptサポートも優れていますが、事前準備が必要です。TypeScriptファイル内にスキーマを書きますが、哲学的には実はこれが好きです。別の`.prisma`構文を学ぶ必要がありません。ですがクエリビルダーは慣れが必要です。集計を伴う複雑なJoinなどはPrismaの`include`構文ほど直感的ではありません。
スキーママイグレーション：本当の違い
PrismaはマイグレーションのSQLファイルを自動生成し、追跡します。Drizzleも`drizzle-kit`で同じことをしますが、ワークフローは少し手作業感があります。`drizzle-kit generate:pg`を実行してSQLファイルを得たら、自分で適用します（または高速プロトタイピング用に`drizzle-kit push`を使います）。魔法が少なく、コントロールが多い。
ジュニア開発者にとってPrismaは毎回勝ります。実行されているSQLが正確に何かを理解したいソロ開発者にとってはDrizzleはPrismaにはない満足感があります。
---
生クエリの力と複雑なシナリオ
2019年にクライアントから非常に複雑な集計が必要なブリーフを受け取りました：累計実行、ウィンドウ関数、条件付きグループ化。当時Prismaを使っていて、すぐに天井に当たりました。Prismaの`queryRaw`は存在しますが、抽象化されたコードベースの中に生SQLをドロップインするのはカンニングのような感じがして、型安全性をすべて失います。
Drizzleはこれをはるかにうまく処理します。ウィンドウ関数、CTE、lateral join：第一級のビルダーを持つか、SQLフラグメントにドロップインしてもTypeScriptコンテキストを失いません。本当に複雑なレポーティングまたは分析クエリを必要とするSupabaseプロジェクトでは、Drizzleはより大きな成長の余地をくれます。
ただしCRUDアプリケーション全体の80%はこの手のものを必要としません。「ユーザーが投稿を作成し、投稿にコメントがつく」プロジェクトなら、Prismaの表現力豊かなリレーションクエリはより早く書け、他の開発者も一目で読みやすいです。
---
各オプションを選ぶべきタイミング
これについてはっきり言わせてください。「客観的に正しい」答えを見つけるために自分たちを縛り上げている人が多すぎるのを見ているので。
Drizzleを選ぶなら：
- バンドルサイズとコールドスタートが重要なエッジまたはサーバーレスランタイムにデプロイしている
- チームはSQLに快適で、実行されているクエリが正確に何かの透明性を望んでいる
- プロジェクトに複雑なクエリ要件がある（レポート、分析、非標準的な集計）
- ソロ開発者または小さなチームで、抽象化のオーバーヘッドを最小限にしたい
以下の場合は Prisma を選びます：
- 接続プーリングを備えた従来のサーバーサイド Node.js セットアップを運用している
- チームにジュニア開発者がいて、スキーマファースト ワークフローの指導メリットを享受できる
- プロジェクトが CRUD 中心で、リレーショナルの複雑さが中程度である
- 成熟したエコシステムで、より多くのサードパーティ ツール、サンプル、Stack Overflow の回答が欲しい
もう一つ注記する価値のあることは：Prisma のドキュメンテーションがより優れています。かなり優れています。Drizzle のドキュメントはこの1年で大幅に改善されましたが、Prisma はより長期間にわたってチュートリアル、ガイド、コミュニティ リソースを蓄積してきました。学習しながら進める場合、その差は実在します。
---
Supabase に特化した実践的なセットアップ ノート
どちらを選ぶにせよ、Supabase に接続する際に普遍的に適用される事項があります。
- ダイレクト接続ではなく、接続プーラー URI を使用します。Supabase は PgBouncer 経由で Supabase 接続プーラーを提供します。サーバーレスの場合、常にこれを使用してください。サーバーレス向けの Prisma 推奨
DATABASE_URLは、ポート 6543 上のプーラー エンドポイントを指す必要があります。 - PgBouncer を使用するときはプリペアドステートメントを無効にします。Prisma には URL に
?pgbouncer=trueを付与する必要があります。Drizzle は Postgres.js または node-postgres 設定でprepare: falseを設定する必要があります。これをスキップすると、本番環境で意味不明なエラーが発生します。 - RLS は味方ですが、セッションを設定する必要があります。ORM クエリに RLS ポリシーを適用したい場合は、セッション レベルで Postgres ロールと JWT クレームを設定する必要があります。これは無料で得られるボイラープレート ではありません。
- Supabase の強みに逆らわないでください。認証、リアルタイム、ストレージは
supabase-jsを使用します。Supabase クライアントのフィルタリングが足りない複雑なデータ クエリでは ORM を使用します。両者は同じプロジェクト内で共存できます。
---
FAQ
Drizzle は 2024 年でプロダクション準備ができていますか？
はい。週末のサイド プロジェクトではない企業のチームがプロダクション環境で使用しています。API は 2023 年後期以降、本気の仕事に十分な安定性を備えています。単に年月による実績で Prisma をより「本番検証済み」と呼ぶかもしれませんが、Drizzle はもはやリスクではありません。
同じプロジェクトで両方を使用できますか？
技術的には可能です。私たちもこれを短期間やりました（戦略ではなく、偶然です）。やめてください。認知的なオーバーヘッドは価値がなく、2つの異なるマイグレーション システムが同じデータベースに触れるのは悪い日を招くことになります。1つを選んでください。
Prisma は Supabase Edge Functions で動作しますか？
Prisma と Supabase Edge Functions（Deno 上で実行）は複雑な関係にあります。Prisma のエンジンは Deno 内でネイティブに実行されません。Prisma Accelerate または外部プーリング セットアップを使用することで回避できますが、可動部が増えます。Drizzle は Deno 環境でこのような問題はありません。
型安全性についてはどうですか？ 比較可能ですか？
両方とも TypeScript 型を生成し、両方とも TypeScript プロジェクトとよく統合されます。Drizzle の型は TypeScript スキーマ定義から導出されます。Prisma の型は生成されたクライアントから来ます。私の経験では、Prisma のネストされたリレーション型は既製でわずかにエルゴノミックですが、Drizzle の推論がかなり追いついてきました。
ランタイム時のスピードはどうですか？
Drizzle はランタイム オーバーヘッドが少なく、クエリと Postgres ワイヤー プロトコル間の距離が短いため、本質的なパフォーマンス優位性を持っています。ベンチマークでは、その差は測定可能です。ほとんどの実際のアプリケーションでは、データベースへのネットワーク レイテンシーに埋もれます。主に生のクエリ速度で ORM を選ばないでください。
---
実際の答え
エッジ/サーバーレスのSupabaseプロジェクト、またはメタルに近い状態を保ちたい場所ではDrizzleを。チーム環境、CRUD操作が多いアプリ、開発者のオンボーディング速度が重要な場面ではPrismaを。
1年前と比べて、今はDrizzleをより多く使っています。ただ、Prismaに費やした年月を後悔していません。それは私をより優れた開発者にしてくれました。十分に意見的だったため、その限界に直面する理由を理解する必要があったからです。
どちらもプロジェクトを左右することはありません。あなたのスキーマ設計が左右します。インデックス設計の決定が左右します。チームの人間に合ったものを選んで、構築を始めましょう。