サーバーレス PostgreSQL「Neon」の仕組みとユースケース

[hiramekun]

[claude]

Claude finished @hiramekun's task in 1m 9s —— View job

---

概要

Neon は、PostgreSQL 互換のサーバーレス DBaaS(Database as a Service)です。最大の特徴は ストレージとコンピュート(演算)を分離したアーキテクチャ で、これにより「使った分だけ課金」「一瞬でのブランチ作成(DB の git ブランチのようなもの)」「アイドル時のスケールトゥーゼロ」といった、従来の RDS 型マネージド Postgres にはない特性を実現しています。2025 年に Databricks に買収されたことも話題になりました(この点は報道ベースの情報のため、最新の体制については公式情報をご確認ください)。

flowchart LR
    subgraph Compute["コンピュート層(ステートレス)"]
        C1["Postgres compute\n(main branch)"]
        C2["Postgres compute\n(dev branch)"]
    end

    subgraph Storage["ストレージ層(分離・共有)"]
        SK["Safekeeper\n(WAL を Paxos 的合意で複製)"]
        PS["Pageserver\n(ページ単位でデータ提供 / LSM 管理)"]
        S3["Object Storage (S3 互換)\n(コスト最適な永続化)"]
    end

    C1 -- "WAL 書き込み" --> SK
    C2 -- "WAL 書き込み" --> SK
    SK -- "WAL 転送" --> PS
    PS -- "ページ要求/応答" --> C1
    PS -- "ページ要求/応答" --> C2
    PS -- "コールドデータの退避" --> S3

Loading

何が嬉しいのか

従来の Postgres(自前ホスティングや Cloud SQL / RDS のような「コンピュートとストレージが一体」の構成)と比較すると、以下のような課題を解決します。

• アイドル時のコスト: 開発環境やステージング環境など、常時アクセスがない DB でも通常は起動しっぱなしで課金され続けます。Neon はアクセスが一定時間なければコンピュートを自動サスペンドし、課金を止められます(次回アクセス時に自動で再開、いわゆる「コールドスタート」)。
• DB のブランチ作成コスト: 通常、開発用に本番相当のデータを含む DB を複製しようとすると、フルコピーの時間とストレージコストがかかります。Neon はストレージが copy-on-write 方式のため、数秒で本番同等のブランチを作成できます。PR ごとのプレビュー環境や、マイグレーションのテストに有用です。
• 予測しづらいトラフィックへのスケーリング: サーバーレス関数やスパイクの多いワークロードでは、固定インスタンスサイズの Postgres だと過剰プロビジョニングになりがちです。Neon はコンピュートの CPU/メモリを負荷に応じて自動でスケールアップ/ダウンします(Neon Autoscaling)。

具体的なユースケース例:

• Vercel / Cloudflare Workers などのエッジ環境から HTTP 経由で Postgres を呼び出す(TCP コネクションを長時間張れない環境向けに @neondatabase/serverless という HTTP/WebSocket ドライバが提供されています)
• マルチテナント SaaS でテナントごとに DB ブランチを払い出す
• CI で PR ごとに本番データのブランチを作り、統合テストに使う

詳細

アーキテクチャ

Neon の内部は大きく 3 層に分かれています。

1. Compute: 標準の PostgreSQL(フォーク)がそのまま動きます。ステートレスであり、ローカルディスクの代わりにストレージ層からページを取得します。ワイヤプロトコルは通常の Postgres と同一なので、既存の Postgres ドライバ・ORM・拡張機能(対応しているもの)はそのまま使えます。
2. Safekeeper: 書き込まれた WAL(Write-Ahead Log)を複数ノードで合意プロトコルにより複製し、耐久性を担保します。
3. Pageserver: WAL を取り込み、LSM ツリーのような構造でページ単位のデータを管理します。コンピュートからのページ要求に応答しつつ、コールドなデータは S3 互換のオブジェクトストレージに退避します。

この分離構造により、「あるタイムスタンプ/LSN 時点のブランチを作る」ことが、実データをコピーせずメタデータ操作だけで可能になっています(copy-on-write)。

接続とプーリング

サーバーレス関数は短命な接続を大量に張りがちで、Postgres の max_connections を簡単に食いつぶします。Neon は組み込みの connection pooler(PgBouncer ベース)のエンドポイントを提供しており、通常の TCP 接続に加えて HTTP/WebSocket 経由のドライバも選べます。

注意点

• コールドスタート: スケールトゥーゼロ後の初回アクセスには再開の遅延(数百ミリ秒〜数秒程度)が発生します。常時レイテンシがシビアな本番トラフィックには chose the pool size / min compute の調整や、常時起動プランの検討が必要です。
• ネットワーク越しのページ取得: コンピュートとストレージがネットワーク越しになるため、ローカル SSD 直結の DB と比べてワークロードによってはレイテンシ特性が異なります。
• 常時高負荷ワークロードのコスト: 使った分だけ課金というモデルは、逆に言えば「常にフル稼働している」ワークロードでは、固定インスタンスの RDS 等より割高になる場合があります。ワークロードの特性(スパイク型か定常型か)で向き不向きを見極める必要があります。
• 拡張機能(extension)のサポート状況は Postgres 本家と完全一致ではないため、使用予定の拡張が対応しているか事前確認が必要です。

参考リンク

• Neon 公式ドキュメント
• Neon Architecture
• Neon Autoscaling
• Neon Branching
• @neondatabase/serverless (HTTP/WebSocket driver)

---