Neonとは｜サーバーレスPostgresの仕組み・料金とSupabase・PlanetScaleとの違い

NeonPostgreSQL互換

Reactアプリの多くがVercelやNetlifyのようなサーバーレス環境にデプロイされるようになった一方、データベースは長らく「常時起動のサーバーを1台立てて接続する」という前提から抜け出せずにいました。開発・ステージング・本番のたびに別々のデータベースを用意し、テスト用に本番相当のデータを作るのも一苦労という状態です。この前提を、Postgres本体を分解して作り直すことで解決しようとしているのがNeonです。

Neonは、ストレージとコンピュートを分離したアーキテクチャで、Git風の瞬時ブランチングとスケールtoゼロを実現するサーバーレスPostgresです（Neon公式サイト）。2025年にDatabricksが買収し（Databricks公式プレスリリース）、Vercelが自社ブランドで提供していた「Vercel Postgres」もNeonへ統合されました。この記事では、Neonの仕組みと料金プラン、Supabase・PlanetScaleとの違い、導入前に確認しておきたい注意点を、各社の公式情報を基に整理します。

01.結論：Neonを選ぶ基準

3つのサービスは競合ではありますが、実際には「開発フローの何を楽にしたいか」で棲み分けています。比較に入る前に、自分たちが最も重視する観点を確認しておくと選びやすくなります。

この並びだけを見ると、可用性やスケールの面でPlanetScaleが優れているように読めるかもしれませんが、Postgresに関してはそうとは言い切れません。両者とも書き込みを1つのプライマリで受ける構成である点は同じで、Postgresのスケーラビリティで明確な優劣がついているわけではありません。詳しくは後述します。

02.Neonとは何か

Neonは2021年に創業したデータベース企業で、オープンソースのPostgresをベースに、ストレージとコンピュートを分離したクラウドネイティブな構成へ作り直したサーバーレスデータベースを提供しています（neondatabase/neon（GitHub））。2025年5月、DatabricksがNeonの買収に合意したと発表しました。Databricksの公式プレスリリースでは買収金額は明記されていませんが、TechCrunchの報道では約10億ドル規模の買収と伝えられています（Databricks公式プレスリリース／TechCrunch）。

Databricksが買収の狙いとして挙げているのが、AIエージェント時代のデータベース需要です。同社のプレスリリースによると、Neonのプラットフォーム上で作成されるデータベースの8割以上は人間ではなくAIエージェントが自動的に作成しており、必要なデータベースを必要な瞬間だけ立ち上げる使われ方が、すでに広がりつつあります。プレスリリースでは、DatabricksがNeonのデータベース・開発者体験への投資を続ける方針が示されており、2026年7月時点でもNeonはneon.comの自社ブランドのまま料金・製品ロードマップを運営しています。

03.Neonを支える仕組み

Neonの機能の多くは、「Postgresのストレージ層とコンピュート層を切り離す」という1つの設計判断から派生しています。ここでは、その設計が生む主要機能と、実際の開発フローへの組み込み方を見ていきます。

ストレージとコンピュートの分離

通常のPostgresは、データを書き込むディスクと、SQLを処理するプロセスが同じサーバー上に同居しています。Neonはこれを、WAL（Write-Ahead Log）を永続化するSafekeeper、ページデータを保持してコンピュートに配信するPageserver、実際にPostgresプロセスを動かすコンピュートという3つの層に分離しています。コンピュートは状態を持たず、必要なページをネットワーク越しにPageserverから取得して動作するため、起動・停止を自由に繰り返せます（Neon公式ドキュメント）。

この構成のもう1つの利点が、変更履歴を遡れる期間（History Window）を軸にした復元機能です。Neonの公式ドキュメントによると、WALの変更履歴をもとに任意の時点への瞬時復元（Instant Restore）や、過去の任意時点に接続してクエリを実行できるTime Travelが提供されています（Neon公式ドキュメント（Restore window））。保持期間はプランによって変わるため、詳しくは後述の注意点でまとめます。

ブランチング

Neonのブランチは、Gitのブランチのように親のデータベースの状態をコピーオンライトで瞬時に複製する機能です。実際のデータはコピーされず、親ブランチとの差分だけが新たに書き込まれるため、数百GBのデータベースであってもブランチの作成自体は数秒で完了します（Neon公式サイト）。プルリクエストごとに本番相当のデータを持つ検証用データベースを用意し、マージ後にブランチを削除する、といった運用を無理のないコストで回せるようになります。

ブランチングを開発フローへ組み込む

