本番環境のデータベースが100Kレコードに達すると、クエリ時間が上昇し始めます。ダッシュボードを更新すると、以前は300msで表示されていたフィルター済みリストが2.4秒かかるようになっています。クライアントに管理パネルが遅くなった理由を聞かれます。Supabase、Firebase、PlanetScale、Neon、またはTursoがこのスケールに対応できるかどうかを評価する時が来ました。ほとんどの比較記事はTodoアプリを立ち上げて研究と称していますが、私たちは1年以上にわたってSupabase PostgreSQLで5つのライブクライアントサイトで253,000以上のレコードを実行しています。Firebase Firestore、PlanetScale、Neon、Tursoを実際のプロジェクトと実際のトラフィックパターンでテストしました。スケールで実際に何が崩壊するか、何が崩壊しないか、ここにあります。

100K以上のレコードを複雑なクエリ、リアルタイム機能、認証で処理する必要があるWebアプリケーションを構築している場合、データベースの選択は数年間アーキテクチャを定義します。選択を間違えると、6ヶ月以内にデータレイヤーを書き直すか、本来の3倍の料金を支払うことになります。両方から救いたいのです。

目次

100K以上のレコードを持つWebサイト向けベストデータベース：Supabase vs Firebase vs PlanetScale テスト済み

この比較が存在する理由

Social Animalでは、主にNext.jsとAstroを使用してヘッドレスWebアプリケーションを構築しています。データ集約的なサイトが必要なクライアント向けです。50K以上のリスティングを持つエンタープライズディレクトリ、数千のページを生成するプログラマティックSEOサイト、リアルタイム更新が必要なSaaSダッシュボードを考えてください。

クライアントが100K以上のレコードが必要なプロジェクトを持ってきた場合、データベースの会話は初日に行われます。それは後付けではありません。データベースの選択は、認証戦略、API設計、ホスティングコスト、6ヶ月後に機能を出荷する能力に波及します。

すべてのデータベースで同じ本番ワークロードを実行したふりをするつもりはありません。それは不正直です。実際に行ったことは、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以上のレコードに達しています。

毎日使用するもの

**Row Level Security（RLS）**は、おそらく私たちがSupabaseを使うことを決定した機能です。マルチテナントアプリケーションを構築している場合（ほとんどのヘッドレス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を直接使用したいです。エッジ関数はDenoによって駆動されます。つまり、一部のNode.jsパッケージは機能しません。サーバーレス環境の接続プーリングが必要な場合、Supavisor接続文字列を使用する必要があります（2025年初頭にPgBouncer廃止）。

また、無料層は開発用に本当に寛大ですが、データベーススペースの上限は500MBです。100K以上のレコードを含む本番環境では、最低でもProプラン（月額$25）を見ています。

100K以上のレコードを持つWebサイト向けベストデータベース：Supabase vs Firebase vs PlanetScale テスト済み - アーキテクチャ

Firebase Firestore：強みと弱み

2024年にFirebaseを2つのクライアントプロジェクト向けに真摯に評価しました。1つはオフライン同期要件のモバイルファーストアプリケーションでした。もう1つは複雑なフィルタリングを持つディレクトリサイトでした。

Firebaseが本当に勝つところ

モバイルアプリケーション用のFirebaseのリアルタイム同期は依然としてクラス最高です。オフライン永続性、自動競合解決、iOS/Android SDKとの密接な統合により、プライマリプラットフォームがモバイルの場合は明らかな選択肢です。Google認証統合は死ぬほど簡単です -- 数行のコードでGoogle、Apple、電話番号、メール/パスワードでサインインできます。

Firebase Crashlytics、Remote Config、Analyticsは、他に類を見ないモバイル開発エコシステムを形成します。モバイルアプリを最初に構築し、Webアプリを2番目に構築している場合、Firebaseは真摯な検討に値します。

代わりにSupabaseを選択した理由

Firestoreはドキュメントデータベースです。接合はありません。その瞬間のために沈めてください。

カテゴリ、タグ、場所、レビュー、ユーザープロファイルを持つリスティング付きのディレクトリを構築している場合、リレーショナルデータが必要です。Firestoreでは、すべてをdenormalize（ドキュメント全体のデータを重複させ、同期させたままにすることを祈ります）するか、複数のラウンドトリップクエリを作成して、アプリケーションコード内のデータを結合します。

