身為後端工程師，你一定遇過這個問題：開發新功能需要跑 migration，但你不敢在正式資料庫上測試，本地的 Docker Postgres 又跟 production schema 對不上。如果資料庫能像 Git 一樣開分支就好了——Neon 就是做這件事的。

Neon 是什麼？為什麼值得關注

Neon 是一個開源的 Serverless PostgreSQL 平台，最大的特色是把儲存和運算完全分離。這個架構帶來三個殺手級功能：自動擴縮（Autoscaling）、縮放到零（Scale to Zero）、以及我們今天要聊的重頭戲——Database Branching。

2025 年底 Neon 被 Databricks 收購後，大幅降價：各層級運算成本下降 15-25%，儲存價格從每 GB/月 $1.75 降到 $0.35，免費方案的運算額度也翻倍到每月 100 CU-hours。這讓它在個人開發者和小團隊中的競爭力大增。

如果你用過 Supabase 或 PlanetScale，Neon 的定位類似，但 branching 功能目前是同類產品中最成熟的。

Database Branching 底層架構

Neon 的分支功能建立在 copy-on-write（CoW）儲存架構上。當你建立一個分支時，Neon 不會複製整個資料集。它建立一個新的 compute 層指向與父分支相同的底層儲存頁面，只有分支上新的變更才會被儲存為差異。

這代表幾件事：

建立分支幾乎是瞬間完成的（不管你的資料庫有多大）
分支不會佔用額外的儲存空間（除了你在分支上做的修改）
分支之間完全隔離，不會互相影響

這跟 Git 的分支概念幾乎一樣，只是對象從程式碼變成了資料庫。

環境設定與 CLI 安裝

開始之前，你需要安裝 Neon CLI：

npm install -g neonctl
neonctl auth

登入後，建立一個專案：

neonctl projects create --name my-app

這會給你一個 main 分支和對應的連線字串。把連線字串存到 .env.local 的 DATABASE_URL 就可以開始用了。

相關推薦：對後端資料庫技術有興趣的話，也可以看看 Drizzle ORM 完全攻略，了解 TypeScript 類型安全的資料庫操作方式。

分支開發工作流程實戰

以下是我自己用 Neon branching 的標準工作流程：

Step 1：建立功能分支

neonctl branches create feature-user-auth \n  --project-id p-abcdef123456 \n  --parent-branch-name main

這會建立一個叫 feature-user-auth 的資料庫分支，包含 main 分支的完整 schema 和資料。

Step 2：取得分支連線字串

neonctl connection-string feature-user-auth

把拿到的連線字串更新到你的 .env.local，你的應用就會連到分支資料庫了。

Step 3：開發與遷移

在分支上自由地跑 migration、修改 schema、塞測試資料。不管你怎麼搞，都不會影響 main 分支。

npx prisma migrate dev --name add-user-roles
# 或是用 Drizzle
npx drizzle-kit push

Step 4：確認後合併

確認功能正常後，把 migration 檔案合併到 Git main branch，然後在 main 資料庫分支上執行同一份 migration。最後清理分支：

neonctl branches delete feature-user-auth

這個流程最大的好處是，你在開發過程中用的是真實的 production schema 和資料（而不是本地 Docker 裡可能已經過時的版本），但完全不會影響正式環境。

CI/CD 整合：自動建立測試分支

Neon branching 真正發揮威力的地方是 CI/CD。在 GitHub Actions 中，你可以這樣設定：

name: PR Database Branch
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: neondatabase/create-branch-action@v5
        id: create-branch
        with:
          project_id: ${{ secrets.NEON_PROJECT_ID }}
          branch_name: pr-${{ github.event.number }}
          api_key: ${{ secrets.NEON_API_KEY }}

      - name: Run migrations
        env:
          DATABASE_URL: ${{ steps.create-branch.outputs.db_url }}
        run: npx prisma migrate deploy

      - name: Run tests
        env:
          DATABASE_URL: ${{ steps.create-branch.outputs.db_url }}
        run: npm test

每個 PR 都會自動建立一個獨立的資料庫分支來跑測試，PR 關閉後自動刪除。再也不用為了跑整合測試而維護一個共用的 staging database 了。

搭配 Vercel Preview 環境

如果你用 Vercel 部署，Neon 有官方的 Vercel Integration。每次 Vercel 建立 preview deployment 時，Neon 會自動建立一個對應的資料庫分支，並把連線字串注入到 preview 環境的環境變數中。

這代表你的每個 preview URL 都有自己獨立的資料庫，可以自由修改不會互相干擾。想想以前 staging 資料庫被多個 PR 同時改 schema 搞到爆炸的日子，這真的是救贖。

對系統架構有興趣的話，也推薦看 WebAssembly 後端開發教學，了解 Wasm 在 Serverless 架構中的應用。

2026 年定價與免費方案分析

經過 2025 年底的大幅降價，Neon 的定價變得相當有競爭力：

免費方案：100 CU-hours/月、512 MB 儲存、10 個分支。對個人專案和學習來說綽綽有餘
Launch：$19/月，適合小團隊開發
Scale：$69/月，適合生產環境
儲存：$0.35/GB/月（比之前便宜 80%）

跟自己架設 Postgres + 管理備份的成本比起來，其實挺划算的，特別是你不需要「隨時有一台機器在跑」這種傳統 RDS 的計費模式。

結語

Neon 的 Database Branching 解決了後端開發中一個長久以來的痛點：如何安全地在真實資料環境中開發和測試。CoW 架構讓分支建立幾乎零成本，搭配 CI/CD 和 Vercel 整合後，可以實現真正的「每個 PR 都有獨立的完整環境」。如果你目前還在用 Docker 本地 Postgres + 手動同步 schema 的工作流程，我強烈建議試試看 Neon，體驗一下「資料庫版的 Git」帶來的效率提升。