Next.js + Prisma は CRUD 開発の生産性と型安全性に優れています。一方で、 pg/sql（例: node-postgres やサーバレス対応の SQL タグ） を併用した方が ベストプラクティスとなる場面も確かに存在します。使い分けの判断軸を整理します。
Prisma で十分なケース
- 典型的な CRUD、集計が軽微で OR マッピングの利点が大きい
- スキーマ駆動での保守性・ポータビリティ（DB 移行含む）を優先
- 移行（migrate）や型付けされたクエリ、バリデーションを統一したい
- 接続管理を簡素化したい（Data Proxy/Accelerate 等の活用）
pg/sql を選ぶべき条件
- 高難度クエリ: 複雑な CTE、ウィンドウ関数、JSONB/全文検索、部分インデックス等を多用
- パフォーマンス: ストリーミング/カーソル、バルク挿入、プリペアド文最適化が必要
- レポーティング: 分析・BI 向けに SQL 主体の最適化が継続的に発生
- 互換性: 既存の生 SQL 資産を再利用、または DB 固有機能を直接活用したい
- Edge/Serverless: Node の `pg` が使えない環境では、
@neondatabase/serverlessや@vercel/postgresのsqlを選択
結論: 大半は Prisma、ホットパスや分析系は pg/sql。
1 プロジェクトでの併用は実務で一般的です。
Next.js での実践パターン
構成のすすめ
- Prisma を標準データアクセスに、
lib/sql/に pg/sql ベースのクエリを分離 - コネクションは環境に合わせて統一（Serverless は Data Proxy や serverless driver）
- クエリは必ずパラメータ化（テンプレートタグの変数埋め込みで SQL インジェクションを防止）
サーバレス向け SQL タグ例（Neon）
# 例: @neondatabase/serverless
npm i @neondatabase/serverless
// app/api/users/route.ts（概念例）
import { sql } from '@neondatabase/serverless'
export async function GET() {
const rows = await sql`select id, name from users order by id desc limit 20`
return new Response(JSON.stringify(rows), { headers: { 'content-type': 'application/json' } })
}
運用上の注意
- Serverless + RDB は接続数・コールドスタートの影響が大きい。PGBouncer/データプロキシ/サーバレスドライバを検討
- Edge Runtime は Node API 非対応。
pgは不可、serverless driver を用いる - 監視: スロークエリ・ロック・接続数の可視化。アラート閾値を運用に合わせて設定
最適解はユースケース依存です。まず Prisma で組み、ボトルネック部分を pg/sql に切り出すのが現実解。
← トップへ戻る