← Back to Notebook

Serverless Postgres「Neon」について

バックエンド開発AI / 機械学習NeonPostgreSQLpgvectorMCP

はじめに

最近サーバーレス構成やAIエージェントが絡む案件で「Neon」というデータベースサービスを耳にする機会が増えてきました。

今回、Webアプリ開発で実際に使ってみたので、サービスの概要から所感までまとめておこうと思います。

そもそもPostgresとは

ご存じの方も多いと思いますが、前提から軽く触れておきます。

PostgreSQL（通称Postgres）は、30年以上の歴史を持つオープンソースのリレーショナルデータベースです。

ANSI SQLへの準拠度の高さ、JSON型やPostGISなどの強力な拡張、トランザクションの堅牢性などから、AWS RDS、Google Cloud SQL、Supabase、Aurora など、あらゆるマネージドDBサービスのバックエンドで採用されている、現代のデファクトスタンダードと言える存在です。

最近ではAI関連サービスのバックエンドでも Postgres + pgvector の組み合わせが標準化しつつあり、「とりあえずPostgres」という選択がますます増えている印象です。

Neonの躍進も、この「Postgresが事実上の標準になっている」という潮流と無関係ではありません。

Neonとは

Neonは、PostgreSQLをサーバーレスで動かすことに特化したクラウドデータベースサービスです。

会社・歴史

  • 設立: 2021年、サンフランシスコ
  • 創業者（CEO）: Nikita Shamgunov 氏。データベース界の有名人で、SingleStore（旧MemSQL）の共同創業者でもある
  • 共同創業者: Heikki Linnakangas 氏など、PostgreSQLのコアコントリビューター複数名
  • GA（一般提供開始）: 2023年6月
  • Databricksによる買収: 2025年5月

立ち上げの動機としてNikita氏は、「既存のデータベース技術は90年代の前提で設計されている。

クラウドと現代の開発者ワークフローに合わせて作り直すべきだ」という問題意識を語っています。

特に、AWS Auroraの「ストレージとコンピュートの分離」というアイデアを取り込みつつ、それをオープンソースで再実装する、というのがNeonの出発点だったようです。

Databricks買収後の状況

買収後もNeonはスタンドアロン製品として運営されており、コアエンジンはオープンソースのまま維持されています。

（GitHubで neondatabase/neon として公開されています）

買収後、ユーザーにとって嬉しいニュースが続いています。

  • ストレージ料金が約80%値下げ（$1.75/GB → $0.35/GB-month）
  • コンピュート料金が15〜25%値下げ
  • 無料プランの計算リソースが2倍に拡張（50 → 100 CU-hours）

Databricks側からは「Neonは無くならない」「買収後にむしろ値下げした」というメッセージが発信されており、少なくとも今のところ買収はポジティブに作用しています。

Neonの核となるアーキテクチャ：ストレージとコンピュートの分離

Neonの最大の特徴は、ストレージ層とコンピュート層を完全に分離した独自アーキテクチャです。

発想としてはAWS Auroraに近いですが、AuroraがAWSプロプライエタリであるのに対し、Neonはオープンソースで実装されています。

ざっくり構成は以下のようになっています。

  • Compute Node: 通常のPostgresインスタンス。ステートレスで起動・停止が高速
  • Pageserver: スケーラブルなストレージバックエンド
  • Safekeepers: WAL（Write Ahead Log）を冗長的に受け取り、永続化する層

この分離があることで、後述する「スケールトゥゼロ」「ブランチング」といった機能がきれいに実装できています。

逆に言うと、これらの機能はNeonの根本的なアーキテクチャ設計から自然に出てきたもので、後付けの機能ではないという点が他のマネージドPostgresと違うところです。

Neonの主な特徴（メリット）

1. データベースブランチング（Gitライクな分岐）

個人的に「これは強い」と感じた一番の機能です。

本番DBから書き込み可能なコピーを一瞬で作成できます。

Copy-on-Writeで実装されているため、ブランチを作ってもストレージ容量はほとんど消費しません。