「カテゴリ別のリスティングを平均評価で検索」クエリが各項目でどのように見えるかは次のとおりです：

-- 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の同等のものもありません。基本的なgeohashクエリを実行できますが、それは近似値であり、真の空間インデックスと比較して制限されています。

PlanetScale：素晴らしいデータベース、不完全なプラットフォーム

PlanetScaleはVitessフッド下で実行されます -- YouTubeのデータベースを力づけるのと同じテクノロジー。純粋なMySQL パフォーマンスについては、それは優れています。データベースブランチング機能（ブランチを作成、スキーマ変更をします、バック統合）は本当に革新的であり、Supabaseがネイティブに持っていた何かを望みます。

PlanetScaleが行うことが得意

サーバーレスドライバーは高速です。接続管理はあなたのために処理されます。これは、各関数呼び出しが新しいデータベース接続を開くかもしれないサーバーレス環境で非常に重要です。スキーマブランチングにより、データベース移行がGit プルリクエストに感じます -- 安全、レビュー可能、元に戻すことができます。

MySQLの強力な専門知識を持つチーム向けは、従来のWebアプリケーションを構築し、PlanetScaleは堅実です。

何が足りないか

PlanetScaleはちょうどデータベースです。それはそれです。完全なアプリケーションスタック構築に必要なものを比較します：

機能 Supabase PlanetScale + エクストラ
データベース ✅ 含む ✅ 含む
認証 ✅ 含む ❌ Clerk（$25+/mo）またはAuth0が必要
ファイルストレージ ✅ 含む ❌ S3またはCloudflare R2が必要
リアルタイム ✅ 含む ❌ PusherまたはAblyが必要
ベクトル検索 ✅ pgvector ❌ 利用不可
ジオクエリ ✅ PostGIS ❌ 基本的なMySQL spatial
エッジ関数 ✅ 含む ❌ 別個の展開が必要

認証にClerkを、ストレージにS3を、リアルタイムにPusherを、検索用に別のベクトルデータベースを追加したら、1つのサービスではなく5つのサービスを管理しています。請求額が高い、複雑さが高い、デバッグ表面エリアが膨大です。

PlanetScaleはまた2024年4月に無料層（ホビープラン）をサンセットしたので、エントリーポイントはScalerプラン（$39/月）です。これはSupabase Proより高く、より少ない機能を提供します。

Neon：純粋主義者の選択

Neonは、PostgreSQLだけが必要な場合に選ぶデータベースです。サーバーレスアーキテクチャは本当に印象的です -- ゼロへのスケーリングは、データベースがクエリされていないときに何も支払わないことを意味します。ブランチング機能はプレビュー展開に優れています（すべてのPRのデータベースブランチをスピンアップします）。

NeonはpgvectorとPostGISをサポートしています。標準的なPostgreSQLだからです。したがって、ベクトル検索とジオクエリを取得します。生のデータベース機能はSupabaseとほぼ同じです。

私たちが依然としてSupabaseを選択した理由

Neonはデータベースです。Supabaseはプラットフォームです。Neonを使用すると、追加する必要があります：

  1. 認証 -- Clerk、Auth0、またはローリング自分
  2. ストレージ -- S3、Cloudflare R2、または同様
  3. リアルタイム -- Pusher、Ably、またはカスタムWebSocketサーバー
  4. エッジ関数 -- 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プロジェクトについては、これらは扱いやすいです。

ヘッド・ツー・ヘッド機能比較

2026年中頃の本番経験と評価に基づいた完全な比較表です：

機能 Supabase Firebase PlanetScale Neon Turso
データベースタイプ PostgreSQL NoSQL（Firestore） MySQL（Vitess） PostgreSQL SQLite（libSQL）
組み込み認証 ✅ はい ✅ はい ❌ いいえ ❌ いいえ ❌ いいえ
ベクトル検索 ✅ pgvector ❌ いいえ ❌ いいえ ✅ pgvector ❌ いいえ
ジオクエリ ✅ PostGIS ⚠️ 限定的（Geohash） ⚠️ 基本的な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（geohash） 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/mo $0（従量課金） $39/mo $19/mo $29/mo
データベース 含む（8GB） ~$18（読み取り + 書き込み） 含む（10GB） 含む（10GB） 含む（9GB）
認証 含む（50K MAU） 含む +$25/mo（Clerk） +$25/mo（Clerk） +$25/mo（Clerk）
ストレージ（10GB） 含む ~$3/mo +$2/mo（R2） +$2/mo（R2） +$2/mo（R2）
リアルタイム 含む 含む +$25/mo（Pusher） +$25/mo（Pusher） +$25/mo（Pusher）
推定総計 $25/mo ~$21/mo ~$91/mo ~$71/mo ~$81/mo

