Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説

Neonは、Postgresのストレージ層とコンピュート層を切り離し、アクセスが途切れた間はコンピュートを停止して課金を止めるマネージドのPostgresサービスです。データベースの分岐（ブランチ）をメタデータ操作だけで作れるため、本番データの形を保ったままプルリクエスト単位の検証環境を用意できるのが特徴です。一方で、東京リージョンの提供が無いこと、プール接続では一部のセッション機能が落ちること、2025年にDatabricks傘下へ入ったことなど、採用前に潰しておく前提もあります。この記事では、SafekeeperとPageserverの役割分担、CU-hour課金の積み上げ方、接続数の上限値、そして受託開発で採用してよい条件と見送るべき条件までを、公式ドキュメントの実数値をもとに順に整理します。

まとめ｜Neonを採用してよい条件と見送りが妥当になる業務要件

Neonが噛み合うのは、負荷が断続的で、検証環境を頻繁に作り直し、レイテンシ要件が緩い用途です。無活動5分でコンピュートが止まり、再開は数百ミリ秒で済むため、夜間や休日に止まる社内システム、開発検証環境、生成AIエージェントのバックエンドあたりが素直に効きます。逆に、24時間コンピュートを起こし続ける構成では停止による節約が効かず、従量課金の分だけ読みにくくなります。

採用可否の分岐は3つに集約されます。第一に、アジアのリージョンがシンガポールとシドニーだけで、東京の提供が無いこと。国内エンドユーザーが対話的に叩く業務システムでは、この一点で候補から外れます。第二に、プール接続でセッション変数やLISTENが使えないこと。既存アプリの移行では、まずここを棚卸しします。第三に、Postgresのメジャー更新が新規プロジェクトへの移行になる点で、5年動かす基幹系ほど段取りを先に決めておく必要があります。

費用の感触も先に出しておきます。1 CUを平日8時間・月22日動かし、ストレージ10GBを置いた構成なら、Launchプランで月22ドル前後。この規模で自前のPostgresを冗長構成で立てる工数と比べれば、小規模案件の初期段階では分があります。

ストレージとコンピュートを分離したNeonの構成要素と処理の流れ

Neonの挙動を予測するには、書き込みがどこで確定し、読み取りがどこから返るのかを押さえるのが近道です。公式のアーキテクチャ解説では、層の間をつなぐ唯一のインターフェースがWALだと説明されています。

Safekeeperがクォーラムで確定させるWALと耐久性の担保範囲

コンピュート層は標準のPostgresで、RAMとローカルNVMeキャッシュの上で動きます。ここが通常のPostgresと違うのは、WALをローカルディスクに永続化せず、ストレージ層へストリーミングする点です。受け取るのがSafekeeperで、Paxosベースのクォーラム合意によってWALを複製します。トランザクションはクォーラムがWALレコードを受領した時点でコミット確定となり、単一マシンのディスクに耐久性を依存しません。

この設計の実務的な意味は、コンピュートが落ちても確定済みのデータが失われない点にあります。WALがどの順序で書かれ、どこでリカバリの起点になるかを理解していれば、Neonの「コンピュートは使い捨て」という前提もそのまま受け入れられるはずです。逆に、ローカルディスクの速度を前提にチューニングしてきた構成をそのまま持ち込むと、書き込みの経路が変わっていることを見落とします。

Pageserverがベースページと差分から組み立てる読み取り経路

読み取りを担うのがPageserverです。公式の記述では、materialize済みのベースページとコミット済みのWALレコードを組み合わせてページ版を再構成します。つまりPageserverは「どの時点のこのページを見せるか」を要求に応じて作る役目で、これがタイムトラベル的な読み取りとブランチの土台になっています。

その後ろにあるオブジェクトストレージは、不変の長期履歴を保持します。ここで押さえておきたいのは、オブジェクトストレージがコンピュート層から直接参照されないと明記されている点です。クエリのクリティカルパスから外れているため、履歴が積み上がってもオブジェクトストレージへのアクセス遅延がそのまま応答時間に乗ることはありません。

Postgres 14から18までの対応版とメジャー更新が別プロジェクトになる制約

対応するメジャーバージョンは14・15・16・17・18の5世代で、Postgres本体の直近5世代に合わせる方針が示されています。マイナーリリースは次回のコンピュート再起動時に最新へ自動更新され、各メジャーで最新マイナー以外はサポート対象外です。ダウングレードやマイナーの飛ばし読みはできません。

設計上の注意はメジャー更新の手順にあります。インプレースの昇格ではなく、希望バージョンで新規プロジェクトを作ってデータを移す形です。EOLはPostgres公式の「初回リリースから5年」に揃うため、14で始めた案件は残存期間が短い前提で見積もる必要があります。新規案件なら17か18から入り、更新時に別プロジェクトへ移す工数を保守見積りへ最初から積んでおくのが実務的な扱い方です。