ブランチング自体は仕組みの説明だけでは実感しにくい機能です。Neonの公式ドキュメントは、ブランチをどの単位で切るかによって、開発フロー上の使いどころが変わると説明しています（Neon公式ドキュメント（Developer velocity with database branching workflows））。

同ドキュメントによると、GitHub ActionsやVercelとの統合を使えば、PRを作成した時点で自動的に専用ブランチが作られ、マージ後に削除するところまでを仕組み化できます。手作業でブランチを作り忘れる、削除し忘れて課金対象のまま残る、といった運用の抜けを防ぎたい場合は、最初からCI・デプロイの仕組みに組み込んでおくと安定します。

オートスケーリングとスケールtoゼロ

コンピュートが状態を持たないため、Neonは負荷に応じてコンピュートサイズを自動で伸縮させ、アクセスがない間はコンピュートを完全に停止する「スケールtoゼロ」に対応しています。停止中はコンピュート分の課金が発生せず、次のリクエストが来た時点で自動的に再起動します（Neon公式サイト）。開発用・検証用のブランチのように、アクセスが断続的なデータベースほど、この仕組みによる費用の削減効果は大きくなります。

04.料金プラン

Neonの料金体系は、無料のFree Planと、2段階の従量課金プラン（Launch・Scale）で構成されています。編集部が2026年7月に公式サイトで確認したところ、Launch・Scaleのどちらも固定の月額基本料金はなく、使った分だけ時間単位で課金される仕組みです。料金表のCU（Compute Unit）は、Neonが定めるコンピュートの処理能力を表す単位で、CU数が大きいほど扱えるメモリ・vCPUが増えます。

料金は2026年7月時点のNeon公式料金ページの目安です。SaaSの料金体系は改定されうるため、契約前に必ずリンク先で最新の内容を確認してください。

最低月額費用がない完全従量課金という点は、次章以降で比べるSupabase（Proプラン月額25ドル〜の固定料金＋従量分）やPlanetScale（最安でも月額5ドルからの固定契約）との明確な違いです。使用量が小さいプロジェクトを多数運用する場合ほど、Neonの課金体系はコストを抑えやすくなります。とりわけ、リリース前でまだ課金ユーザーがいない新規サービスの立ち上げ期には効果が大きく、アクセスがない時間帯はコンピュートがスケールtoゼロで停止するため、利用者がゼロの間はデータベース費用もほぼゼロに抑えられます。PlanetScaleのように固定契約が前提のサービスでは、この期間にも最低月額分の費用が発生します。

05.Supabaseとの違い

Supabaseは、Postgresをベースに認証・ストレージ・リアルタイム購読・Edge FunctionsまでをまとめたBaaS（Backend as a Service）です。データベース単体の機能で比べるとNeonと重なる部分もありますが、Supabaseはアプリのバックエンド全体を1つのプラットフォームでまかなう設計思想が軸になっています。

料金面では、Supabaseの公式サイトによると、Freeプランはデータベース容量500MB・エグレス5GBまで無料で、Pro以上は月額25ドルから、ブランチング機能はPro以上のプランで1ブランチ・1時間あたり0.01344ドルの従量課金アドオンとして提供されています（Supabase公式料金ページ）。Neonが全プラン（無料含む）でブランチングを標準搭載しているのに対し、Supabaseはブランチング自体が有料プラン前提の追加機能である点が違います。

06.PlanetScaleとの違い

PlanetScaleは、GoogleのVitessをベースにしたMySQL互換データベースとしてスタートし、現在はPostgres互換のプランも提供しています（PlanetScale公式ドキュメント）。PlanetScale最大の特徴は、スキーマ変更をプルリクエストとして提案し、レビューを経てから本番に適用する「デプロイリクエスト」の仕組みです。ただしこれはVitess（MySQL互換）側の機能で、公式ドキュメントによるとPostgres向けプランではブランチ間のスキーマ差分を手動で反映する運用になります（PlanetScale公式ドキュメント）。

一方PlanetScaleは、2024年3月に無料のHobbyプランの廃止を発表し、同年4月8日付けで終了しました（PlanetScale公式ブログ）。現在は無料プランがなく、公式料金ページによると最安のPostgres単一ノード構成でも月額5ドルからの有料契約が前提です（PlanetScale公式料金ページ）。個人開発や検証目的で無料のPostgresを探している場合、この違いは選定に直結します。