Firebaseは安いように見えますが、2つのことに気付くまで。まず、その$21の見積もりは予測可能な読み取りパターンを仮定しています。ウイルス瞬間またはボットサイトをクロールすると、読み取りが大幅にスパイクする可能性があります -- そしてあなたの請求スパイク。次に、ベクトル検索などの機能が必要になったら、Pineconeまたはweaviateを追加しています。これは月額$70で開始されます。

Supabaseのフラット$25/月すべてのために -- データベース、認証、ストレージ、リアルタイム、エッジ関数 -- このワークロードサイズについて驚くほど良い値です。Proプランには8GBデータベース、250GBの帯域幅、100GBストレージ、認証用50K月次アクティブユーザーが含まれています。

どのデータベースを選ぶべきか

これらのツールを使って構築した経験に基づいた正直な推奨です：

リレーショナルデータを持つWebアプリケーションを構築している場合、Supabaseを選択します、認証+ストレージ+リアルタイムが1つのプラットフォームで必要です。PostgreSQLのエコシステム（pgvector、PostGIS、フルテキスト検索）が必要ですか、またはNext.jsで構築しています。これは、見ているプロジェクトの約80%をカバーしています。

Firebaseを選択しますモバイルファーストアプリケーションを構築している場合、オフライン同期が重要、あなたのチームはすでにFirebaseエコシステムを知っています、またはあなたのデータは本当にドキュメント形状（チャットメッセージ、アクティビティフィード、シンプルなユーザープロファイル）です。

PlanetScaleを選択します強いMySQLチームを持っている場合、複雑なスキーマ管理のためにデータベースブランチングが必要であり、すでに認証とストレージに別々のサービスを使用しています。それは素晴らしいデータベースです -- ちょうど完全なプラットフォームではありません。

プラットフォームオーバーヘッドなしでPostgreSQLが必要な場合、Neonを選択します。ベストオブブリード サービスから自分のスタックを組み立てることを好むか、低トラフィックプロジェクトのコスト最適化のためにゼロへのスケーリングが必要です。

読み取り重いグローバル分散アプリケーションを構築している場合、Tursoを選択します、エッジレイテンシが書き込みスループット、またはAstroでのコンテンツフォーカスサイト上で重要です。

Social Animal での私たちの仕事用にヘッドレスWebアプリケーションを構築するには、Supabaseが正しい呼び出しでした。オールインワンプラットフォームは、より高速な開発、より単純なアーキテクチャ、および予測可能なコストを意味します。253K以上のレコードにスケーリングしましたが、汗をかいていません。このスケールで計画を立てていて、アーキテクチャについて話し合いたい場合は、連絡をとってください -- 今数回行いました。

FAQ

Supabaseは大規模なアプリケーションに良いですか？

はい、そしてそれをバックアップする本番証拠があります。5つの本番サイト全体で253K以上のレコードを実行しています。クエリパフォーマンスは一貫性を保ちます -- ベクトル類似性検索による最も複雑な結合は137Kの行で50ms未満で返されます。Supabaseは標準的なPostgreSQLで実行されます。私たちのほとんどが構築するものより数桁大きいアプリケーションを力づけます。プラットフォームレイヤー（認証、ストレージ、リアルタイム）は新しい部分ですが、2024年初頭以来、安定しています。

Supabaseの価格設定はスケールでFirebaseと比較してどのように比較しますか？

Supabaseはドラマチックにより予測可能です。Proプランは、認証用50K MAU、8GBデータベースストレージ、250GB帯域幅、100GBファイルストレージを含むフラット$25/月です。Firestoreは、ドキュメント読み取り、書き込み、削除ごとに請求します。100Kレコード アプリケーションが月2M読み取りを持つことができるため、Firebaseのコストはパターンに応じて$15から$200+の任意の場所で実行できます。社会的メディア上でページが共有されたときにFirebaseの請求が一夜にして3倍になるのを見ました。

