100K以上のレコードを持つWebサイト向けベストデータベース: Supabase vs Firebase vs PlanetScale テスト比較
大多数「Supabase vs Firebase」の記事は、各プラットフォームでtoDoアプリをさっと作成して終わりにしている人によって書かれています。私は1年以上にわたり、Supabase PostgreSQLで5つの本番ウェブサイト上に253,000以上のレコードを運用してきました。Firebase Firestore、PlanetScale、Neon、Tursoを実際のクライアントプロジェクト（仮説的なものではなく）に対して評価しました。これが私が実際に発見したことです。
100K以上のレコードを処理する必要があり、複雑なクエリ、リアルタイム機能、認証を必要とするウェブアプリケーションを構築している場合、データベースの選択は今後数年間のアーキテクチャを定義します。間違った選択をすると、6ヶ月以内にデータレイヤーを書き直すか、本来よりも3倍の費用を支払うことになります。私はあなたをその両方から救いたいのです。
目次
- この比較が存在する理由
- 競合者を一目で見る
- Supabase PostgreSQL：私たちの本番環境の主力
- Firebase Firestore：勝つ場面と勝たない場面
- PlanetScale：素晴らしいデータベース、不完全なプラットフォーム
- Neon：純粋主義者の選択
- Turso：エッジファースト SQLite
- 機能の詳細比較
- 100K以上のレコードでのパフォーマンスベンチマーク
- 100K レコード ワークロードの価格内訳
- どのデータベースを選ぶべきか？
- FAQ
この比較が存在する理由
Social Animalでは、ヘッドレスウェブアプリケーションを構築しています。主にNext.jsとAstroを使用して、動的でデータが豊富なサイトが必要なクライアント向けです。50K以上のリスティングを持つエンタープライズディレクトリ、何千ものページを生成するプログラム的SEOサイト、リアルタイム更新が必要なSaaSダッシュボードを考えてください。
100K以上のレコードを含むプロジェクトでクライアントが来たとき、データベースの会話は初日に行われます。それは事後考です。データベースの選択は、認証戦略、APIの設計、ホスティングコスト、そして6ヶ月後に機能を出荷する能力に波及します。
5つのデータベースすべてで同一の本番ワークロードを実行したふりをするつもりはありません。それは不正直です。私がしたことは、Supabase（253K以上のレコード、5つのサイト、14ヶ月）での真剣な本番運用と、特定のクライアントプロジェクト向けの選択肢の徹底的な技術評価です。どのデータが本番から来たのか、どのデータが評価から来たのかをはっきりさせます。
競合者を一目で見る
深く掘り下げる前に、ここは簡単な絵です：
- Supabase -- バッテリー付きのPostgreSQL（認証、ストレージ、リアルタイム、エッジ関数）
- Firebase Firestore -- Googleの NoSQLドキュメントデータベースで、優れたモバイルSDK
- PlanetScale -- データベースブランチを使用したサーバーレスMySQL（Vitessを搭載）
- Neon -- ブランチとゼロへのスケーリングを備えたサーバーレスPostgreSQL
- Turso -- エッジで分散されたSQLite（libSQLによって搭載）
それぞれは何か本当に得意です。質問は、その何かがあなたが構築しているものと一致するかどうかです。
Supabase PostgreSQL：我たちの本番環境の主力
Supabaseから始めます。最も深い経験がそこにあるからです。5つの本番サイト全体で、最大のテーブルは137Kの行（ディレクトリプロジェクト用の全国アドレスシステム）を有し、すべてのデータベース間で253K以上の総レコードがあります。
毎日使用するもの
**行レベルセキュリティ（RLS）**は、おそらく私たちの決定に影響を与えた機能です。マルチテナントアプリケーションを構築する場合（ほとんどのヘッドレスCMS駆動型サイトが最終的になる）、ユーザーごとのデータ分離が必要です。RLSを使用すると、セキュリティロジックはデータベース自体に存在します。APIレイヤーは、すべてのクエリでuser_idでフィルタリングすることを覚える必要がありません。データベースはそれを強制します。
ここは、プロジェクトでの典型的なRLSポリシーです：
-- ユーザーは自分の組織のリスティングのみ表示できます
CREATE POLICY "org_isolation" ON listings
FOR SELECT
USING (org_id = (SELECT org_id FROM profiles WHERE id = auth.uid()));
-- 管理者はすべてを表示できます
CREATE POLICY "admin_access" ON listings
FOR ALL
USING (EXISTS (
SELECT 1 FROM profiles
WHERE id = auth.uid() AND role = 'admin'
));
これは本当のSQLです。独自のDSLではありません。Supabaseを離れる必要がある場合、これらのポリシーはPostgreSQLホストに変換されます。
pgvectorは意味検索の啓示です。従来の全文検索が十分でなかったコンテンツが豊富なサイトに実装しました。ユーザーは「ダウンタウン付近で食べる場所」を検索して、レストラン、カフェ、フードトラック（これらの正確な単語がリスティングに含まれていなくても）を含む結果を期待するでしょう。
-- ベクトル列を作成する
ALTER TABLE listings ADD COLUMN embedding vector(1536);
-- インデックスを作成する（100K以上のレコードで非常に重要）
CREATE INDEX ON listings USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);
-- 意味検索クエリ
SELECT id, name, 1 - (embedding <=> $1) AS similarity
FROM listings
WHERE 1 - (embedding <=> $1) > 0.78
ORDER BY embedding <=> $1
LIMIT 20;
1536次元ベクトルを備えた137Kレコードで、このクエリはSupabaseのProプランで約45msで戻ります。これはリアルタイムの検索タイプに十分に高速です。
PostGISジオクエリは、場所ベースの機能を強化します。半径内のリスティングを見つけ、距離でソートし、運転時間を計算する - すべてがアプリケーションコードではなくデータベースレベルで処理されます。
-- ポイントから10km以内のリスティングを見つけ、距離でソートする
SELECT id, name,
ST_Distance(location, ST_MakePoint(-73.9857, 40.7484)::geography) AS distance_m
FROM listings
WHERE ST_DWithin(
location,
ST_MakePoint(-73.9857, 40.7484)::geography,
10000
)
ORDER BY distance_m
LIMIT 50;
リアルタイム購読により、WebSocketインフラストラクチャなしでライブダッシュボードを構築できます。クライアントの管理パネルは関連するテーブルのINSERTイベントをサブスクライブするため、新しい送信が即座に表示されます。追加のインフラなし。
完璧ではないもの
Supabaseが完璧であるふりをしません。100K以上の行を含むテーブルを閲覧している場合、ダッシュボードは遅い場合があります。テーブルエディタは小さなデータセットには適していますが、一括操作には苦痛です。直接SQLを使用する必要があります。Edge関数はDenoを搭載しているため、一部のNode.jsパッケージは動作しません。サーバーレス環境の接続プーリングが必要な場合は、Supavisor接続文字列を使用する必要があります（2025年初頭の時点でPgBouncer廃止）。
また、無料層は開発用に本当に寛大ですが、500MBのデータベーススペースのハード制限があります。100K以上のレコードでの本番環境では、最低でもProプラン（月額$25）を探しています。
Firebase Firestore：勝つ場面と勝たない場面
2024年にFirebaseを2つのクライアントプロジェクトについて真剣に評価しました。1つはオフライン同期要件を持つモバイル優先アプリケーションでした。もう1つは複雑なフィルタリングを備えたディレクトリサイトでした。
Firebaseが本当に勝つ場所
モバイルアプリケーション用のFirebaseのリアルタイム同期は、依然としてクラス最高です。オフライン永続性、自動競合解決、iOS/Android SDKとの緊密な統合により、プライマリプラットフォームがモバイルの場合の明白な選択肢です。Google Auth統合は簡単です - 数行のコードでGoogle、Apple、電話番号、メール/パスワードでのサインインが完了しました。
Firebase Crashlytics、Remote Config、Analyticsは、他の何物も一致しないモバイル開発エコシステムを形成します。モバイルアプリを最初に構築し、ウェブアプリを2番目に構築している場合は、Firebaseが真摯に検討する価値があります。
代わりにSupabaseを選んだ理由
Firestoreはドキュメントデータベースです。結合なし。それを一瞬沈めてください。
カテゴリ、タグ、場所、レビュー、ユーザープロフィールを持つリスティングを持つディレクトリを構築している場合、リレーショナルデータが必要です。Firestoreでは、すべてを非正規化（ドキュメント全体でデータを複製し、同期を保つことを祈る）するか、複数の往復クエリを実行してアプリケーションコードでデータを結合します。
ここは、各「カテゴリ別のリスティングを見つけ、平均的な評価を見つける」クエリです：
-- Supabase：1つのクエリ、完了
SELECT l.*, c.name AS category_name,
AVG(r.rating) AS avg_rating,
COUNT(r.id) AS review_count
FROM listings l
JOIN categories c ON l.category_id = c.id
LEFT JOIN reviews r ON r.listing_id = l.id
WHERE c.slug = 'restaurants'
GROUP BY l.id, c.name
ORDER BY avg_rating DESC
LIMIT 20;
// Firestore：3つのクエリ+クライアント側の結合
const categorySnap = await db.collection('categories')
.where('slug', '==', 'restaurants').get();
const categoryId = categorySnap.docs[0].id;
const listingsSnap = await db.collection('listings')
.where('categoryId', '==', categoryId).get();
// 各リスティングのレビューをフェッチして...
// 次に、アプリケーションコードで平均を計算する...
// その後、ソートする...あなたはアイデアを理解しています。
そして本当の問題は：Firestoreはドキュメント読み取りごとに課金されます。上記の3クエリパターン？すべてのクエリのすべてのドキュメント数。中程度のトラフィックを伴う100K以上のレコードでは、請求書は本当に予測不可能になります。予想外の$400以上の請求について聞いたことがあるか、クエリが予想よりも多くのドキュメントをスキャンしていることを開発者が実現しなかったことに気づきました。
FirestoreにはpgvectorまたはPostGISに同等のものがありません。基本的なジオハッシュクエリを実行できますが、これは近似的で、真の空間インデックスと比べて制限されています。
PlanetScale：素晴らしいデータベース、不完全なプラットフォーム
PlanetScaleは、フードの下でVitessを実行します - YouTubeのデータベースを強化するのと同じ技術。純粋なMySQL パフォーマンスの場合、それは優秀です。スキーマ変更を行い、戻すことができるデータベースブランチ機能（ブランチを作成する）は本当に革新的で、Supabaseが本来持っていたものです。
PlanetScaleが上手いこと
サーバーレスドライバは高速です。接続管理はあなたのために処理されます。これは、各関数呼び出しが新しいデータベース接続を開く可能性があるサーバーレス環境では非常に重要です。スキーマブランチにより、データベース移行はGitプルリクエストのように感じます - 安全、レビュー可能、可逆的。
MySQL の専門知識が強く、従来のウェブアプリケーションを構築するチームの場合、PlanetScale は堅実です。
不足しているもの
PlanetScale はただのデータベースです。それだけです。完全なアプリケーションスタックを構築するために必要なものを比較します：
| 機能 | Supabase | PlanetScale + エクストラ |
|---|---|---|
| データベース | ✅ 付属 | ✅ 付属 |
| 認証 | ✅ 付属 | ❌ Clerk（月額$25以上）またはAuth0が必要 |
| ファイルストレージ | ✅ 付属 | ❌ S3またはCloudflare R2が必要 |
| リアルタイム | ✅ 付属 | ❌ PusherまたはAblyが必要 |
| ベクトル検索 | ✅ pgvector | ❌ 利用不可 |
| ジオクエリ | ✅ PostGIS | ❌ 基本的なMySQL空間 |
| エッジ関数 | ✅ 付属 | ❌ 別のデプロイメントが必要 |
認証用のClerk、ストレージ用のS3、リアルタイム用のPusher、検索用の個別ベクトルデータベースを追加すると、1つの代わりに5つのサービスを管理しています。請求書は高くなり、複雑さは高くなり、デバッグの表面積は非常に大きくなります。
PlanetScale も2024年4月に無料層（Hobbyプラン）を廃止したため、エントリーポイントは現在Scalerプラン（月額$39）です。これはSupabaseプロより高く、機能が少なくなります。
Neon：純粋主義者の選択
Neonは、PostgreSQLだけが必要な場合に選ぶデータベースです。サーバーレスアーキテクチャは本当に印象的です - ゼロへのスケーリングは、データベースがクエリされていない場合は支払いがないことを意味します。ブランチ機能は、プレビュー展開に優れています（すべてのプルリクエストに対してデータベースブランチをスピンアップします）。
Neonは pgvectorとPostGIS をサポートしています。これは標準的なPostgreSQLです。したがって、ベクトル検索とジオクエリを取得します。生データベース機能はSupabaseとほぼ同じです。
それでもSupabaseを選んだ理由
Neonはデータベースです。Supabaseはプラットフォームです。Neonを使用すると、追加が必要です：
- 認証 -- Clerk、Auth0、または独自に構築する
- ストレージ -- S3、Cloudflare R2、または同様
- リアルタイム -- Pusher、Ably、またはカスタムWebSocketサーバー
- エッジ関数 -- Cloudflare WorkersまたはVercel上に個別に展開
一部のチームにとって、そのモジュラーアプローチは実際に好ましいです。認証についての意見があり（Clerkの予算がある）、すべてのS3を使用し、リアルタイムが必要でない場合、Neonの焦点を絞ったアプローチは、より少ないベンダーロックインを意味します。
しかし、ヘッドレス開発プロジェクトでは、1つのダッシュボード、1つの請求書、1つのAPIキーセットで認証、ストレージ、リアルタイムを使用することは多くの価値があります。開発者の速度は、タイトな期限でクライアントプロジェクトを出荷するときに重要です。
Neonの価格設定も競争力があります：無料層は0.5GBストレージと毎月190のコンピュート時間を含みます。月額$19のLaunchプランは10GBを提供します。純粋なデータベースプレイの場合、それはサーバーレスPostgreSQLで最良の値です。
Turso：エッジファースト SQLite
Turso は魅力的な技術です。彼らはSQLite（世界で最も展開されているデータベース）を取得し、分散させました。データはエッジに、ユーザーに近い場所に住んでいるため、読み取り遅延は非常に低い（グローバルに10ms未満）です。
Turso が輝く場所
グローバルな視聴者向けの読み取り重視のワークロード。頻繁に変わらないコンテンツを世界中のユーザーに提供している場合、Tursoのエッジレプリケーションは、データベース読み取りが即座に感じるように与えます。埋め込みレプリケー機能を使用して、SQLiteレプリケーションをアプリケーションに直接バンドルできます。
Astroで構築された軽量データレイヤーを必要とする静的のようなサイトの場合、Tursoは説得力があります。
私たちのニーズに合わなかった理由
100K以上のレコードワークロードには、重大な書き込みが含まれます - ユーザー送信、管理者の更新、レビュー作成、リアルタイムデータの変更。SQLiteの書き込みモデル（単一ライター）はスケール時のボトルネックになります。Tursoは彼らのlibSQL フォークを通じてこれをより良く処理しますが、それでも100K以上のレコードアプリケーション向けに設計されていません。
ベクトル検索なし。PostGISに相当するもの。PostgreSQLやMySQL と比べて限定されたエコシステム。ディレクトリとSaaSプロジェクトでは、これらは決裂していました。
機能の詳細比較
2025年半ばの時点で、本番経験と評価に基づいた完全な比較表は以下の通りです：
| 機能 | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| データベースの種類 | PostgreSQL | NoSQL（Firestore） | MySQL（Vitess） | PostgreSQL | SQLite（libSQL） |
| 組み込み認証 | ✅ はい | ✅ はい | ❌ いいえ | ❌ いいえ | ❌ いいえ |
| ベクトル検索 | ✅ pgvector | ❌ いいえ | ❌ いいえ | ✅ pgvector | ❌ いいえ |
| ジオクエリ | ✅ PostGIS | ⚠️ 限定的（ジオハッシュ） | ⚠️ 基本的なMySQL空間 | ✅ PostGIS | ❌ いいえ |
| リアルタイム | ✅ はい | ✅ はい | ❌ いいえ | ❌ いいえ | ❌ いいえ |
| ファイルストレージ | ✅ はい | ✅ はい | ❌ いいえ | ❌ いいえ | ❌ いいえ |
| エッジ関数 | ✅ Denoベース | ✅ Cloud Functions | ❌ いいえ | ❌ いいえ | ❌ いいえ |
| 結合/リレーション | ✅ 完全SQL | ❌ 結合なし | ✅ 完全SQL | ✅ 完全SQL | ✅ SQL（限定的） |
| ブランチ | ⚠️ マイグレーション経由 | ❌ いいえ | ✅ ネイティブ | ✅ ネイティブ | ❌ いいえ |
| ゼロへのスケーリング | ❌ いいえ | ✅ はい | ✅ はい | ✅ はい | ✅ はい |
| 価格予測可能性 | 🟢 高（フラットレベル） | 🔴 低（読み取りごと） | 🟡 中程度 | 🟢 高 | 🟢 高 |
| オープンソース | ✅ はい | ❌ いいえ | ❌ いいえ（Vitessは） | ✅ はい | ✅ はい |
| 自己ホスト可能 | ✅ はい | ❌ いいえ | ❌ いいえ | ❌ いいえ | ✅ はい |
100K以上のレコードでのパフォーマンスベンチマーク
これらの数値は、137K行を持つプライマリテーブルを使用したSupabase本番インスタンス（Proプラン、us-east-1地域）からものです。他のデータベースの場合、100K個の合成レコードを使用して公開されたベンチマークと評価テストを使用しています。
| クエリタイプ | Supabase | Firebase | PlanetScale | Neon | Turso |
|---|---|---|---|---|---|
| IDで単純SELECT | 3ms | 8ms | 4ms | 5ms | 1ms |
| フィルタリングクエリ（インデックス） | 12ms | 15ms | 10ms | 14ms | 3ms |
| 複雑なJOIN（3つのテーブル） | 35ms | N/A（結合なし） | 28ms | 38ms | 25ms |
| ベクトル類似性（上位20） | 45ms | N/A | N/A | 42ms | N/A |
| ジオ半径（10km） | 22ms | ~50ms（ジオハッシュ） | N/A | 24ms | N/A |
| 全文検索 | 18ms | N/A（Algoliaを使用） | 15ms | 20ms | 12ms |
| 一括INSERT（1000行） | 180ms | 250ms | 150ms | 195ms | 320ms |
| コールドスタート（サーバーレス） | N/A（常時オン） | ~100ms | ~50ms | ~300ms | ~20ms |
いくつかのことが目立ちます。Tursoの読み取りパフォーマンスは例外的です - SQLiteのエッジ上の利点です。PlanetScaleのMySQLエンジンはPostgreSQLの比較で結合をわずかに高速処理します。Neonのコールドスタート（300ms）は顕著です。計算を起こす必要があるため、その後のクエリは高速ですが。Firestoreの結合の欠如は、これらのクエリの一部をリテラル実行できないことを意味します。
Supabaseのオンコンピュート（Proでスケーリング不可）は、ユーザー向けのアプリケーションでは最初のリクエストが遅い場合がある、ゼロのコールドスタートを意味します。
100K レコード ワークロードの価格内訳
現実的な100Kレコードアプリケーションをモデル化しましょう：100Kのリスティング、50K月当たりのアクティブユーザー、月当たり約2M のデータベース読み取り、月当たり約50K の書き込み、5GBのデータベースサイズ、10GBのファイルストレージを持つディレクトリサイト。
| Supabase Pro | Firebase（Blaze） | PlanetScale Scaler | Neon Launch | Turso Scaler | |
|---|---|---|---|---|---|
| 基本費用 | $25/月 | $0（従量課金） | $39/月 | $19/月 | $29/月 |
| データベース | 含まれる（8GB） | ~$18（読み取りと書き込み） | 含まれる（10GB） | 含まれる（10GB） | 含まれる（9GB） |
| 認証 | 含まれる（50K MAU） | 含まれる | +$25/月（Clerk） | +$25/月（Clerk） | +$25/月（Clerk） |
| ストレージ（10GB） | 含まれる | ~$3/月 | +$2/月（R2） | +$2/月（R2） | +$2/月（R2） |
| リアルタイム | 含まれる | 含まれる | +$25/月（Pusher） | +$25/月（Pusher） | +$25/月（Pusher） |
| 推定合計 | $25/月 | ~$21/月 | ~$91/月 | ~$71/月 | ~$81/月 |
Firebaseは2つのことを実現するまで安く見えます。まず、$21の見積もりは予測可能な読み取りパターンを前提としています。ウイルスの瞬間またはボットがサイトをクロールする場合、読み取りが大幅に急増する可能性があり、請求書も増加します。次に、ベクトル検索のような機能が必要になると、PineconeやWeaviateを追加します。これは月額$70から始まります。
Supabaseの平坦な月額$25（すべてのデータベース、認証、ストレージ、リアルタイム、エッジ関数）は、このワークロードサイズで驚くほど良い価値です。Proプラン には8GBデータベース、250GB帯域幅、100GBストレージ、認証用の50K月当たりアクティブユーザーが含まれます。
どのデータベースを選ぶべきか？
これらのツールを使用して構築することに基づいた正直な推奨は以下の通りです：
Supabaseを選ぶ場合、リレーショナルデータを含むウェブアプリケーションを構築している場合、1つのプラットフォームで認証+ストレージ+リアルタイムが必要な場合、PostgreSQLのエコシステム（pgvector、PostGIS、全文検索）が必要な場合、またはNext.jsで構築している場合。これは、おそらく私たちが見るプロジェクトの80%をカバーしています。
Firebase を選ぶ場合、オフライン同期が重要で、モバイルファーストアプリケーションを構築している場合、チームが既にFirebaseエコシステムを知っている場合、またはデータが真にドキュメント形状（チャットメッセージ、アクティビティフィード、単純なユーザープロフィール）。
PlanetScale を選ぶ場合、強いMySQL チームがある場合、複雑なスキーマ管理用のデータベースブランチが必要な場合、および認証とストレージの別のサービスを既に使用している場合。それはすでにプラットフォームの一部ではなく、素晴らしいデータベースです。
Neon を選ぶ場合、プラットフォームの負荷なしにPostgreSQLが必要な場合、最高の品質のサービスから独自のスタックを組み立てることを好む場合、またはトラフィックが少ないプロジェクトのコスト最適化のためスケーリング不可が必要な場合。
Turso を選ぶ場合、読み取り重視のグローバルに分散されたアプリケーション（エッジレイテンシが書き込みスループットよりも重要）を構築している場合、またはAstroでコンテンツ焦点のサイトで作業している場合。
Social Animalでの私たちの仕事ヘッドレスウェブアプリケーションを構築している、Supabaseは正しい呼び出しでした。オールインワンプラットフォームは、より速い開発、より単純なアーキテクチャ、予測可能なコストを意味します。253K以上のレコードにスケーリングしましたが、汗をかくことはありませんでした。このスケールでプロジェクトを計画していて、アーキテクチャについて話したい場合は、お問い合わせください - 私たちはこれを何度か行っています。
FAQ
Supabase は大規模なアプリケーションに適していますか？ はい、本番環境の証拠があります。Supabase Proで5つの本番サイト全体で253K以上のレコードを実行しています。クエリのパフォーマンスは一貫性を保つ - 137Kの行でベクトル類似性検索を備えた最も複雑な結合は50ms未満で戻ります。Supabase は標準的なPostgreSQLで実行されます。これは、私たちのほとんどが構築するものよりも桁違いに大きいアプリケーションを強化しています。プラットフォーム層（認証、ストレージ、リアルタイム）はより新しい部分ですが、2024年初期以来、安定しています。
Supabase の価格設定はスケール時にFirebaseとどのように比較されますか？ Supabase は劇的により予測可能です。Proプランはフラット$25/月で、50K MAUの認証、8GBのデータベースストレージ、250GB帯域幅、100GBのファイルストレージが含まれます。Firebaseはドキュメント読み取り、書き込み、削除ごとに課金されます。これにより、クエリパターンに応じて100Kレコードアプリケーションのコストが15ドルから200ドル以上に異なる場合があります。ページがソーシャルメディアで共有されるとFirebase法案が一晩で3倍になった場合を見ました。
PlanetScale は100K以上のレコードを処理できますか？ 絶対に。PlanetScale はVitessを実行し、YouTubeスケールのワークロードを強化します。100Kレコード を使用した生のデータベースパフォーマンスの場合、PlanetScale は優秀です。制限はスケーリングではなく、完全性です。認証、ファイルストレージ、リアルタイム更新、ベクトル検索用の別のサービスを追加する必要があります。Supabaseのオールインワンアプローチと比べて、総コスト（月額$90以上）とアーキテクチャの複雑さが増加します。
pgvector とは何で、なぜそれが重要なのですか？ pgvectorはPostgreSQL拡張機能で、ベクトル埋め込みを直接データベースに保存してクエリします。これは意味検索を可能にします - ユーザーは正確なキーワードではなく、意味で検索できます。100K以上のリスティングを持つディレクトリの場合、これは「子供向けのブランチスポット」を検索して、「ファミリーレストラン」または「週末の朝食」としてタグ付けされた結果を返すことを意味します。これらの単語が一致しない場合でも。pgvector なしでは、Pinecone（月額$70以上）のようなベクトルデータベースを分離する必要があり、2つのデータベースを同期し続ける必要があります。
Firebase Firestore はディレクトリウェブサイトに適していますか？ 正直なところ、いいえ。ディレクトリウェブサイトは本質的にリレーショナルです。リスティングはカテゴリに属し、タグを持ち、ユーザーからレビューを受け、複雑なフィルタリングが必要です（「5マイル以内のレストランで4以上の星を表示してください（現在営業中）」）。Firestoreは結合を実行できず、制限されたクエリ演算子があり、ドキュメント読み取りごと課金されます。つまり、複雑なフィルタリングされたクエリはデータ非正規化と比べてコストが増加し、クライアント側のクエリ回避策を処理するSupabaseと比べて推定4倍の開発時間があります。
Next.js アプリケーションにNeonまたはSupabaseを使用する必要があります。 データベースのみが必要な場合、Neon はより優れた価値を提供します（無料層は寛大で、$19/月のLaunchプランは堅実です）。認証、ストレージ、リアルタイム、またはエッジ機能が必要な場合（ほとんどの本番Next.jsアプリケーションは）、Supabase は複数の別個のサービスを統合するのを保存します。Next.js 開発プロジェクトにはSupabaseを使用しています。統合認証とストレージは、典型的なプロジェクト期間から数週間を切り取ります。
プログラム的なSEOサイトに最適なデータベースは何ですか？ Supabase PostgreSQL。プログラム的なSEOサイトは構造化されたデータから何千ものページを生成するため、高速クエリ、優れたインデックス、複雑なデータ関係の処理能力が必要です。Supabaseで多くのプログラム的なSEOサイトを構築しており、場所ページ用にPostGIS、関連コンテンツ用にpgvector、動的フィルタリング用に全文検索を使用するSQLite。フラットな価格設定は、Googleインデックス作成からのトラフィック急増が請求を破裂させないことを意味します。
Turso（libSQL）本番Webアプリケーションの準備ができていますか？ 読み取り重視のアプリケーション向けです。TursoのエッジレプリケートされたSQLiteは、グローバルに5ms未満の読み取りを提供し、コンテンツ焦点のサイトに信じられないほどです。しかし、100K以上のレコード（ユーザーの送信、管理者のパネルの処理の更新、レビューの継続的な作成、リアルタイムデータ変更など）を含む書き込み重いアプリケーションの場合、SQLiteの単一ライターモデルはボトルネックになります。Turso は彼らのlibSQLフォークを通じてこれをより良く処理しますが、それでも書き込み重い100K以上のレコードアプリケーション向けに設計されていません。Tursoをコンテンツサイト上でAstroに、および重大な書き込みワークロード上でSupabaseまたはNeonに推奨します。