Neonとは｜料金・使い方・無料枠を実例で整理するサーバーレスPostgreSQL完全ガイド2026
この記事のポイント Neonは「使っていない時間は課金が止まる」サーバーレスPostgreSQL。本物のSQLデータベースをほぼゼロ円から立ち上げられ、Gitのようにデータベースを枝分かれ（ブランチ）させて検証できる。pgvector対応でRAGやAI検索の保存先にもなる。一方でUIは英語のみ、無料枠には上限がある。SupabaseやFirebaseとの線引きを押さえれば選定は早い。
Neonとは、使っていない時間は課金が止まるサーバーレス型のPostgreSQLデータベースです。
PostgreSQL（ポストグレス）は、世界中の業務システムで使われている定番のSQLデータベース。Neonはその中身をそのまま使いながら、料金と運用の仕組みだけを今風に作り替えた。だから既存のSQL知識もツールも、ほぼそのまま流用できる。
ここが他のクラウドDBと一番違う。MySQLでもNoSQLでもない、純正のPostgreSQLが動く。乗り換えコストが低い理由はここにある。
この記事では、料金プランの読み方、無料枠でどこまでやれるか、登録から最初の接続までの手順、そしてSupabaseやFirebaseとの選び分けまでを、公式の料金情報を引きながら一本でたどれるようにした。
Neonは「止まっている間はタダ」のPostgreSQL
Neonの正体は、ありふれたPostgreSQLだ。特別な独自言語も独自APIもなく、既存のSQL資産やORM、psqlがそのまま動く。違うのは課金と運用の仕組みの方にある。
最大の特徴は、計算リソース（コンピュート）とストレージを分離した設計にある。アクセスが来た時だけコンピュートが起動し、しばらく無アクセスだと自動でスリープする。スリープ中はコンピュート課金がゼロになる。
ここでいうコンピュートとは、SQLを実際に処理する「計算する箱」のこと。データを保管しておくストレージとは別物だ。この二つを切り離したから、保管だけ続けて計算は止める、という芸当ができる。
個人開発の検証用DBや、たまにしか叩かれない管理画面のバックエンドだと、月の請求がストレージ代だけになることも珍しくない。「常時起動のDBを借りると、使わない夜間も課金される」という従来の悩みを構造から消しにいったのがNeonだ。
もう一つの背景として、Neonは2025年にデータ基盤大手Databricksに買収されている（複数の業界報道、2026-06-28時点）。AI／データ基盤の文脈で投資が続く土台のあるプロダクト、という安心材料にはなる。
料金プランはいくら？（無料枠・Launch・Scaleの3層）
Neonの料金は、固定の月額サーバー代ではない。「使ったコンピュート時間」と「保存しているストレージ量」で決まる従量型だ。まず無料枠で試し、上限に当たったら有料へ、が王道になる。
プランは大きく3層。最新の正確な金額・上限は変動するため、本番判断の前に公式の料金ページで必ず確認してほしい。以下は公式料金ページの公開値（最終確認: 2026-06-28）をもとにした整理だ。
| プラン | 月額 | コンピュート単価 | ストレージ単価 | 想定する使い方 |
|---|---|---|---|---|
| Free | $0 | 無料枠内（100 CU時間/プロジェクト） | 無料枠内（0.5GB/プロジェクト） | 個人開発・学習・検証 |
| Launch | 月額固定なし（従量） | $0.106 / CU時間 | $0.35 / GB・月 | 小〜中規模の本番、複数プロジェクト |
| Scale | 月額固定なし（従量） | $0.222 / CU時間 | $0.35 / GB・月 | チーム運用・大きめの負荷 |
注目すべきは、有料プランから「月額の最低料金（最低$5/月）」が撤廃された点だ（公式料金ページ、2026-06-28時点）。つまり使った分だけ払う、純粋な従量制になった。眠っているプロジェクトに固定費が乗らない。
ここで出てくるCUとは、コンピュートの大きさを測る単位（コンピュートユニット）。1 CUはおおよそ4GBメモリ相当の計算能力で、これを何時間動かしたかが「CU時間」だ。常時フル稼働させればその分積み上がり、スリープが効くワークロードなら安く収まる。
逆に、24時間365日フルロードがかかり続ける高負荷サービスでは、サーバーレスのうまみが薄れ、専用インスタンス型の方が読みやすいこともある。自分のアクセスパターンを思い浮かべてから階層を選ぶといい。
ストレージ単価はかつて$1.75/GB・月だったが、現在は$0.35/GB・月（公式料金ページ、2026-06-28時点）。値下げの流れが続いているので、古い記事の金額をうのみにしないこと。
無料枠でどこまでできるのか？
無料枠の価値は「ちゃんと動くPostgreSQLを、クレカ登録なしで触れる」ことに尽きる。学習・プロトタイプ・趣味アプリなら、有料に上げないまま走り切れるケースも多い。
具体的な無料枠の中身はこうだ（公式料金ページ、最終確認 2026-06-28）。
- コンピュート: 100 CU時間／プロジェクト（アイドル時はゼロまで自動縮小）
- ストレージ: 0.5GB／プロジェクト
- プロジェクト数: 最大100
- ブランチ数: プロジェクトあたり最大10
100 CU時間という枠は、検証や学習なら十分に余裕がある。ただし本番トラフィックを継続的に受ける用途だと、コンピュート時間とストレージのどちらかから先に上限へ届く。常時起動アプリには向かない、と覚えておけばいい。
実務的には「無料枠で設計とPoC（試作検証）を固め、ローンチのタイミングで有料に切り替える」流れが扱いやすい。無料のうちにブランチ運用やpgvectorの感触を確かめておくと、課金後の判断が速くなる。
データベースブランチ — Neon最大の武器
Neonを他のマネージドPostgreSQLと分ける一番の機能が、データベースのブランチだ。Gitでコードを枝分かれさせるのと同じ感覚で、データベースまるごとのコピーを一瞬で作れる。
ブランチは本番データのコピー・オン・ライト方式で作られる。これは「変更があった部分だけ新しく書く」やり方のこと。だから巨大なテーブルでも作成が速く、容量も最初はほぼ食わない。本番に触れずに「もし大改修したら」を試せる。
使いどころは具体的だ。
- スキーマ変更（テーブル構造の変更）を本番コピー上で先にリハーサルする
- プルリクエストごとに使い捨てのプレビューDBを自動生成する
- 障害調査で「事故った瞬間」の状態を復元して原因を追う
特にCI/CD（コードの自動テスト・自動公開の仕組み）と組み合わせると強い。プレビュー環境ごとに独立したデータベースが立ち上がるので、「テスト同士がデータを汚し合う」問題から解放される。開発体験の改善幅が大きいのはここだ。
CursorのようなAIエディタでマイグレーションコードを書き、ブランチ上で安全に試す、という流れも組みやすい。AIコーディング全般の選択肢はAIコーディングツールのカテゴリも合わせて見ておくといい。
pgvector対応でAI検索・RAGの保存先になる
NeonはPostgreSQL拡張のpgvectorに対応しており、埋め込みベクトル（文章の意味を数値の並びに変換したもの）をそのままテーブルに保存して類似検索できる。専用のベクトルDBを別途立てなくても、AI機能のバックエンドが一つで済む。
RAG（社内資料などをAIに読ませて答えさせる仕組み）では、ドキュメントを埋め込みベクトルに変換してNeonへ保存し、ユーザーの質問に近い文書を引いてLLM（大規模言語モデル）へ渡す、という流れを組める。アプリのデータとベクトルを同じPostgreSQLに同居させられるのが利点だ。
専用ベクトルDBに比べれば、超大規模・超低レイテンシ用途では見劣りする場面もある。ただ、個人〜中規模のAIアプリなら「Neon一本でアプリデータもベクトルも管理」は構成がシンプルで保守が軽い。最初の一歩としては十分現実的だ。
Difyやv0 by VercelのようなツールでAIアプリを組むときの、データ層をNeonに寄せる構成も相性がいい。RAGの全体像を先に押さえたいならRAGの仕組みガイドが早い。DifyとNeonをどう組み合わせるかはDifyとNeonの比較も参考になる。
ステップ1: アカウント作成とプロジェクト生成
最短ルートはシンプルだ。アカウントを作り、プロジェクトを生成し、接続文字列をアプリに貼る。ここまで数分で、本物のPostgreSQLが手に入る。
公式サイトからGitHubアカウントなどで登録する。最初のプロジェクトを作ると、自動でデータベースとブランチ（main）が一つ用意される。リージョン（サーバーの設置地域）は利用者に近い場所を選ぶとレイテンシ（応答の遅れ）が下がる。日本のユーザー主体なら東京リージョンが無難だ。
ステップ2: 接続情報を控える
ダッシュボードに表示される接続文字列（postgresql://... で始まる接続先の住所）をコピーする。これがアプリやORM（PrismaやDrizzleなどのDB操作ライブラリ）からの接続先になる。
サーバーレス環境向けには、HTTP/WebSocket経由のドライバも用意されている。Vercelなどのサーバーレス基盤から叩くなら、こちらを使うと接続まわりの相性がいい。
ステップ3: 最初のテーブルとデータ
Web上のSQLエディタ、またはローカルのpsql（コマンドラインのPostgreSQL操作ツール）からテーブルを作り、テストデータを入れる。接続できたら、アプリ側から読み書きを確認する。
AI用途ならここでpgvector拡張を有効化し、ベクトル列の設計に進む。CREATE EXTENSION vector; を一度実行するだけで使えるようになる。
UIは英語のみだが、PostgreSQLを触ったことがあれば迷う場面は少ない。最初だけ「プロジェクト＝ブランチ＝エンドポイント（接続口）」の関係を押さえておくと混乱しない。
こんな人に向いている / 向いていない
向き不向きがはっきりしているツールだ。「本物のPostgreSQLが欲しいか」「英語UIと接続設計を許容できるか」で判断するとブレない。
向いている人
- 波のあるトラフィックで、アイドル時の課金を止めたい開発者
- 本番に触れずスキーマ変更やマイグレーションを検証したい人
- PRごとに使い捨てプレビューDBを自動で立てたいチーム
- pgvectorでRAGやAI検索の保存先を一本化したい人
向いていない人
- 日本語UIで完結させたい、SQLにあまり触れたくない人
- 画面・認証・ストレージまで一体で欲しいオールインワン志向の人
- 24時間フルロードが続き、サーバーレスの利点が出ない高負荷用途
- 料金上限を確認せず本番トラフィックをいきなり流したい人
ノーコードで画面まで作りたいタイプの人は、NeonよりノーコードAIツールのカテゴリから入った方が早い。
どこでつまずきやすい？注意点と落とし穴
便利な反面、サーバーレス特有のクセもある。事前に知っておけば回避できるものばかりだ。
最も多いのがコールドスタート。スリープ状態から最初のアクセスでコンピュートが起動するため、初回リクエストに一瞬の待ちが出る。常に即応が必要なら、起動を維持する設定やプランを検討する。
接続管理も要注意だ。サーバーレス関数から大量に接続すると上限に当たりやすい。Neonが提供するコネクションプーリング（接続をまとめて使い回す仕組み）用のエンドポイントを使うのが基本になる。ここを誤ると本番で詰まる。
そしてUIは英語のみ。無料枠にはコンピュート稼働時間（100 CU時間/プロジェクト）とストレージ（0.5GB/プロジェクト）の上限がある。「気づいたら無料枠を超えていた」を避けるため、使用量の確認とアラート設定は最初にやっておきたい。データ分析寄りの重い使い方をするならAIデータ分析ツールのカテゴリの選択肢も視野に入る。
SupabaseやFirebaseとどう違う？
「Neon vs ◯◯」で迷うなら、軸は明快だ。Neonは"データベースに特化"、競合は"バックエンド一式"という違いに集約される。
| 比較ツール | 立ち位置 | Neonと比べた選び分け |
|---|---|---|
| Supabase | PostgreSQL＋認証/ストレージ/APIの一式 | 周辺機能も欲しい→Supabase、純粋なDBとブランチ運用→Neon |
| Firebase | アプリ向けバックエンド（NoSQL寄り） | リアルタイム/モバイル一体→Firebase、SQL資産とpgvector→Neon |
| Xano | ノーコードでAPI/ロジックまで構築 | 画面裏のロジックまで作る→Xano、DB層だけ任せる→Neon |
要するに、「アプリの土台を丸ごと欲しい」ならSupabaseやFirebase、「最高のPostgreSQLだけを安く柔軟に」ならNeon。両者は競合というより、レイヤーが違う。Supabase自身が内部でNeon的なサーバーレス思想を取り込む動きもあり、境界は今後さらに動く。
ノーコードのBubbleとの違いが気になるならBubbleとNeonの比較、kintoneのような業務アプリ基盤との違いはkintoneとNeonの比較が手早い。
よくある質問（FAQ）
Q. Neonは完全無料で使い続けられますか？
無料枠の範囲なら課金は発生しない。具体的には100 CU時間/プロジェクトと0.5GB/プロジェクトが上限（公式料金ページ、2026-06-28時点）。本番トラフィックを継続的に受けると超過しやすい。学習やプロトタイプは無料、ローンチで有料、が現実的な流れだ。
Q. 既存のPostgreSQLからNeonへ移行できますか？
できる。Neonは標準的なPostgreSQLなので、pg_dump／pg_restoreでの移行が基本だ。アプリ側は接続文字列を差し替えるだけのことが多い。ただしバージョンや拡張機能の対応は事前に確認しておくと安全だ。
Q. コールドスタートはどのくらい遅いですか？
スリープからの初回起動で短い待ちが入る。多くのケースでは体感できる範囲だが、常時即応が必須のサービスでは無視できない。起動を維持するオートサスペンド設定の調整や、上位プランでの対応を検討する。
Q. AI開発でNeonを使うメリットは？
pgvectorでベクトルをアプリデータと同じDBに保存でき、構成がシンプルになる点だ。さらにブランチ機能で、AI機能の実験を本番から隔離して回せる。RAGの保存先を一本化したい個人〜中規模開発と相性が良い。
Q. 日本語のサポートやUIはありますか？
UIは英語のみで、日本語UIは提供されていない。とはいえ操作はPostgreSQLの一般的な流儀に沿っており、SQL経験があれば大きな障壁にはなりにくい。
Q. CUとは何ですか？料金はどう計算されますか？
CU（コンピュートユニット）はコンピュートの大きさを測る単位で、1 CUはおおよそ4GBメモリ相当だ。請求は「CU時間（CUの大きさ×稼働時間）×単価」＋「ストレージ量×単価」で決まる。Launchの単価は$0.106/CU時間、ストレージ$0.35/GB・月（公式料金ページ、2026-06-28時点）。
Q. クレジットカードなしで始められますか？
始められる。無料枠（Free）はクレカ登録不要でアカウントを作れる。有料プランへ移るタイミングで支払い情報を登録する流れなので、まず触ってから判断できる。
Q. SupabaseとNeon、どちらを選ぶべきですか？
認証・ストレージ・APIまで一体で欲しいならSupabase、純粋なPostgreSQLとブランチ運用を安く柔軟に回したいならNeonだ。レイヤーが違うので「両方使う」も普通にある。詳しくは本文の比較表を参照。
編集部の評価
正直に言って、Neonは「サーバーレスPostgreSQL」というジャンルで頭ひとつ抜けている。特にデータベースブランチは、一度CI/CDに組み込むと手放せなくなる種類の機能で、開発体験への効きが大きい。ここは破格だ。
コスト面も、波のあるトラフィックや個人開発では圧倒的に有利になりやすい。有料プランの最低月額が撤廃され、ストレージ単価も$1.75→$0.35/GB・月へ下がった流れ（公式料金ページ、2026-06-28時点）は、検証用DBを気軽に量産する後押しになる。「使わない時間は止まる」という一点だけでも価値がある。pgvector同居でAIアプリの土台になれるのも重宝する。
一方で、認証もストレージも欲しいオールインワン志向ならSupabaseの方が話が早い。英語UI・接続設計・コールドスタートの三点は、初学者にはやや段差になる。「本物のSQLを安く柔軟に運用したい開発者向け」という線が明確なツールで、その層には一択に近い。万人向けではないが、刺さる人には深く刺さる。
迷ったら、無料枠でブランチを一本切ってマイグレーションをリハーサルしてみるといい。その体験で、自分の開発に合うかは大体わかる。ツールの詳細はNeonのツールページも合わせてどうぞ。
あわせて読みたい
Neon周辺の比較・関連トピックは、次の記事で深掘りできる。
- DifyとNeonの比較 — AIアプリ基盤としてのデータ層をどちらに寄せるか
- BubbleとNeonの比較 — ノーコードで完結させるか、DBだけ任せるか
- RAGの仕組みガイド — pgvectorを活かす前に押さえたい全体像
