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とは？仕組み・ベクトルDB・最新動向まで完全解説 (2026年版)：pgvectorを活かす前に押さえたい全体像
