Neon で始めるサーバレス Postgres の実務ノート (日本・2026 年版)

1. サーバレス Postgres とは何か / なぜ Neon か

「サーバレス Postgres」というカテゴリは 2022 年頃から現れた新しい概念です。従来の Postgres は「常時起動しているインスタンス」を借りる形態で、開発中も本番も同じ料金が 走り続けます。一方サーバレス Postgres は「クエリが来た時だけコンピュートを起こす」 設計で、アイドル時は コンピュートが 0 にスケールインします。ストレージ層は常時稼働ですが安価 (Neon なら 1 GB あたり月 $0.10) なので、月間 100 万クエリ以下の小規模プロダクトならFree tier (¥0) で本番運用が可能 という驚異的なコスト構造になります。

Neon を選んだ理由は 3 つあります。第一に Postgres 完全互換 (フォークではなくバニラ Postgres 16/17 をコアに使っている) なので、 既存の psql / pg_dump / SQLAlchemy / Drizzle / Prisma が そのまま使える。第二に ブランチ機能 (後述) が git 的で、PR ごとに 本番と同じデータの独立コピーを作れる。第三に HTTP ドライバ が あるので、Vercel Edge Function や Cloudflare Workers から TCP コネクションなしで 叩ける。Supabase / Xata / PlanetScale (PSQL 版) と比べても、この 3 点セットを 全部満たすのは 2026 年時点で Neon だけです。

2. RDS / Supabase / Neon の実測比較

「どの DB を選ぶか」は宗教論争になりがちなので、ClearNets が実際に測定した数字で 並べます。全て東京リージョン (ap-northeast-1 相当) から東京の Vercel Function に 接続した際の実測です (2026 年 7 月計測、100 回平均)。

• AWS RDS (db.t4g.micro, PostgreSQL 16): 単純 SELECT p50=4ms、p99=12ms。月額最低 約 ¥2,500 (24h 稼働 + gp3 20GB)。VPC / Security Group / RDS Proxy の設定で 初期セットアップに半日〜1 日かかる。
• Supabase (Free tier, PostgreSQL 15): 単純 SELECT p50=18ms、p99=45ms。Free tier は ¥0 だが週 1 回の一時停止 (inactive) がある。REST/Realtime/Auth 込みなので DB 単体で 比較すると割高感、逆に Auth も欲しいなら圧倒的にお得。
• Neon (Free tier, PostgreSQL 17): HTTP driver で単純 SELECT p50=28ms、p99=65ms。cold start (suspend からの起床) 込み初回は約 500-900ms。¥0 で 0.5 GB ストレージ + 191.9 コンピュート時間/月。

レイテンシだけ見れば RDS が最速ですが、月額 ¥2,500 × 5 プロダクト = ¥12,500/月の 差分は個人開発では効きます。Neon の p50=28ms は「LP + Blog + 管理画面」用途では 気にならないレベル、投稿分析やチップ決済のようなユーザーが待つ画面 < 200ms 目標 にも余裕で収まります。 HFT やゲームサーバのような 10ms 要求案件だけは RDS 一択です。

3. Neon のブランチ機能を PR プレビュー環境で使う

Neon の最大の差別化ポイントが ブランチ (Copy-on-Write) です。本番 DB の完全コピーを数秒で作れて、ストレージも「差分のみ」課金です。 1 GB の本番 DB を 10 個ブランチしても、差分が 100 MB なら合計 1.1 GB 課金。 従来 pg_dump | pg_restore で数十分かかっていた「本番の コピーで検証」が git branch 感覚でできます。

ClearNets では GitHub Actions と組み合わせて、PR 作成時に自動でブランチを切り、 Vercel Preview Deployment にその DATABASE_URL を差し込む運用にしています。 PR ごとに独立した DB が立ち、他 PR や本番と完全に隔離されるので、 migration の検証やシード投入の副作用を気にせず reviewer が触れる。

# .github/workflows/preview-db.yml (要点)
- name: Create Neon branch
  id: branch
  run: |
    BRANCH_NAME="pr-${{ github.event.pull_request.number }}"
    curl -X POST https://console.neon.tech/api/v2/projects/$PROJECT_ID/branches \
      -H "Authorization: Bearer $NEON_API_KEY" \
      -d '{"branch":{"name":"'"$BRANCH_NAME"'","parent_id":"br-main-xxx"}}'
    # 返ってきた endpoint URL を GITHUB_OUTPUT に

- name: Deploy to Vercel with branch DB
  env:
    DATABASE_URL: ${{ steps.branch.outputs.url }}
  run: vercel deploy --prebuilt

