Supabase 完整教學：從建專案到用 MCP 讓 AI 代理直接管你的資料庫

一位在新竹做 side project 的工程師跟我說，他用 AI 生了一個訂閱制網站，三天就上線了，覺得自己是天才。第五天他發現有人把他的使用者資料表整個下載走了——不是被駭，是他忘了開 Row Level Security，而 anon key 就寫在前端的 JavaScript 裡，按 F12 就看得到。

這篇教學會從頭教 Supabase 怎麼用，但我想先把這件事放在最前面：Supabase 好上手，也好出事。

Supabase 是什麼

Supabase 是開源的後端服務平台，常被稱為「Firebase 的替代方案」。它把一套完整的後端打包給你：PostgreSQL 資料庫、身分驗證、檔案儲存、即時訂閱、Edge Functions、自動產生的 REST 與 GraphQL API。

它跟 Firebase 最關鍵的差別是：底層是真正的 PostgreSQL。你寫的是標準 SQL，有 foreign key、有 transaction、有 view 與 trigger。這代表兩件事——一是你既有的 SQL 知識完全能用，二是哪天想搬走，把資料庫 dump 出來丟到任何 Postgres 上就好，不會被鎖死。

2026 年 Supabase 最值得注意的變化是 AI 整合。官方推出的 MCP server 讓 Claude Code、Cursor、Codex、Gemini CLI 這些 coding agent 可以直接操作你的專案；另外也有 ChatGPT 整合，官方文件提到約 29 個工具，涵蓋執行 SQL、改 schema、開分支、部署 Edge Function、看即時日誌。

它能做什麼

一個典型的 Web 或行動 App 需要的後端，Supabase 幾乎都包了：

• Database：PostgreSQL，含自動生成的 REST API
• Auth：email、密碼、magic link、Google／GitHub／Apple 等 OAuth
• Storage：檔案上傳與 CDN 分發，權限跟資料庫政策整合
• Realtime：資料變動即時推送到前端
• Edge Functions：Deno 執行環境的無伺服器函式
• Vector：pgvector 擴充，可以直接拿來做 RAG 的向量檢索

最後這點對 AI 應用很實用——你不必為了 RAG 另外買一個向量資料庫，Postgres 加 pgvector 對中小規模的應用完全夠用。

怎麼用：從建專案到第一支查詢

第一步：建立專案

到 supabase.com 註冊，建立 organization 與 project。要選的東西有三個：

• Region：選離使用者最近的。台灣使用者建議選 Singapore 或 Tokyo，選 us-east 延遲會多出一兩百毫秒
• Database password：這是資料庫的超級使用者密碼，存到密碼管理器，這個不是 API key
• 方案：Free 可以先開始

建立需要一兩分鐘。完成後在 Project Settings > API 可以看到兩把鑰匙：

• anon key：設計成公開的，會放在前端程式碼裡
• service_role key：絕對不能放前端，它繞過所有權限檢查

這兩把鑰匙的差別是整篇教學最重要的觀念。

第二步：建立資料表

到 Table Editor 按 New table。以一個簡單的待辦事項為例：

• 表名 todos
• 欄位：id（int8，主鍵，自動遞增，預設已有）、user_id（uuid）、title（text）、done（bool，預設 false）、created_at（timestamptz，預設 now()）

user_id 這個欄位很關鍵——它會拿來跟登入者的 ID 比對，決定誰能看到哪幾筆。建表時記得勾選 Enable Row Level Security，Supabase 現在預設會提醒你。

也可以直接用 SQL Editor 建：

create table todos (
  id bigint primary key generated always as identity,
  user_id uuid references auth.users(id) not null,
  title text not null,
  done boolean default false,
  created_at timestamptz default now()
);
alter table todos enable row level security;

第三步：設定 RLS 政策（這一步不能跳）

開了 RLS 之後，預設是什麼都不准。你要明確寫出誰可以做什麼。

到 Authentication > Policies，或直接用 SQL：

-- 只能讀自己的待辦
create policy "read own todos" on todos
  for select using (auth.uid() = user_id);

-- 只能新增 user_id 是自己的資料
create policy "insert own todos" on todos
  for insert with check (auth.uid() = user_id);

-- 只能改自己的
create policy "update own todos" on todos
  for update using (auth.uid() = user_id);

-- 只能刪自己的
create policy "delete own todos" on todos
  for delete using (auth.uid() = user_id);

auth.uid() 是 Supabase 提供的函式，回傳當前登入者的 ID。這四條政策確保每個人只碰得到自己的資料。

寫完一定要測。用兩個不同帳號登入，確認 A 真的看不到 B 的資料。不要相信「我寫了政策應該就對了」。

第四步：從前端連上來

安裝 SDK：

npm install @supabase/supabase-js

建立 client 並查詢：

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
)

// 查詢（RLS 會自動只回傳這個人的資料）
const { data, error } = await supabase
  .from('todos')
  .select('*')
  .order('created_at', { ascending: false })