「PlanetScaleの方が大規模トラフィックに強い」と単純に言い切れるかというと、Postgresに関しては現時点でそこまで明確な差はありません。PlanetScale Postgresは独自基盤上でプライマリ＋レプリカの自動フェイルオーバーを標準搭載していますが（PlanetScale公式ドキュメント）、Vitessが持つような水平シャーディング機能はPostgres向けにはまだ提供されておらず、後継の「Neki」として2025年に発表されたものの、2026年7月時点ではプレビュー段階です（PlanetScale公式ブログ）。一方Neonも、コンピュートを最大56 CU（約224GB RAM）まで拡張でき、ストレージ層は常時複数AZへ冗長化されていて、Scale・Businessプランのコンピュートには99.95%のSLAが公表されています（Neon公式ドキュメント（High Availability））。どちらも書き込みを1つのプライマリで受ける構成である点は共通しており、水平シャーディングが必須になるような超大規模のワークロードでない限り、可用性・スケールだけを理由にPlanetScaleを選ぶ必要はありません。

この制約自体は、NeonやPlanetScale Postgresに限らずPostgres全般が前提とする設計です。書き込みをさらに伸ばす必要が出てきた場合の選択肢は、次のように段階を追って考えると整理しやすく、どのマネージドPostgresを選んでいても道筋は変わりません。

1. 垂直スケール：コンピュートサイズを上げる
2. リードレプリカ：読み取りをレプリカへ逃がし、プライマリは書き込み専用にする
3. 拡張機能によるシャーディング：Citusのような拡張で複数ノードへデータを水平分割する。Microsoftが2019年に買収し、Azure Database for PostgreSQLの「Elastic Clusters」として提供されています（Microsoft Learn）
4. 分散SQLへの移行：CockroachDB・YugabyteDBのような、複数ノードでの書き込みを前提に設計されたデータベースへ切り替える

水平シャーディングの検討が必要になるのは、基本的には前述のNeonの上限まで垂直スケールを使い切ってからです。まずはその範囲でどこまで足りるかを見極め、それでも足りない場合に上記のステップへ進むという順序で考えると、将来の水平シャーディングを心配してPostgresのベンダーを早々に選び直す必要はなくなります。

07.Vercelとの統合（旧Vercel Postgres）

Vercelは以前、Neonの技術を土台にした「Vercel Postgres」を自社ブランドで提供していました。Vercelの公式チェンジログによると、2024年11月にVercel MarketplaceでのNeon統合が始まり、既存のVercel Postgresデータベースも今後数か月かけてNeonへ順次移行すると案内されました（Vercel公式チェンジログ）。移行の詳細な手順は、Neon公式の移行ガイドにまとめられています（Neon公式ドキュメント（Vercel Postgres Transition Guide））。

現在Vercelから新規にPostgresデータベースを作成すると、Vercel Marketplace経由でNeonのプロジェクトが直接作成される仕組みになっています。VercelでNext.jsなどのアプリをホスティングしているチームにとっては、追加の契約なしにダッシュボードから完結してNeonを使い始められる点が、他のデータベースサービスにはない導線です。

08.導入の流れ

個人開発・小規模プロジェクトでNeonを使い始める場合、大まかな流れは次のとおりです。

09.導入前に確認しておきたい注意点

ブランチングやスケールtoゼロが便利な一方で、導入前に確認しておくとよい点もあります。

10.どんな人に向いているか

優劣で選ぶものではなく、開発フローのどこにコストと手間をかけたいかで向き不向きが変わります。

いずれのサービスも、Postgres本体との互換性を保ちながら独自の運用機能を積み上げているため、まずは無料枠やトライアルで実際にブランチを作ったり接続したりして、自分たちの開発フローに合うかどうかを確かめてから本番導入を判断すると、後戻りのコストを抑えられます。外注していた定型業務をAIで効率化したい場合は、次のTANTOUもご検討ください。

11.よくある質問（FAQ）

12.まとめ

Neonは、ストレージとコンピュートを分離した設計で、Git風の瞬時ブランチングとスケールtoゼロを全プランで標準搭載するサーバーレスPostgresです。2025年のDatabricksによる買収を経ても独立したサービスとして提供が続き、旧Vercel PostgresもNeonへ統合されたことで、Vercelユーザーにとっての既定の選択肢になっています。

Supabaseは認証・ストレージまで含むBaaSとしての総合力、PlanetScaleはMySQL（Vitess）側のPRレビュー体制とPostgresでも標準搭載するプライマリ＋レプリカ型の自動フェイルオーバーと、それぞれ異なる軸で強みを持っています。無料でブランチングを気軽に使い倒したいならNeon、バックエンド全体を1サービスで揃えたいならSupabase、従来型のHA構成や安全なスキーマ運用を重視するならPlanetScaleと、開発フローのどこを楽にしたいかを先に決めてから選ぶと選びやすくなります。