PR が close/merge された時に自動でブランチを削除する Action も入れておくと ゴミが溜まりません。1 コマンドで本番の 100% コピー環境ができる のは、RDS スナップショット復元 (10-30 分) と比べて別物の開発体験です。

4. ClearNets の 4 プロダクトでの使い分け

同じ Neon でも、プロダクトごとに構成を変えています。用途と規模に応じた選択の実例。

• clearcast (投稿分析 SaaS): 単一 project、schema 分離 (public / analytics)。分析クエリが重いので autosuspend を 10 分に 伸ばしてコールドスタート頻度を減らす。0.5 GB / 月 の想定で Free tier。
• スキ活マーケット (teen-earn): 単一 project、Drizzle ORM + HTTP driver。決済系なので Pool (WS) driver との 2 系統併用 (詳細は §5)。 本番と staging の 2 ブランチを常設 + PR ごとの ephemeral ブランチ。
• Merci (チップ決済 SaaS): Stripe Webhook のトランザクションが 必要なので Pool (WS) driver 主用途。schema=payments で分離、監査ログを 別 schema に切って permission 分離。
• Kotsukotsu (習慣トラッカー PWA): 元は Supabase を使っていたが Auth 要件が Sign in with Google のみに落ち着いたので Neon + next-auth に 移行。データ量が少ないので Free tier で当分回る見込み。

5. connection pool の落とし穴と 3 種のドライバ

Neon には主に 3 つの接続方式があり、それぞれ用途が違います。ここを間違えると 「本番で謎の 504」や「トランザクションが効かない」で数日溶かします。

• @neondatabase/serverless の HTTP driver (neon()): 1 クエリ 1 HTTP。TCP 接続を張らないので Vercel Edge や Cloudflare Workers で使える。トランザクションは不可 (単一 SQL または db.transaction() の array 形式は可)。 読み取り中心の Server Component / API Route に最適。
• @neondatabase/serverless の WebSocket driver (Pool from @neondatabase/serverless): WS 経由で pooler に繋いで prepared statement / インタラクティブ tx も可能。 Node.js runtime (nodejs runtime) 必須。Stripe Webhook のような 「複数 SQL を 1 tx にまとめたい」場面はこれ一択。
• @vercel/postgres: 内部で Neon Pool を wrap したもの。 Vercel 環境ではゼロ設定で使えて便利だが、Neon 直接より抽象が 1 枚多く エラー時に何が起きたか追いにくい。新規案件では @neondatabase/serverless 直接を推奨。

pooling mode も 2 種類あります: Session mode (プリペアド ステートメント可、接続毎に固定) と Transaction mode (tx 単位で 接続をリサイクル、より高い並行性、ただし prepared statement 不可)。 Drizzle は Transaction mode 前提で書けば安全です。Prisma は Session mode 必須 だったのが最近 Transaction mode 対応が来たので、バージョン確認を。

6. Migration 運用 — Drizzle Kit vs 手書き SQL

Migration は「schema 変更を再現可能な形で残す」作業ですが、ツール選定で運用 コストが 3 倍違います。ClearNets は Drizzle Kit を採用していますが、複雑な migration (index rebuild / 大量 backfill) は手書き SQL に落とす hybrid 方式に落ち着いています。

• Drizzle Kit が得意: 単純な CREATE TABLE / ALTER TABLE ADD COLUMN / DROP COLUMN。schema.ts と drift を検出して SQL を自動生成。drizzle-kit generate → SQL レビュー → drizzle-kit migrate のフローで 1 分。
• 手書きに落とすべき場面: (a) 数百万行の backfill (batch update 必要)、(b) partial index の作成、(c) CHECK 制約の追加 (既存データ検証)、(d) enum の値追加/削除 (Postgres の enum は immutable)、 (e) tsvector 生成列の追加。これらは Drizzle 生成 SQL では意図通りにならない ことが多いので、生成後に手動で書き換え。
• 本番前の必須チェック 3 つ: (1) EXPLAIN で lock 種別確認 (ACCESS EXCLUSIVE は本番停止相当)、(2) 対象テーブルのサイズと想定所要時間、 (3) rollback SQL の事前作成。この 3 つを PR 説明欄に貼るテンプレートを 用意しています。

7. Row-Level Security の Postgres native な実装例

Supabase の売りの一つが Row-Level Security (RLS) ですが、これは Supabase 独自 機能ではなく Postgres 標準機能 です。Neon でも当然使えます。 マルチテナント SaaS では必須の防御層。

-- workspaces テーブルへの RLS 例
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY posts_workspace_isolation ON posts
  USING (workspace_id = current_setting('app.current_workspace_id')::uuid);