コピーオンライトのブランチが変える検証環境の作り方と課金の増え方

Neonを他のマネージドPostgresと分けている機能がブランチです。ここは開発フローの設計に直結するため、上限値と課金の効き方まで含めて見ます。

ブランチ作成がメタデータ操作だけで完了する仕組みと復元への転用

ブランチはデータのコピーではなく、履歴上の一点を指す参照の作成です。公式の説明では、新しいブランチは既存の履歴上の一点を指し、そこからコピーオンライトの意味論で分岐していきます。ストレージを追加消費するのは新規・変更されたデータだけです。数百GBのテーブルがあっても、分岐の瞬間にその容量が二重に課金されることはありません。

同じ仕組みは復元にも転用できるのが利点です。誤ったマイグレーションを流した直後であれば、その手前の時点を指すブランチを立てて中身を確認し、必要な行だけを戻すという段取りが取れます。MySQL系でブランチとスキーマ変更のワークフローを提供するPlanetScaleと発想は近く、Postgres側の実装としてNeonを見ると位置づけが掴みやすくなります。

プランごとのブランチ本数上限とCI連携で詰まりやすい典型パターン

本数の上限は見落としやすい制約です。FreeとLaunchはプロジェクトあたり10ブランチ、Scaleは25ブランチ。プルリクエストごとにブランチを切る運用では、この数字にすぐ届きます。

• 並行するプルリクエストが10本を超え、CIのブランチ作成が失敗する
• マージ済みブランチが消されずに残り、上限を実質的に食い潰す
• ステージング用の長命ブランチを本数に数え忘れ、開発用の枠が足りなくなる

対処は単純で、CIのワークフローにブランチ削除のジョブを必ず対にして置くことです。作成側だけを自動化して削除を手動に残すと、上限に当たるのは時間の問題になります。

長期保持したブランチでストレージ課金が膨らむ条件と削除の基準

コピーオンライトは分岐時点では安価ですが、分岐後の書き込みは差分としてストレージを消費します。有料プランのストレージ単価は0.35ドル／GB-月。長命のステージングブランチに大量の書き込みテストを流し続ければ、その差分が積み上がります。Freeプランはプロジェクトあたり0.5GBなので、テストデータを入れた時点で枠を超えることも珍しくありません。

削除の基準は日数で切るのが運用しやすい方法です。プルリクエストのマージから何日で消すかを決め、CIに落とし込む。ステージング用の長命ブランチだけは例外扱いにし、月次で差分の量を確認する。この2本立てにしておけば、請求書を見てから慌てずに済みます。

CU-hour課金とスケールトゥーゼロで決まる月額費用の見積もり手順

Neonの費用はコンピュートの稼働時間とストレージ量で決まります。定額のインスタンス料金に慣れていると読み違えやすいため、単価と上限値を並べて確認します。

FreeとLaunchとScaleで変わる単価と上限値の実額比較

プランは3つです。以下は公式のプラン一覧に記載された数値をそのまま並べたものです。

プロジェクト数の上限はFreeとLaunchが100、Scaleが1,000のソフト上限です。マルチテナントでテナントごとにプロジェクトを分ける設計を考えているなら、この数字が先に効いてきます。

スケールトゥーゼロが効く負荷と効かない常時接続の実務での見分け方

コンピュートは無活動5分で停止し、再びクエリが来ると数百ミリ秒で復帰します。判定に使われるのは活動の有無なので、5分より短い間隔でヘルスチェックやポーリングを打っている構成では、いつまでも停止しません。監視エージェントがデータベースへ定期クエリを投げているだけで停止条件を満たさなくなる、というのがよくある取りこぼしです。

実務での見分け方は、深夜帯のクエリログに何が残るかを見ることに尽きます。バッチ・監視・キャッシュ更新のいずれかが5分未満で走っていれば、停止による節約は当てにできません。逆に、業務時間外にクエリが完全に途切れる社内システムであれば、停止時間がそのまま費用の削減として効きます。Scaleプランは停止までの時間を1分から常時稼働まで設定できるため、復帰の数百ミリ秒を嫌うワークロードは常時稼働に寄せる選択も取れます。

CU-hour換算で月額の当たりを付ける計算手順とストレージ費の加算

見積りは次の順で組み立てます。

1. 月の稼働時間を出す（平日8時間・月22日なら176時間）
2. 平均CU数を決める（軽い業務システムなら1 CU前後）
3. 稼働時間と平均CU数を掛け、プランの単価を乗じる
4. ストレージ量に0.35ドルを掛けて足す

