做 Vibe Coding 最常卡住的地方，通常不是畫面，而是資料庫。前端請 AI 生一生很快，輪到會員登入、資料表、檔案上傳、權限和 API，事情馬上變多。這時候我很常推薦 Supabase：它是一套以 PostgreSQL 為核心的開源後端，和 Codex、Claude Code、Cursor 這類 AI Agent 串起來很順。
更直接一點說，Supabase 很適合「我想趕快做出能登入、能存資料、能上傳圖片，而且未來還能繼續長大」的專案。它不只是一個雲端資料庫，Auth、Storage、Realtime、Edge Functions 和自動產生的 API 都已經準備好，現在連官方 MCP 與 Agent Plugin 都有了。
我不會說每個 Vibe Coding 專案都非 Supabase 不可，但只要產品有會員、關聯資料和正式上線的打算，它通常會是我最先拿出來評估的選項。
Supabase 是什麼？它不只是雲端資料庫
Supabase 每個專案拿到的是一套完整的 PostgreSQL，不是把資料包成另一種封閉格式。你可以用後台 Table Editor 管理資料，也能直接寫 SQL、建立關聯、索引、View、Function 與 Trigger。官方的 Database 文件也很明確：Auth、Storage、Realtime 和 Edge Functions 都建立在這套 Postgres 基礎上。
| Supabase 功能 | 可以處理什麼 | Vibe Coding 的好處 |
|---|---|---|
| PostgreSQL Database | 資料表、關聯、SQL、索引與函式 | AI 很熟 SQL 與 Postgres，產生的程式碼比較容易理解與維護 |
| Data API／SDK | 用 REST 或各語言 SDK 存取資料 | 不用先手寫一整套 CRUD API |
| Auth | Email、密碼、Magic Link、OTP、社群登入與 SSO | 會員系統不用從零開始 |
| Storage | 圖片、文件、影音與 Bucket 權限 | 上傳功能可以直接和會員權限整合 |
| Realtime | 監聽資料變更與即時訊息 | 聊天、通知、看板比較快做出來 |
| Edge Functions | TypeScript Serverless Function、Webhook 與第三方 API | 需要保密金鑰或後端邏輯時有地方放 |
| MCP／Agent Plugin | 讓 AI Agent 讀取專案、查資料庫、管理 Migration | Codex、Claude Code、Cursor 能更準確地協助開發 |
為什麼 Supabase 特別適合 Vibe Coding？
AI 寫程式最怕資訊不完整。你只說「幫我做會員資料庫」，它很容易猜欄位、猜權限、猜 API。Supabase 的 Schema、SQL Migration、TypeScript 型別和官方文件都很結構化，AI 比較容易看懂目前專案到底有哪些表、欄位和關聯。
前端可以直接串，不用每次先搭後端 API
簡單的 CRUD 可以透過 Supabase SDK 從瀏覽器呼叫。只要資料表權限與 Row Level Security 設計正確，前端就能安全地讀寫使用者被允許碰到的資料。這對 MVP、會員工具、預約系統、內容平台和 SaaS 原型很省時間。
從原型做到正式產品，不用急著換資料庫
PostgreSQL 是成熟的關聯式資料庫。產品剛開始可以只做三張表，之後再加交易、報表、權限或第三方整合，不必因為原型工具的資料格式太封閉，長大後整套重做。這點和我介紹過的 PocketBase 開源後端不太一樣：PocketBase 的單一執行檔很輕巧，Supabase 則更適合需要關聯資料、多人協作與雲端擴充的產品。
AI Agent 已經有官方 MCP 和 Skills
Supabase 官方提供 MCP Server，可以讓 AI 工具讀取資料表、查詢資料庫、處理 Migration、Edge Functions 與除錯資訊。現在也有 Supabase Plugin for AI Coding Agents，把 MCP 和 Supabase Skills 一起裝好。這不是噱頭，因為 AI 能直接取得專案真實狀態後，就不必一直靠你貼 Schema 猜答案。
Supabase 串接教學：先讓一個待辦清單跑起來
下面用 JavaScript／Next.js 的做法示範。React、Vue、Svelte 或一般前端專案的概念都差不多。
建立專案與資料表
登入 Supabase 後建立 Project，在 Table Editor 新增 todos，至少準備這幾個欄位：
id：主鍵user_id：使用者 UUIDtitle：待辦內容is_done：是否完成created_at：建立時間
AI 可以幫你產生建表 SQL，但我會要求它把 Schema 寫進 Migration，不要只在雲端後台點一點。這樣 Git 才能記住資料庫改了什麼。Vibe Coding 更需要版本管理，可以搭配我的 GitHub 管理 AI 程式碼教學一起看。
安裝 Supabase JavaScript SDK
npm install @supabase/supabase-js到 Project 的 Connect 畫面取得 Project URL 和 Publishable Key，放進環境變數：
NEXT_PUBLIC_SUPABASE_URL=https://YOUR_PROJECT.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=sb_publishable_xxx接著建立 Client：
import { createClient } from '@supabase/supabase-js'
export const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
)讀取待辦資料只需要這樣：
const { data, error } = await supabase
.from('todos')
.select('*')
.order('created_at', { ascending: false })
if (error) throw error這也是 Supabase 很討喜的地方。程式碼短，AI 也很熟悉這套語法。你可以直接請 Agent 幫忙補新增、修改、刪除與錯誤處理，但完成後還是要用測試驗證。介面測試可以參考 Playwright 與 AI Agent 自動化測試。
真正重要的是 RLS：不要讓方便變成資料外洩
Supabase 的 Publishable Key 本來就會出現在瀏覽器裡。它不是用來隱藏資料的密碼，真正限制使用者能看哪些資料的是 PostgreSQL Grants 和 Row Level Security（RLS）。官方也要求公開 Schema 的資料表要正確設定 RLS Policy。
例如待辦只能由擁有者讀寫，可以使用類似下面的規則：
alter table public.todos enable row level security;
grant select, insert, update, delete
on table public.todos
to authenticated;
create policy "Users manage their own todos"
on public.todos
for all
to authenticated
using ((select auth.uid()) = user_id)
with check ((select auth.uid()) = user_id);- 每張對外提供 API 的資料表都檢查 RLS。
- 依照
select、insert、update、delete測試允許與拒絕情境。 - 不要因為測試卡住，就寫一條
using (true)把所有資料開放。 - 正式站和開發站分開，不要讓 AI Agent 一開始就連正式資料。
2026 年金鑰名稱已經改了
很多舊教學還在叫你找 anon 和 service_role。Supabase 最新的 API Key 文件已改用 Publishable Key 和 Secret Key，並預計在 2026 年底前淘汰舊金鑰。
| 金鑰 | 放在哪裡 | 權限 |
|---|---|---|
| Publishable Key | 瀏覽器、App、公開 Client | 依照 anon／authenticated Role、Grants 與 RLS 存取 |
| Secret Key | Server、Edge Function、Cron 與受控後台 | 使用 service_role，會繞過 RLS |
Secret Key 絕對不要放進前端、Git Repository、聊天截圖或公開的 AI Prompt。它等於資料庫的管理鑰匙。需要付款、寄信、管理員操作或第三方私密金鑰時，放在 Server 或 Edge Function。
怎麼把 Codex、Claude Code、Cursor 接上 Supabase？
最方便的方法是從 Supabase 官方 MCP 頁面選擇專案與 Client，再依畫面產生設定。第一次連線我建議這樣做：
- 只綁定單一開發專案，不要一次開放整個 Organization。
- 先開 Read-only，確認 Agent 能看到正確的 Table 和 Migration。
- 只啟用目前需要的 Feature Groups。
- Migration 與程式碼都提交 Git，再進行寫入。
- 正式環境的 Schema 變更要有人審查。
想把 MCP 和官方 Supabase Skills 一起安裝，可以使用官方文件提供的 Plugin 指令：
npx plugins add supabase-community/supabase-pluginMCP 是給開發中的 AI Agent 管理與理解 Supabase；你的正式 App 還是透過 SDK、Data API 或 Server 連線。兩者不要混在一起。如果你對 MCP 的角色還有點模糊，可以接著看 WordPress MCP 與 REST API 差異，觀念其實很接近。
Supabase、PocketBase、Firebase 怎麼選？
| 工具 | 資料核心 | 適合情境 | 我會怎麼選 |
|---|---|---|---|
| Supabase | PostgreSQL | SaaS、會員網站、預約、內容平台、關聯資料與正式產品 | 想快速開發，又希望架構能繼續長大 |
| PocketBase | SQLite | 內部工具、小型 MVP、單機或自架專案 | 想要單一執行檔、低成本與完全自己控管 |
| Firebase | NoSQL／Google Cloud 服務 | 行動 App、即時應用與 Google 生態 | 團隊已熟 Firebase，資料模型也適合 NoSQL |
如果資料有清楚的關聯，例如會員、公司、訂單、方案、發票與權限，我通常偏向 Supabase。只做一個人使用的小工具，PocketBase 反而更輕。工具沒有絕對輸贏，重點是產品會不會長大，以及你願不願意處理 RLS 和資料庫 Migration。
Supabase 免費方案夠用嗎？
依照 Supabase 官方價格頁目前資料，Free 方案包含 2 個 Active Projects、每個專案 500MB Database、每月 50,000 MAU、1GB File Storage，以及 5GB Egress；閒置一週的免費專案會暫停。拿來學習、做 Demo 和小型 MVP 很夠。
正式服務我會評估 Pro，價格從每月 25 美元起，包含更大的 Database、Storage、流量、Log 與每日備份。費用會隨 Compute、流量和額外專案增加，正式上線前要設定預算通知與 Spend Cap，不要只看「API Request 無上限」就以為所有資源都免費。
我的建議：Supabase 很快，但資料設計不能交給 AI 猜
Supabase 把後端起手式縮得很短，這正是它適合 Vibe Coding 的原因。你可以在一天內做出登入、資料 CRUD、圖片上傳和 Realtime，AI Agent 還能透過 MCP 讀懂專案。
真正決定產品能不能上線的，還是 Schema、RLS、Migration、測試和備份。我的做法是讓 AI 負責加速，資料模型與權限一定人工確認。這樣 Supabase 才是省時間，不是把問題延後到正式上線才一次爆開。
常見問題 FAQ
Supabase 適合完全不會後端的人嗎？
適合拿來學習與做原型，Table Editor、SDK 和自動 API 都很好上手。但正式上線前仍要理解資料表關聯、RLS、環境變數與基本 SQL，不能只靠 AI 猜權限。
Supabase Publishable Key 放在前端安全嗎？
Publishable Key 本來就設計給公開 Client 使用，安全性依靠 Grants、使用者登入狀態與 RLS。Secret Key 會繞過 RLS，只能放在受控 Server、Edge Function 或 Cron，不能放進瀏覽器。
Supabase 免費方案可以正式上線嗎？
小型測試服務可以，但免費專案閒置一週會暫停，而且沒有自動備份。只要開始有真實客戶、重要資料或穩定性要求，就應評估 Pro、備份與用量成本。
Codex、Claude Code 和 Cursor 都能串 Supabase 嗎？
可以。Supabase 有官方 Remote MCP Server，也提供包含 MCP 與 Skills 的 Agent Plugin。建議先綁定單一開發專案、使用 Read-only，再依需要逐步開放寫入能力。
Supabase 和 PocketBase 哪個更適合 Vibe Coding？
要做關聯資料、多人服務、會員系統與正式 SaaS，我會優先看 Supabase。只想快速自架小型工具、偏好單一執行檔與 SQLite，PocketBase 會更輕巧。
