ただし、これは普遍的な概念ではありません。専用の Postgres インスタンスをプロビジョニングする Supabase と Aurabase は、これと同じメカニズムを同じ方法で公開しません。この記事では、Neon が独自のコールド スタートについて実際に文書化している内容、Vercel Postgres と Supabase の比較、Aurabase モデルがどこに適合するかについて詳しく説明し、マーケティング ページから推測するのではなくプロビジョナー コードで直接検証します。
必需品
- サーバーレス コールド スタートとは、一時停止されたデータベースが最初のリクエストに応答する前にコンピューティングを起動する必要がある場合に追加される遅延を指します。
- Neon はストレージと計算を分離します。文書化された非アクティブな時間が経過すると、コンピューティングはスリープ状態になります (無料プランではデフォルトで 5 分、有料プランでは構成可能)。
- Neon では、通常、数百ミリ秒から数秒程度の再起動を記録しています。この数値は発行者によって公開されており、コミュニティ ツール neon-latency-benchmarks.vercel.app を介してライブで測定できます。
- Vercel Postgres は Neon インフラストラクチャに依存しています。ウェイクアップ動作は、異なるブランドの下で同じメカニズムに従います。
- Supabase は、接続ごとのコールド スタートを行わずに、プロジェクトごとに専用のデータベースを提供します。無料プランのみが非アクティブなプロジェクトを一時停止し、手動で復元します。
- Aurabase は、プロジェクトごとに専用の Postgres データベース、専用の CNPG クラスター、または共有クラスター上の専用のベースをプロビジョニングします。これは、プロビジョナー コードで検証された Neon サーバーレス モデルではありません。
サーバーレス Postgres データベースのコールド スタートとは何ですか?
コールド スタートは、データベースを実行するコンピューティングが非アクティブによってスリープ状態になったときに発生します。新しいクエリは、実行する前にまずコンピューティングを再起動する必要があります。これは、一般的な TCP/TLS 接続の通常のネットワーク遅延ではありません。これは、最初のリクエストの実行が開始される前であっても、新しい Postgres プロセスを起動してその状態を復元する時間です。
The term comes from serverless computing broadly, where a zeroed execution environment must restart before processing a request, whether it is a server function or a WebAssembly runtime at the edge. We detail this mechanism on the edge functions side in our article on cold start WebAssembly facingcontainers. For a database, the mechanics differ: it is not a compiled binary that starts, but a complete Postgres server which must reopen its files, validate its state, then accept new connections.
1. 顧客ログイン
コンピューティングが一時停止されているプロジェクトにリクエストが到着します。
2.睡眠検知
プラットフォームは、コンピューティングがアクティブでなくなったことに気づきます。
3. コンピューティングの再起動
Postgres プロセスが再起動され、必要な状態が復元されます。
4. リクエストの処理
接続は成功し、リクエストは正常に実行されます。
コールド スタート メカニズムの図、簡略化されたシーケンス、測定時間値なし。
Neon がコンピューティングをスリープ状態にする理由とその頻度
Neon は、データベース アーキテクチャを 2 つの異なる層に分離しています。1 つはデータを保持する永続ストレージ、もう 1 つは独立して停止および再起動できる Postgres プロセス自体の計算です。公式ドキュメントによると、この分離により、Neon はデータに触れることなく非アクティブなプロジェクトの計算を一時停止し、オンデマンドで再起動できるようになります。
無料プランでは、Neon はコンピューティングをスリープ状態にする前に 5 分間のデフォルトの非アクティブ タイムアウトを文書化しています。有料プランでは、このしきい値を構成したり、一定のトラフィックで使用するために大幅に増加したりすることもできます。このタイプのデフォルトは製品のアップデートによって変更されます。この個別の図ではなく、読んだ時点で最新の Neon ドキュメントを確認してください。
この設計は、特定の目的、つまり一時的な環境に役立ちます。 Git ブランチごとのデータベース、プル リクエストによるプレビュー環境、1 日に数分しか使用されないテスト データベース。これらの用途でコンピューティングを継続的に実行するのはコストがかかり、実際のメリットはありません。 2 回の使用の間にコンピューティングを一時停止すると、データを削除せずに請求額が削減されます。これが Neon のサーバーレス モデルの中心的な議論です。
ネオン目覚まし時計の持続時間と自分で確認する方法
Neon のドキュメントでは、プロジェクトのサイズと、コンピューティングの準備が整う前に再生されるトランザクション ログの量に応じて、通常は数百ミリ秒から数秒程度でコンピューティングが再開されると記載されています。これは出版社自体によって公表された数値であり、独立した監査によるものではありません。契約上の保証としてではなく、文書化された桁違いとして扱います。
実際の測定では、パブリック コミュニティ ツール neon-latency-benchmarks.vercel.app が、一時停止された Neon プロジェクトを定期的にポーリングし、観測されたウェイクアップ レイテンシを表示します。これは、単なる文書化された数値よりも重要な方法論のタイプです。つまり、テスト条件はマーケティング平均の陰に隠れず、目に見えるままになります。同じ原則を独自の バックエンド ベンチマーク方法論に適用します。図を公開する前にプロトコルを公開します。
| プロジェクトの規模 | 検証する関係と WAL ボリュームが増えると、再起動に時間がかかります。 |
|---|---|
| 地域とネットワーク距離 | コールド スタート自体とは関係なく、接続の遅延が増加します。 |
| 料金プラン | 有料プランでは、非アクティブのしきい値を構成または拡張できます。 |
| 接続頻度 | 定期的に要求されたままのコンピューティングでは、このような遅延は発生しません。 |
Vercel Postgres と Neon: 別ブランドの同じエンジン?
Vercel は、2024 年に公開されたパートナーシップである Neon インフラストラクチャに基づいて Postgres データベース製品を構築しました。この記事の執筆時点では、この Postgres 統合は、他のプロバイダーと並んでストレージ オプションとして Vercel Marketplace で提供されています。更新された Vercel 製品ページを確認してください。このタイプのパートナーシップは、四半期ごとに変化する市場で急速に進化します。
具体的には、Vercel 経由でプロビジョニングされた Postgres データベースのスリープおよびウェイクアップの動作は、Neon について上で説明したものと同じ仕組みに従います。これは独自のコールド スタート モデルを備えた別個のエンジンではなく、Vercel 統合の背後で公開される同じインフラストラクチャです。
Supabase には同等のコールド スタート機能がありますか?
いいえ、同じではありません。 Supabase は、接続ごとに一時停止されるサーバーレス コンピューティングではなく、プロジェクトごとに専用の Postgres インスタンスをプロビジョニングします。したがって、Neon モデルとは異なり、数分間非アクティブになった後の新しいセッションごとにウェイクアップ遅延が追加されることはありません。
ただし、無料プランには別のメカニズムが存在します。Supabase では、ドキュメントによれば 1 週間程度の長期間が経過した後に非アクティブなプロジェクトを自動的に一時停止し、最初のリクエストで自動的にウェイクアップするのではなく、ダッシュボードから手動で復元します。これは分単位ではなく日単位で測定されるしきい値であり、透明性のある回復ではなく明示的なアクションです。Neon コールド スタートとの 2 つの構造的な違いであり、同じメカニズムの単純なバリエーションではありません。アーキテクチャを完全に比較するには、Aurabase と Supabase の詳細な 比較で、その他の相違点を文書化します。
Aurabase モデル: 比較がそのまま適用されない理由
Aurabase は Neon のようなサーバーレス モデルを提供していません。プロビジョナー コード (aura-provisioner、github.com/daylami555/aurabase のオープン ソース) で検証: 各プロジェクトは、選択したプランに応じて、CloudNativePG、Kubernetes CNPG オペレーターによって管理される専用の Postgres クラスター、または同じ組織の複数のプロジェクト間で共有される CNPG クラスター上の専用ベースのいずれかを受け取ります。どちらの場合も、接続ごとにサスペンドおよびウェイクアップする単一のコンピューティングではありません。これは、プライマリおよび可能なレプリカを備えた完全な Postgres クラスターです。
Aurabase 側には休止状態メカニズムが存在しますが、それは異なる目的を果たします。長期間の非アクティブ状態 (デフォルトでは 7 日間) が発生すると、プロビジョナーは、断続的な使用のレイテンシを最適化するためではなく、リソースを解放するために、非アクティブなインスタンスをスリープ状態にします。スリープ中の CNPG クラスターを起動すると、永続ボリュームからポッドが再作成されます。これは、単純なサーバーレス プロセスの再起動よりも構造的に重いメカニズムです。
Aurabase は現在までウェイクアップ レイテンシの数値を発表しておらず、ウェイクアップ時間が速いと主張したり、Neon と比較したりしていません。それは同じ製品ではありません。公表された寸法なしにそれをそのように偽るのは不誠実です。
この専用アーキテクチャには、分離性とパフォーマンスの予測可能性の点で直接対応するものがあります。つまり、サイズが不十分な共有クラスターとは異なり、プロジェクトはそのコンピューティングを別のプロジェクトと共有しません。この調停については、専用の記事「 専用 vs 共有ベース、パフォーマンスと分離への実際の影響」で詳しく説明しています。
ユースケースに応じて選択してください
Neon サーバーレス モデルは、特定のユース ケース、つまり、継続的に実行されるコンピューティングの料金を支払うことが経済的に合理的でない、多くの一時的な環境やトラフィックが非常に断続的な環境に役立ちます。 Git ブランチごとのデータベース、プル リクエストによるプレビュー環境、週に数回テストされるプロトタイプ。時折コールド スタートを行うことは、実際の使用量に比例する請求書に対して許容できる妥協点になります。
逆に、最初の接続のレイテンシを予測可能な状態に保つ必要がある場合には、専用の常時稼働の Postgres アーキテクチャが推奨されます。たとえば、通常のトラフィックを伴う運用 API、ユーザー リクエストで時折レイテンシが急上昇することが許容できないバックエンド、または分離されたテスト ブランチのコストよりも p99 が重要なシステムなどです。
| サプライヤー | 計算モデル | スリープトリガー | 典型的な目覚まし時計 |
|---|---|---|---|
| ネオン | ストレージから分離されたサーバーレス コンピューティング | 非アクティブ状態、5 分から (無料プラン) | 自動、1 秒未満から数秒 (編集者と主張) |
| ヴェルセル・ポストグレ | ネオンインフラストラクチャー（パートナーシップ） | ネオンと同じ | ネオンと同じ |
| スーパーベース | プロジェクトごとの専用ボディ | 長期間の非アクティブ状態、無料プランのみ | 手動、ダッシュボードから復元 |
| オーラベース | 専用または共有 CNPG クラスター | 長期間の非アクティブ状態、デフォルトでは 7 日間 | 2 秒未満を意図したものではなく、公開されていません |
ネオン目覚まし時計: 出版社によって文書化された桁違いのものであり、独立した監査は行われていません。 Aurabase 休止状態のしきい値: aura-provisioner、変数 HIBERNATE_INACTIVITY_DAYSでチェックイン、デフォルトは 7 日。
よくある質問
覚えておくべきこと
Postgres のサーバーレス コールド スタートは普遍的な概念ではありません。これは、ストレージと計算を分離して 2 つの使用の間で後者を一時停止する Neon アーキテクチャの直接の結果です。 Vercel Postgres は、Neon とのパートナーシップを通じてそれを直接継承しています。専用の Postgres インスタンスをプロビジョニングする Supabase と Aurabase は、同じ目的のために設計されたものではなく、分ではなく日単位で測定される異なるメカニズムを公開しています。
この基準だけでプロバイダーを選択する前に、プロバイダーによって文書化されている実際の非アクティブしきい値、プランで構成可能かどうか、アプリケーションのトラフィックが一時停止するコンピューティングを正当化するかどうかという 3 つのことを確認してください。実際の断続的なトラフィック、テストブランチ、またはプレビューで使用する場合、サーバーレス モデルには明らかな経済的メリットがあります。通常のトラフィックが発生する運用環境では、専用のアーキテクチャを使用することで問題が解消されます。