// 新增
await supabase.from('todos').insert({ title: '寫教學', user_id: user.id })

注意這裡用的是 anon key，權限完全由 RLS 決定。前端拿不到不該拿的資料，因為資料庫層就擋掉了。

第五步：加上登入

// Email + 密碼註冊
await supabase.auth.signUp({ email, password })

// 登入
await supabase.auth.signInWithPassword({ email, password })

// Google 登入
await supabase.auth.signInWithOAuth({ provider: 'google' })

OAuth 供應商要先到 Authentication > Providers 開啟並填入該平台的 client ID 與 secret。Google 的設定要到 Google Cloud Console 建立 OAuth 憑證，記得把 Supabase 給的 callback 網址填進去。

進階技巧

用 MCP 讓 AI 代理管資料庫

這是 2026 年最實用的新東西。安裝 Supabase MCP server 之後，Claude（搭配 Claude Code 教學）、Cursor 這些代理就能直接查你的資料庫、產生 migration、部署 Edge Function，而且官方把 agent skills 一起打包，代理會照著最佳實務做而不是亂改。

實際體感的差別是：以前你要跟 AI 描述「我的資料表長這樣，有這些欄位」，現在它自己去看。改 schema 的時候它會產生 migration 檔而不是直接下 ALTER TABLE。

但請務必只接到開發或預覽分支。讓 AI 代理直連正式資料庫，一個誤解的指令就可能刪掉東西。正確的流程是代理在分支上改，你 review 過的 migration 才合併到正式環境。

資料庫分支

Supabase 的 branching 讓你開一個獨立的資料庫分支測試 schema 變更，確認沒問題再合併回正式環境。計費上沒有固定月費，預覽分支跑在 Micro compute 上大約每小時 0.01344 美元——一天開八小時大概 0.11 美元，非常便宜。

搭配 MCP 使用是絕配：代理在分支上隨便改，反正壞了就砍掉重開。

Edge Functions

需要在後端跑的邏輯（呼叫第三方 API、處理 webhook、隱藏密鑰）放這裡：

supabase functions new send-notification
supabase functions deploy send-notification

執行環境是 Deno，寫 TypeScript。要用 service_role key 的操作（例如管理員功能）就放在這裡，絕對不要放前端。

pgvector 做 RAG

create extension if not exists vector;

create table documents (
  id bigserial primary key,
  content text,
  embedding vector(1536)
);

create index on documents using ivfflat (embedding vector_cosine_ops);

之後用 SQL 做相似度搜尋即可。中小規模的 RAG 應用這樣就夠，不用另外導 Pinecone 或 Qdrant。

注意事項

RLS 是你唯一的防線。再說一次：anon key 是公開的，前端原始碼裡看得到，這是設計如此。權限完全靠 RLS。上線前請逐一檢查每張表都開了 RLS 且政策正確。Supabase 後台會對沒開 RLS 的公開表格顯示警告，不要忽略它。

service_role key 絕不進前端。它繞過所有 RLS。只能放在 Edge Functions、後端伺服器或 CI 的環境變數裡。commit 進 git 之前檢查一次。

免費方案會暫停。專案閒置一段時間會被 pause，要手動喚醒。有真實使用者的產品請至少上 Pro（每月 25 美元）。

加購項目要留意。PITR 時間點還原每 7 天 100 美元、自訂網域 10 美元、進階 MFA 首個專案 75 美元。這些單價不低，開之前先確認真的需要。

資料落地。選 region 時要考慮的不只是延遲。如果你的服務涉及個資且有落地要求，要確認選定的區域符合規範。台灣目前沒有 Supabase 的區域，最近的是 Singapore 與 Tokyo。

TheAI學院評語

Supabase 這幾年最大的貢獻，是讓「一個人做完整個產品」變得真的可行。以前你要會後端、要架資料庫、要處理登入，現在這些都是設定。加上 2026 年的 MCP 整合，AI 代理直接管資料庫，開發速度又快了一個檔次。

但我必須誠實講另一面：它讓不懂資料庫的人也能把資料庫推上線，而這正是風險所在。那位新竹的工程師不是笨，他只是不知道前端的 key 是公開的。工具把門檻降低了，但資料外洩的後果沒有跟著降低。

我的建議很簡單：你可以用 AI 寫 90% 的程式碼，但 RLS 政策那一段請自己看懂、自己測過。這是那種「錯了就沒有第二次機會」的東西。

評語：Supabase 是目前個人開發者最強的後端選擇，但請把「檢查 RLS」當成上線檢查清單的第一項，不是最後一項。

給台灣讀者的具體建議：先用免費方案做一個有登入的小專案，刻意用兩個帳號測試資料隔離，親眼看到 RLS 生效再往下做。想接 AI 代理的話，先開一個分支練習，確認流程順了再考慮碰正式環境。相關的安全觀念可以搭配 LLM 應用安全清單 一起看。

資料來源

• Supabase 官方文件：MCP Server
• Supabase Changelog：Developer Update, June 2026

依公開資訊整理，功能與定價以官方文件為準。