2024年後半、Canary Wharf のフィンテッククライアント向けSaaSプロジェクトに3週間入っていた。アプリは Next.js 14 ダッシュボードで、小規模事業主向けの財務サマリーを引っ張ってくるものだった。Vercel Postgres へのデフォルト選択は、それがVercel ダッシュボードに右にあり、僕が高速で進めていたからだ。6週間後、初日から無料で手に入っていたはずの行レベルの認証ロジックを手作業で配線していた。それは大体2スプリント分の余分なコストがかかった。理想的ではない。
だから直接言いたい：SupabaseとVercel Postgresは同じ仕事のために戦う等価なツールではない。一方は完全なバックエンドプラットフォーム。もう一方は素敵なDXラッパーを備えた管理されたPostgresインスタンスだ。間違ったものを選んでもアプリは壊れないが、それを使う時間の全てに静かに負荷がかかる。
Seahawk Mediaのクライアントプロジェクト全体で両方を本番運用して実際に学んだことをここに示す。
---
実際のところ何なのか（マーケティング版ではなく）
Vercel Postgres
Vercel Postgres は 2023 年にローンチされ、サーバーレス Postgres 企業である Neon の上に構築されています。これは重要な点で、しばしば見落とされています。基本的には、Neon のデータベースに Vercel 風の SDK を重ねた上で、課金を Vercel プランに統合したものです。
何が手に入るか：PostgreSQL データベース、@vercel/postgres 経由のエッジ対応接続プーリング、Vercel の環境変数システムとの緊密な統合です。SQL を書くか、その上で Drizzle や Prisma を使うかのいずれかです。基本的にはそれだけです。
Supabase
Supabase はまったく別物です。内部的には Postgres ですが、auth（GoTrue 経由）、リアルタイムサブスクリプション（Phoenix チャネル経由）、ファイルストレージ、エッジ関数、PostgREST ベースの自動生成 REST API を備えたプラットフォームでラップされています。どのようにして各ピースが適合するかを理解したければ、Supabase のアーキテクチャドキュメントを読む価値があります。単なるデータベースではなく、意見を持ったバックエンドスタックを選択しているのです。
この区別はプロジェクトのスコープを決める際に即座に重要になります。Vercel Postgres では、auth、ストレージ、API レイヤーをすべて自分で構築し続けることになります。Supabase では、その相当な部分がすでに揃っています。
---
開発者体験：初日 vs 3 ヶ月目
Vercel Postgres の初日は本当に速いです。ダッシュボードで「Create Database」をクリックして、env 変数をコピーして、@vercel/postgres をインストールして、最初のクエリを書くのに約 8 分で完了します。一度測ってみたことがあります。Vercel エコシステムにすでに住んでいれば、摩擦がまったくありません。
Supabase の初日も速いですが、理解する必要のあるサーフェスエリアが広いです。ダッシュボードが濃密です。テーブルエディタ、auth 設定、RLS ポリシー、ストレージバケット、エッジ関数、ユーザーデータの 3 つのテーブルを保存したいだけなのに、多く感じることがあります。
ただし、3ヶ月目に状況は逆転する。Vercel Postgresではギャップを埋めるためにサードパーティパッケージを常に探すことになる。認証にはClerkやNextAuth、ファイルストレージにはUploadthingやS3、リアルタイムにはPusherといった具合だ。各統合は依存関係を増やし、新しい請求項目が増え、新たな障害ポイントが生まれる。Supabaseの場合、こうした機能はすでに組み込まれており、ネイティブに相互作用する。
去年Seahawk Mediaで、フィットネスブランド向のコミュニティプラットフォームプロジェクトを担当した。リアルタイムリーダーボード更新とユーザー生成コンテンツのアップロード機能が必要だったため、Supabaseを選んだ。これらの機能を2週間で公開できた。同じプロジェクトをVercel Postgresで実装した場合、Pusher、S3、Clerkを一から組み立てる必要があるため、最低でも4週間はかかっていただろうと確信している。
---
パフォーマンスとスケーリング
どちらもPostgresを実行している。したがって、一般的なウェブアプリの負荷に対する生のクエリパフォーマンスは、差別化要因にはならない。どちらも接続プーリングをサポートしている。どちらも正しくインデックスされていれば、数百万行を難なく扱える。
本当のパフォーマンスの話は、アーキテクチャについてだ。
Vercel Postgresはボンネットの下ではNeonで、コンピュートとストレージが分離されたサーバーレスネイティブなアプローチを使用している。コールドスタートは現実の問題だ。フリーティアとホビティアでは、データベースが一定期間アクセスされていない場合、新しい接続の最初のクエリは500ms以上かかることがある。予測可能なトラフィックを持つダッシュボードアプリであれば問題にならない。散発的なユーザーを持つコンシューマーアプリの場合、目に見える問題になる。
Supabaseは専用インスタンスで実行される（有料プランではPgBouncer経由のプール接続）。同じようなコールドスタートは起きない。Supabaseの接続プーリングガイドでは、プランごとにPgBouncerがどのように設定されるかが明記されている。フリーティアでは60のデータベース接続が得られる。Proでは200が得られる。アプリをそれ以上にスケールさせると、Supavisor（彼らの新しいプーラー）か、PgBouncerのトランザクションモードのような外部ツールを検討することになる。
月間アクティブユーザー10,000人以下の典型的なSaaS アプリでは、どちらのプラットフォームもボトルネックにはならない。それを超えた場合、会話は変わるし、とにかく独自の負荷テストを実施すべきだ。
---
料金設定：ここが面白くなるところ
ここで多くの人が引っかかるのを見ます。
Vercel Postgres の料金設定（2025～2026年時点）：
- Vercel Pro に月額 $20 で含まれる（制限あり）
- Pro では 256MB のストレージ、その先は 1GB あたり $0.30
- コンピュートは使用量に応じてスケール
Supabase の料金設定：
- 無料ティア：500MB のデータベース、1GB のファイルストレージ、認証用の月間 50,000 アクティブユーザー
- Pro：月額 $25、8GB のデータベース、100GB のファイルストレージ、100,000 MAU
すでに Vercel Pro に支払っている場合、データベースはバンドルされているため「無料」に見えます。心理的には魅力的です。しかし月額 $25 の Clerk、Uploadthing、Pusher を追加した瞬間、あなたの「無料」データベースは実際には月額 $80 以上の関連ツール代がかかっているのです。
Supabase Pro（月額25ドル）はそのほとんどを置き換えます。中規模プロジェクトの場合、データベース行項目は高く見えても、月間総支出ではSupabaseが有利なことが多いです。
正直な注釈として：認証の複雑性がなく、リアルタイムが不要な純粋にサーバーレスAPIルートのみを実装するソロデベロッパーなら、Vercel Postgresは本当に安くてシンプルです。使わない機能に金を払う必要はありません。
---
Next.js統合：実践的な部分
どちらのデータベースもNext.js App RouterおよびServer Actionsでよく機能します。ただし統合の感覚が異なります。
Vercel Postgresの場合、パターンは通常以下の通りです：
- Server ActionまたはRoute Handlerを書く
@vercel/postgresからsqlをインポート- クエリを実行
- コンポーネントにデータを返す
シンプル。使い慣れている。Drizzle ORM との相性が素晴らしい。約18ヶ月間、Drizzle をデフォルト ORM として使ってきたが、Vercel Postgres とペアで使う際は全く問題がない。
Supabase の場合、Next.js での典型的なパターンは以下の通りだ：
- Supabase クライアントを作成する（サーバーサイドで
@supabase/ssr経由） - クライアントを使ってクエリを実行するか、自動生成される REST API を呼び出す
- 必要に応じて RLS を使い、データベースに認可を直接処理させる
@supabase/ssr パッケージは 2023 年のローンチ時は荒削りなところがあった。今は大幅に改善されている。以前は Next.js ミドルウェアで認証クッキーフローをセットアップするのにカスタム実装が必要だったが、現在のドキュメントではシンプルに対応している。とはいえ、Vercel Postgres よりはセットアップが多い。その点は最初から理解しておこう。
Next.js における Supabase で本当に気に入っている点は、Row Level Security のおかげで、Server Action 内でデータベースクエリを書く際に、誤って他のユーザーのデータを公開してしまわないか心配する必要がないということだ。認可ロジックはデータベース内に存在し、アプリケーションコード全体に散らばらない。マルチテナントアプリにおいて、これは本当のアーキテクチャの勝利だ。
---
Vercel Postgres を選ぶべき時
- シンプルなコンテンツサイト、ブログ、認証要件のない内部ツールを構築している（あるいは認証を別途で処理することに満足している）
- Vercel エコシステムに既に深く関わっていて、バンドル価格が理にかなっている
- チームが SQL をよく知っていて、生のクエリを書くか Drizzle を使いたい、抽象化のオーバーヘッドがない状態で
- 素早くプロトタイピングしていて、90日後にインフラを再評価することが分かっている
---
Supabase を選ぶべき場合
チェックリストとして使ってください。3つ以上にチェックが入れば、Supabase を選んでください：
- ユーザー認証が必要である（メール/パスワード、ソーシャル OAuth、マジックリンク）
- リアルタイム機能を構築している：ライブフィード、協調編集、プレゼンスインジケータ
- S3 ポリシーを設定することなくファイルストレージが欲しい
- 行レベルのデータ分離が重要なマルチテナント SaaS を構築している
- バックエンドの課題が既に解決されていることを想定し、素早く進めたいと考えている
- ダッシュボードを使ってデータを検査する開発者以外のステークホルダーがプロジェクトにいる
2025年にSupabaseを不動産リスティングプラットフォームで使用しました。クライアントは、エージェントが画像をアップロードし、買い手がリアルタイムでお気に入りを保存でき、基本的なレポート機能を持つ管理パネルが必要でした。認証、ストレージ、リアルタイム、RLS、すべてカバーできました。Supabaseの組み込みテーブルエディタをクライアントがリスティングを直接管理するために使用しました。カスタム管理パネルは不要でした。これだけで1週間を節約できました。
---
ベンダーロックインの問題
名前を付ける価値があります。どちらのオプションも特定のインフラに結びついていますが、その方法は異なります。
Vercel Postgres（Neon）を使う場合、データはNeonデータベースにあります。Neonは実際には十分にオープンなため、自前でホストするPostgresインスタンスへの移行は実行可能です。pg_dumpを使い、新しいホストを指定すれば、完了です。ロックインは実際にはデータそのものではなく、Vercelのデックス層です。
Supabaseの場合、データベースのロックインは同様です（結局Postgresですから）が、プラットフォームのロックインはより顕著です。認証はGoTrue、ストレージはSupabase Storage、リアルタイムはPhoenixチャネルの設定です。これらすべてを別のスタックに移行するには1週間以上の作業が必要です。これは正当な代償として認識する価値があります。Supabaseはdocker経由の自己ホスティングを提供しており、Supabase自己ホスティングガイドを参照してください。これでベンダーの懸念を幾分軽減できます。
どちらも壊滅的なロックインではありません。しかし、3年後に完全に自分のものにする必要があるものを構築しているのであれば、この点をこの議論に組み込んでください。
---
よくある質問
SupabaseはFirebaseにPostgresを組み合わせただけですか?
大体そうですが、その説明ではPostgresの価値を過小評価しています。FirebaseはFirestoreを使っていて、これはドキュメントデータベースで独自のクエリモデルを持っています。Supabaseは完全にリレーショナルなデータベースを提供していて、結合、トランザクション、外部キー、Postgresを使う価値のあるすべての機能が含まれています。Firebaseとの比較は主に「バッテリー付属」という哲学についてのものです。SQLを知っていて、リレーショナルデータモデルを構築しているなら、SupabaseはFirebaseよりもずっと快適に作業できる場所です。
Supabaseの認証システムを使わずにSupabaseを使用できますか?
できます。Supabaseを管理されたPostgresデータベースとして純粋に使用して、ClerkやNextAuthで独自の認証を接続できます。そうしているチームもあります。正直なところ、その判断は疑問です。プラットフォームの代金を払っているのに、最も時間を節約できる機能を使っていないわけですから。ただし、認証プロバイダーについて強い意見があるなら、有効なアーキテクチャ上の選択肢です。
Vercel PostgresはPrismaで動作しますか?
動作します。@vercel/postgresパッケージはPrismaの標準PostgresコネクタでPrismaと連携します。環境変数でDATABASE_URLを設定すれば、Prismaはその背後にあるものを気にしません。私はVercel Postgresを2つのプロジェクトで使用しました。今は型安全性とマイグレーション専用サーバーが不要なDrizzleの方が好みですが、Prismaは完璧に機能します。
ソロのインディ開発者で予算が限られている場合、どちらがより良いですか?
Supabaseの無料レベルは本当に気前が良いです。500MB のストレージ、認証込み、リアルタイム機能込みです。サイドプロジェクトや初期段階のプロダクトなら、これ以上に良いものを見つけるのは難しいです。Vercel Postgresの無料レベルはもっと制限されていて、本当の価値はVercel Proにすでに加入している場合にだけ現れます。もし明日パーソナルプロジェクトを始めるなら、迷わずSupabaseを選びます。
Vercel Postgresの代わりに、Neonを直接使うのはどうですか?
いい質問だ。Vercel PostgresはNeonの上に構築されているから、仲介者を排除してNeonを直接使うことができる。プラン選択の柔軟性が高くなり、ブランチング機能（プレビュー環境向けのNeonのデータベースブランチングは本当に優秀だ）が使え、Vercelの価格パッケージに縛られない。Vercel Postgresをデータベース機能メインで使っていて、エコシステム統合を活用していないなら、公式のNext.js統合経由でNeonを直接使うことを本気で検討する価値がある。
---
正直なところ：Vercel Postgresは、判断を減らしたいVercelネイティブなプロジェクト向けの優れたデータベースだ。Supabaseはバックエンドプラットフォームであって、たまたま優れたデータベースを含んでいるだけだ。まずプロジェクトのスコープを定義してから、実際に構築している内容に合ったツールを選ぶ。私は逆方向で進めてスプリントを無駄にしたことがある。おそらく君も同じ失敗をする必要はないだろう。
関連記事：2026年のAI検索キーワードリサーチ：それは何か、なぜ従来の、技術的SEO、およびAI検索。