PlanetScaleは100K以上のレコードを処理できますか？

絶対に。PlanetScaleはVitessを実行します。これはYouTube スケールのワークロードを力づけます。100K以上のレコードでの生のデータベースパフォーマンスについては、PlanetScaleは優れています。制限はスケールではなく、完全さです。認証、ファイルストレージ、リアルタイム更新、ベクトル検索用に別々のサービスを追加する必要があります。これにより、Supabaseのオールインワンアプローチと比較して、コスト（合計$90+/月）とアーキテクチャの複雑さが増加します。

pgvectorとは何ですか、それはなぜ重要ですか？

pgvectorは、ベクトル埋め込みを直接データベースに保存およびクエリするPostgreSQL拡張機能です。これにより、セマンティック検索が可能になります -- ユーザーは正確なキーワードではなく、意味で検索できます。100K以上のリスティングを持つディレクトリについては、「子供向けブランチスポット」を検索すると、「家族レストラン」または「週末朝食」タグ付き結果を返すことができます。これらの言葉が一致しなくても。pgvectorがなければ、Pinecone（$70+/月）のような別のベクトルデータベースが必要になり、2つのデータベースを同期させたままにしておくことで対処します。

Firebase FirestoreはディレクトリWebサイトに適していますか？

正直に言うと、いいえ。ディレクトリWebサイトは本質的にリレーショナルです。リスティングはカテゴリに属しており、タグを持ち、ユーザーからレビューを受け取り、複雑なフィルタリング(「今オープンしている5マイル以内の星4以上のレストランを見せてください」)が必要です。Firestoreは結合できず、限定的なクエリ演算子を持ち、ドキュメント読み取りごとに請求されます。つまり、複雑なフィルター済みクエリはSupabaseと比較して開発時間の4倍を取得します。Firestoreをディレクトリプロジェクト向けに評価して、データdenormalization とクライアント側のクエリ回避策のためにSupabaseと比較して開発時間が大幅に増加することを推定しました。

Neon か Supabase を Next.js アプリ用に使用する必要がありますか？

データベースだけが必要な場合は、Neonはより良い値を提供します（無料層は寛大で、$19/月のLaunchプランは堅実）。認証、ストレージ、リアルタイム、またはエッジ関数が必要な場合（ほとんどの本番Next.jsアプリはそうします）、Supabaseは複数の個別サービスを統合およびサポート（かつ支払い）から相談を保存します。Next.js開発プロジェクトについてはSupabaseを使用しています。統合認証とストレージは、タイトなタイムラインでクライアントプロジェクトを出荷するときに週間を切り取っています。

プログラマティックSEOサイト向けの最良のデータベースは何ですか？

Supabase PostgreSQL。プログラマティックSEOサイトは構造化データから数千のページを生成します。つまり、高速クエリ、良好なインデックス、複雑なデータ関係の処理が必要です。Supabaseでプログラマティックなseオサイトを構築しました。これは、ロケーションページ用の位置情報、関連コンテンツ用のpgvector、動的フィルタリング用のフルテキスト検索でのページセットから10K以上のページを生成し、単一のデータベースから - 。フラット価格設定は、Google インデックスから認識されるトラフィックスパイクが請求額を爆発させないことを意味します。

Turso（libSQL）は本番Webアプリに対応しているか？

読み取り重いアプリケーションの場合は はい。TursoのエッジレプリケーションされたSQLiteは、グローバルに信じられないほど低いサブ5ms読み取りを提供します。ただし、100K以上のレコードを持つ書き込み重いアプリケーション -- ユーザー提出データ、管理パネル処理更新、絶え間ないレビュー作成とデータ変更など -- SQLiteのシングルライターモデルは制限になります。TursoはlibSQLフォークを通じてこれをより良く処理しますが、まだ高い書き込みスループットのある100K以上のレコード アプリケーション向けに設計されていません。Astroで構築されたコンテンツサイト向けのTursoをお勧めします。Supabase またはNeon動的アプリケーションとサウンド後ろ。