この手順でLaunchプランを計算すると、176 CU-hours×0.106ドルでコンピュートが約18.7ドル、ストレージ10GBで3.5ドル、合計は月22ドル程度になります。同じ条件をScaleプランの0.222ドルで計算すればコンピュートは約39.1ドルで、差はおよそ2倍。プランの差はブランチ本数と停止設定の自由度に対する対価なので、まずLaunchで始め、ブランチ上限か停止設定で詰まった時点でScaleへ上げる進め方が費用対効果として素直です。オートスケールを高い上限で許可すると平均CU数が想定を超えることがあるため、上限値は要件から決めた数字で締めておきます。

PgBouncer経由の接続上限とプール利用時に落ちる機能の確認手順

既存アプリをNeonへ載せ替える工程で最初に事故が起きるのが接続まわりです。上限値と、プール経由で使えなくなる機能を先に確認します。

コンピュートサイズ別のmax_connectionsと実効同時接続数

非プール接続の max_connections はコンピュートサイズで決まります。0.25 CUなら104、1 CUで419という具合に、小さいサイズでは接続数そのものが制約になります。

プール付きのエンドポイントを使えばPgBouncerが前段に入り、最大10,000同時接続まで受けられます。プールはユーザーとデータベースの組ごとに max_connections の0.9倍で確保されるため、複数のロールで接続する構成では枠の食い合いが起きます。接続ユーザーを用途ごとに増やす設計は、Neon上では慎重に扱う対象です。

トランザクションモードで使えなくなるセッション依存機能の洗い出し

プール接続の既定はトランザクションモードで、トランザクション完了ごとに接続がプールへ返ります。この性質上、セッションをまたいで状態を保つ機能は使えません。

• SET と RESET によるセッション変数
• LISTEN と NOTIFY による通知
• WITH HOLD 付きのカーソル
• SQLレベルのprepared statementと LOAD 文
• セッションレベルのadvisory lock

プロトコルレベルのprepared statementは使えるので、多くのドライバは素通りします。詰まるのは LISTEN と NOTIFY でジョブキューを組んでいるアプリと、セッション変数で行レベルセキュリティのコンテキストを渡している実装です。移行の初手として、この2つの利用箇所をコード検索で洗い出しておくと、後戻りが減ります。

サーバーレス実行環境でのコネクション枯渇を避ける接続設計の勘所

Lambdaのような実行環境から直接つなぐ場合、同時実行数がそのまま接続数になります。0.25 CUの104という上限は、同時実行が二桁後半に届くだけで危うい水準です。プール付きエンドポイントを既定にし、非プール接続はマイグレーションや管理作業に限る、という切り分けが安全側の設計になります。

セッション機能が必要な処理は、非プール接続を使う経路として分離します。バッチ側だけ非プールでつなぎ、アプリ本体はプール経由に寄せる。この二経路構成にしておけば、トランザクションモードの制約に引っかかった処理だけを逃がせます。接続文字列を環境変数で切り替えられるようにしておくと、移行途中の切り戻しも楽になります。

東京リージョン不在とDatabricks傘下という前提での採用可否の線引き

ここからは技術仕様ではなく、受託開発で判断を下すための材料です。結論を先に置くと、Neonは「国内本番の基幹系には出さない、それ以外では積極的に使う」という線引きが実務に合います。

国内向け本番データベースでNeonを採用しない条件と例外の用途

提供リージョンはAWSがバージニア北部・オハイオ・オレゴン・フランクフルト・ロンドン・シンガポール・シドニー・サンパウロで、Azure側の3リージョンは非推奨扱いです。東京（ap-northeast-1）はありません。アジアで最も近いのはシンガポールで、国内エンドユーザーが対話的に操作する画面では往復遅延がそのまま体感に乗ります。さらに、既存プロジェクトのリージョン変更はできず、移すには新規プロジェクトを作って移行する手順になります。

そのため、国内ユーザーが日中に叩く業務システムの本番データベースとしては採用しません。判断を曖昧にせず、この条件では見送ります。例外にできるのは、遅延要件が緩いバッチ寄りの処理、社内向けの検証・分析用データベース、開発とプレビュー環境、そしてレイテンシよりも起動の速さと分岐のしやすさが効く生成AIエージェントのバックエンドです。国内本番に置くPostgresの基盤設計をどうするかは、リージョン要件とバックアップ方式まで含めて詰める話になるため、クラウド基盤の構築支援の枠で要件から設計するのが確実です。

Databricks傘下という前提が受託案件のリスク評価に与える影響

Databricksは2025年5月14日付のプレスリリースでNeon買収の意向を公表し、Neon公式ドキュメントも「2025年にNeonはDatabricksに加わった」と記載しています。同じ基盤はDatabricks側でLakebase Postgresとして提供され、Neon側はAuth・Functions・オブジェクトストレージ・AI Gatewayを束ねた開発者向けの構成、Databricks側はLakehouseやUnity Catalogとの統合という違いが説明されています。現時点でNeon単体の提供が止まる旨の記載はありません。