コードのブランチを切る感覚でDBのブランチが切れる、というイメージです。

ユースケース例:

  • プルリクエストごとにプレビュー環境のDBを自動生成
  • マイグレーションを本番データのコピーで事前検証してからマージ
  • AIエージェントが安全にデータを操作できる「使い捨てサンドボックス」として利用
  • バグ調査のために、障害発生時点のスナップショットを取り出して分析

VercelやNetlifyのプレビュー環境と組み合わせると、「PRごとに本番相当のDBを持つ」という運用が現実的にできます。

2. スケールトゥゼロ

一定時間アクセスがないとコンピュートが自動的に休止し、その間の課金が発生しません。

アクセスが来ると自動で再起動します。

各種ベンチマークによると、コールドスタートのレイテンシは概ね 300ms〜1秒程度。

一度ホットになれば通常のPostgresと変わらないレスポンスが得られます。

（同等条件でのAurora Serverless v2のコールドスタートは数秒〜十数秒という報告もあり、ここはNeonの強みです）

3. オートスケーリング

ワークロードに応じてCPU・メモリが自動で増減します。

事前にインスタンスサイズを見積もる必要がほぼなく、急なバーストにもある程度追従できます。

4. インスタント Point-in-Time Restore

WALを保持しているため、任意の過去時点に瞬時に巻き戻せます。

誤って DELETE FROM users; を打ってしまったときの安心感が違います。

5. 完全なPostgres互換

独自方言ではなく、本物のPostgresです。

pgvector、PostGIS、各種拡張もそのまま動きます。

既存のアプリケーションコードをほぼそのまま移行できる点は地味に大きいです。

デメリット・気をつけるべき点

良いことばかり書くと胡散臭くなるので、注意点も挙げておきます。

1. コールドスタートはユースケース次第で痛い

ユーザー向けAPIなどレイテンシ要求が厳しい用途では、一日に数回でも数百ms〜1秒の遅延が混じるのは許容しづらいでしょう。

本番では有料プランでスケールトゥゼロをオフにする運用が基本になります。

2. 常時稼働ワークロードでは旨味が薄い

24時間トラフィックが流れ続けるサービスでは、スケールトゥゼロの恩恵を受けられません。むしろRDSやAuroraの方がコストパフォーマンスが良いケースもあります。「変動の激しいワークロード」や「アイドル時間の長い環境」に特に強い、というのが正確な評価です。

3. ベンダーロックインの懸念

ブランチング、MCPサーバ、Neon独自のサーバーレスドライバなど、深く使うほどNeon固有の機能に依存します。

コアはオープンソースなので「いざとなれば自前で動かせる」とはいえ、その運用は別問題です。

4. Databricks買収後の長期方向性

今のところユーザー向けには良い方向に作用していますが、長期的にどう変わるかは未知数です。

Databricks本体の戦略変更次第では、価格や機能の方針が変わる可能性は頭に置いておく必要があります。

なぜ今Neonが注目されているのか

ここからは、海外コミュニティの反応も含めて、Neonが盛り上がっている理由を整理してみます。

理由1: サーバーレス全盛時代のDBとして相性が良い

Vercel、Cloudflare Workers、AWS Lambdaなど、サーバーレス基盤での開発が一般化した結果、

「アプリ側はサーバーレスなのにDBだけ常時起動」という非対称な構成が目立つようになりました。

Neonはこの違和感を解消します。

理由2: AIエージェントとの相性が異常に良い

これがおそらく最大の追い風です。

Databricks買収時の発表によると、

Neon上で作成されるデータベースの80%以上が、人間ではなくAIエージェントによる自動生成だったとのこと。

AIエージェントが「タスクごとにDBを作って、データを入れて、検証して、不要になったら捨てる」というワークフローを回すには、

  • 数秒以内にプロビジョニング完了
  • API経由でフル管理可能
  • 使わなければほぼ無料

という条件が必要で、Neonはこれを高いレベルで満たします。

理由3: 公式MCP（Model Context Protocol）サーバ