-- アプリ側から接続毎に workspace_id をセット
SET LOCAL app.current_workspace_id = '00000000-0000-0000-0000-000000000042';

-- これ以降のクエリは自動で WHERE workspace_id = '...' が挟まる
SELECT * FROM posts;  -- そのワークスペースの投稿のみ返る

Supabase の場合は auth.uid() を JWT から自動で取れる仕掛けが 入っていますが、Neon + Next.js の場合は自前でSET LOCAL app.current_workspace_id を各リクエスト冒頭で発行 する middleware を書くことになります。10 行程度の関数で書けます。「アプリのバグで workspace_id を where に書き忘れる」事故を DB 層で 機械的に防げる のは、監査上も強力です。

8. コスト実測 — Free tier で回している / Pro に上げる閾値

ClearNets は 4 プロダクトすべて Free tier で運用しています。実際の使用量:

• ストレージ: 全プロダクト合計 0.6 GB (Free 上限 0.5 GB × プロジェクト数)。プロジェクトを分けているので上限内。
• コンピュート時間: 月 約 30-50 時間 (Free 上限 191.9h)。autosuspend が効いていて、アイドル 5 分で 0 スケール。 真夜中は完全停止。
• データ転送: 月 数百 MB (Free 上限 5 GB)。分析系クエリは結果を圧縮して返すので余裕。

Pro tier ($19/月) にアップグレードすべき閾値は経験則で:

• MAU 1,000 超で日次アクティブが安定して 100+ ある → コンピュート時間が Free 枠を超える
• ストレージ 3 GB 超 → Free 枠を明確に超える
• 本番 DB の自動 daily backup + point-in-time restore が欲しくなった時 (Pro は 7 日保持)
• 複数チームメンバー招待や監査ログが必要な時

「まだユーザーが 100 人しかいないのに月額固定 $20 払っている DB」は個人開発では よくある無駄です。Neon Free tier は「収益がつく前は ¥0、ついたら Pro」 の理想的な料金曲線を実現します。

9. Vercel との組合せで気をつけること 5 つ

Neon + Vercel は蜜月関係にあり (Vercel は Neon に投資、公式統合あり) ですが、 本番投入で踏んだ罠を 5 つ記録しておきます。

1. region を揃える: Neon project 作成時に「AWS ap-southeast-1 (Singapore)」がデフォで、そのまま作ると東京 Vercel から 80ms 増える。必ずAWS ap-northeast-1 (Tokyo) を選ぶ。Free tier では後から region 変更不可 (dump/restore になる) なので最初が肝心。
2. cold start を許容できる画面か判断: autosuspend からの起床 初回は 500-900ms かかる。ユーザー動線の最初の画面 (ログイン直後など) ではautosuspend_delay を 10-15 分に伸ばしておく。
3. Edge Runtime か Node Runtime か: Edge Runtime では@neondatabase/serverless の HTTP driver しか使えない。tx が 必要なら Node runtime に切り替え (export const runtime = 'nodejs')。
4. lazy init パターン必須: build 時に DATABASE_URL 未設定でも crash しないよう、Proxy 経由の lazy init にする。let _sql: NeonQueryFunction を関数内で初期化するテクは前記事 (Next.js マーケットプレイス schema 記事) で 詳述。
5. preview branch の掃除: 前述の GitHub Actions で PR close 時に Neon branch も自動削除する。放置すると 100 個くらい溜まって管理画面が煩雑になる (課金は差分のみなので破産はしないが、視認性が悪くなる)。

10. まとめ — 意思決定フローチャート

Neon にすべきかどうかの判断は、以下のフローチャートで大体決まります。

• Q1. ユーザー画面のレイテンシ要件は?
  → 10ms 以下必須 (HFT / ゲームサーバ) → RDS + RDS Proxy
  → 200ms 以下で十分 (Web/SaaS/EC) → 次へ
• Q2. Auth / Storage / Realtime も一括で欲しい?
  → Yes → Supabase (Auth 込みなら DB 単体比較より圧倒的安い)
  → No、DB だけ欲しい → 次へ
• Q3. 月額 ¥0 で本番を回したい / PR プレビュー DB が欲しい?
  → Yes → Neon 一択
  → No、常時起動でよい → RDS (料金は月 ¥2,500 〜)

ClearNets の 4 プロダクトはすべて Q2=No / Q3=Yes だったので Neon になっています。 「月額 $19 の Supabase Pro に上げる前に、Neon Free で MVP を出す」パスは、 個人開発 / 少人数チームには極めてコスト効率が良い選択肢です。RDS/Supabase から の移行も pg_dump | pg_restore で数十分、schema 依存が Postgres 標準 から外れていなければハマりどころは少ないです。