受託案件でのリスク評価は、製品の存続確率を当てにいく話ではなく、退避経路を書けるかどうかで決めます。Neonは標準のPostgresを動かしているため、論理レプリケーションやダンプでの引き上げが現実的な逃げ道になります。5年運用する前提の案件では、移行先の候補と作業量を保守契約の段階で明文化しておく。それが書けないなら採用しない、という基準にしておけば、買収後の方針転換が起きても判断がぶれません。

Aurora ServerlessやRDSと比べて選び分けるときの判断軸

比較の軸は4つに絞れます。リージョン要件、ブランチの要否、負荷が常時か断続か、セッション機能への依存度。国内リージョンが要るならこの時点でAWS側に決まり、Aurora Serverless v2のスケーリングと料金モデルを軸に検討する流れになります。

逆にNeonを選ぶ理由がはっきりするのは、検証環境を何度も作り直す開発フェーズと、夜間に完全に止まるワークロードです。Aurora Serverless v2は下限容量を保つ設計で、完全停止を前提にした課金体系ではありません。ゼロまで落として数百ミリ秒で戻す挙動が費用に直結する用途なら、Neonの構造が効きます。常時高負荷でセッション機能に依存する既存システムを載せ替える場面では、得るものより移行の手当てのほうが大きくなるため、そこはRDSやAuroraに置いたままにします。

よくある質問

Neonの検討時に判断が止まりやすい論点を、公式ドキュメントの記載に沿って整理します。

NeonはPostgreSQLと完全に互換ですか？

コンピュート層で動いているのは標準のPostgresなので、SQLの構文やドライバはそのまま使えます。対応メジャーバージョンは14から18の5世代です。ただし互換性の議論で問題になるのは本体の機能よりも周辺で、プール接続ではセッション変数やLISTENが使えず、メジャー更新はインプレースではなく新規プロジェクトへの移行になります。既存アプリを載せ替えるときは、この2点を先に確認してください。

Neonの無料プランはどこまで使えますか？

Freeプランは月額0ドルで、ストレージがプロジェクトあたり0.5GB、コンピュートがプロジェクトあたり月100 CU-hours、プロジェクト数100、ブランチはプロジェクトあたり10本です。オートスケールの上限は2 CU（8GB RAM）で、スケールトゥーゼロは5分後に必ず働き、無効化はできません。試作や小規模な検証には足りますが、テストデータを載せると0.5GBの枠に届きやすく、業務で使うなら有料プランが前提になります。

東京リージョンが無い状況ではどう運用すればよいですか？

アジアの選択肢はシンガポールとシドニーの2つです。国内ユーザーが対話的に操作する本番システムでは往復遅延が体感に乗るため、その用途では採用を見送る判断が妥当です。開発・検証環境や、遅延の影響が小さいバッチ処理、非同期のAI処理のバックエンドであれば実用の範囲に収まります。なお、プロジェクト作成後にリージョンは変更できないため、将来の移設を見込むなら移行手順を先に決めておいてください。

ブランチを増やすとストレージ費用はどれくらい増えますか？

分岐した瞬間はコピーオンライトで参照を作るだけなので、元データ分の課金は発生しません。増えるのは分岐後に新規作成・変更されたデータの分です。有料プランの単価は0.35ドル／GB-月なので、1GBの差分が積み上がっても月あたり0.35ドルの増加にとどまります。費用が問題になるのは、長命のブランチに大量の書き込みテストを流し続ける運用です。マージ後の削除をCIに組み込んでおけば、この積み上がりは抑えられます。

NeonとDatabricks Lakebaseはどちらを選べばよいですか？

公式ドキュメントは、両者が同じ基盤・同じ中核機能で、違うのは周辺だと説明しています。Neon側は開発者・スタートアップ・エージェント基盤向けにAuthやFunctionsを束ねた構成、Databricks側はLakehouseやUnity Catalogによる全社的なガバナンスとの統合が軸です。すでにDatabricksでデータ基盤を持ちUnity Catalogで統制しているならLakebase、アプリのバックエンドとして単独で使うならNeonという分け方が実情に合います。

関連記事

• PlanetScaleとは何か？次世代型サーバーレスデータベースの全貌：MySQL系でブランチ運用を提供する対比対象です。
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説：国内リージョンが要る場合の第一候補として比較できます。
• ライトアヘッドログとは：Neonが層間の唯一の接点に据えるWALの一般論を補えます。
• MVCCとは：Pageserverがページ版を組み立てる前提となる多版同時実行制御を整理しています。
• TimescaleDBとは？PostgreSQL拡張の仕組みと採用可否の判断基準：Postgresを拡張で伸ばす方向の選択肢です。