Claude、Cursor、Devinなどから自然言語でDB操作ができる公式MCPサーバを早い段階で提供しました。

「ブランチを作って、マイグレーションを試して、問題なければマージ」のような一連の流れをAIに任せる体験は、

一度味わうとなかなか戻れません。

理由4: Databricks買収による安心感

個人開発者向けスタートアップにありがちな「サービス突然終了」リスクが、Databricks傘下になったことで大きく下がりました。

エンタープライズ採用のハードルも明確に下がっています。

海外エンジニアの反応

開発者コミュニティの反応は概ね好意的です。

Hacker NewsのGA発表スレッドでは「これまで使った中で群を抜いて使いやすいサーバーレスDB」といった声があり、特にブランチング機能への評価が高い印象です。

AWS RDSから移行した開発者からは「典型的なOLTPワークロードでパフォーマンスが落ちなかった」という報告も上がっています。

一方で慎重派の意見もあり、「ミリ秒単位のレイテンシが必要な本番ワークロードや、99.99%のSLAが必要なケースでは、まだ専用インスタンスや既存のマネージドDBの方が安心」という見方も根強くあります。

要するに、「全部Neonに寄せる」のではなく「適した用途に使う」というのが現状のコンセンサスのようです。

無料プランについて

個人開発で試すなら、まず無料プランで始めるのがおすすめです。

2026年時点での無料プラン主な内容は以下のとおりです。

項目 内容
コンピュート 月 100 CU-hours（過去 50 から倍増）
ストレージ 0.5 GB / プロジェクト（最大 10 プロジェクト）
オートスケール 最大 2 CU まで
ブランチング 無制限
スケールトゥゼロ 有効
クレジットカード 不要
商用利用 OK
期限 なし（ずっと無料）

CU（Compute Unit）は 0.25 CU = 0.25 vCPU + 1 GB メモリ相当です。

0.25 CU で動かせば月 400 時間ぶん使える計算になるので、個人ブログや軽い社内ツールなら十分収まります。

無料プランでもブランチングやオートスケールが使えるのが大きく、競合と比較しても「機能制限が緩い」と評価する声が多いです。

所感

実際に触ってみて素直に感動したのは、「とりあえずDBが欲しい」と思ったときの心理的ハードルが圧倒的に下がることです。

コンソールでポチポチと数十秒待つだけで本物のPostgresが立ち上がり、接続文字列を環境変数に貼るだけで開発をスタートできる体験は、一度味わうと病みつきになります。

特にブランチング機能は、開発プロセスそのものを変革する力を持っています。

これまでは「本番データが絡むマイグレーションは怖い」という心理的ブレーキが少なからずありましたが、「一瞬でブランチを切って試し、ダメなら捨てる」がGit感覚で回せるため、試行錯誤のサイクルが体感で何倍も速くなりました。

一方で、本番運用における「スケールトゥゼロ」の採用は慎重に見極める必要があります。

ミリ秒単位のレスポンスが求められるユーザー向けAPIでは、やはりコールドスタートの遅延（数百ms〜1秒）がネックになり得ます。

ですが、CI環境、ステージング（プレビュー）環境、社内ツール、そしてAIエージェント用の使い捨て sandbox といった「動いていない時間が長い環境」においては、コスト面でも運用面でも、今やNeon以外の選択肢を考えられないほどの魅力を放っています。

まとめ

  • NeonはPostgresのコアコントリビューターたちが立ち上げた、サーバーレスPostgresに特化したサービス
  • ストレージとコンピュートの分離という独自アーキテクチャにより、ブランチング・スケールトゥゼロ・オートスケールを実現
  • AIエージェント時代の「使い捨て可能なDB」という新しいニーズに刺さっている
  • 無料プランがかなり太っ腹なので、まずは触ってみるのが早い

「Postgresは好きだけど運用が面倒」「サーバーレス構成にDBだけ追従できていない」「AIエージェントを絡めた開発を試したい」というチームには、一度検討する価値が十分にあると思います。