Supabase 是什麼？開源 BaaS 平台總覽 | Supabase 完整教學

2026/09/20
supabase baas 總覽
Supabase 是什麼？開源 BaaS 平台總覽 | Supabase 完整教學

Supabase 是一個開源的後端即服務（BaaS）平台，以 PostgreSQL 為單一真相來源，把資料庫、身份驗證、儲存、即時訂閱、Edge Functions 與向量搜尋整合成一致的開發體驗，讓你能以 Firebase 的速度構建，同時保有對資料的完全控制權。這篇是 Supabase 系列教學的第一篇，帶你建立全局的心智模型。

前言

一句話定義：Supabase 是「開源的 Firebase 替代方案」，一個以 Postgres 為核心的後端即服務（Backend as a Service，簡稱 BaaS）平台。

如果要用現實世界的類比，你可以把 Supabase 想成一間「以中央廚房為核心的餐廳」。傳統上你要自己蓋廚房、請廚師、裝水電、找外送——也就是自己架資料庫、寫 API、做登入、設定檔案儲存。Supabase 則是把一座設備齊全的中央廚房（Postgres 資料庫）直接交給你，並在廚房周圍配好了現成的出餐窗口：點餐系統（自動 API）、門口的驗票員（Auth）、倉儲（Storage）、即時廣播（Realtime）、臨時加工站（Edge Functions）。所有服務都圍著同一座廚房運作，食材（資料）只有一份，不會東一份西一份對不起來。

這正是 Supabase 最重要的設計哲學：所有東西都讀寫同一個 Postgres。認證資料、儲存的檔案中繼資料、即時事件，全都在同一個資料庫裡，套用同一套資安政策。

為什麼這件事這麼重要？因為在傳統的後端架構裡，登入系統、檔案儲存、業務資料庫往往是三套獨立的服務，彼此之間要靠一堆「膠水程式碼」串接，資料同步、權限一致性都是麻煩來源。而 Supabase 把這些全部收斂到一個 Postgres，於是「使用者」這個概念不再散落在各處——你的訂單表可以直接用外鍵指向認證系統的使用者、你上傳的檔案權限可以跟業務資料共用同一套 RLS 政策。少了膠水，錯誤就少，開發速度自然快。

Supabase 誕生於 2020 年，官方的使命是「給所有開發者 Postgres，讓他們能以 Firebase 的速度構建」。它的精神不是「重新發明一個更好的資料庫」，而是站在 PostgreSQL 這個久經考驗、超過 30 年歷史的開源巨人肩膀上，把周邊該有的後端能力補齊。對前端與全端開發者來說，這代表你毋須自行建置與維運伺服器基礎設施，就能在幾分鐘內啟動一個功能完整、可上線的後端。

本篇你會學到：

  • Supabase 到底是什麼：開源 BaaS 的定位，以及「Postgres 是單一真相來源」代表什麼
  • 六大服務如何圍繞資料庫：Database、Auth、Storage、Realtime、Edge Functions、Vector 的分工
  • 開源可自架的差異化：為什麼可攜性（Portability）與 RLS 是關鍵優勢
  • 一句話看懂 Supabase vs Firebase：什麼情境該選哪一個
  • 50 篇系列導讀：接下來要學什麼、路線圖長什麼樣

核心概念

Postgres 是中心，六大服務環繞

理解 Supabase 的最快方式，是先看清楚它的架構長相。與其把它想成「一堆功能」，不如記住一張圖：一個 Postgres 在正中央，六大服務像衛星一樣環繞它。

                    ┌─────────────────┐
                    │   你的應用程式   │
                    │ Web/Mobile/Edge │
                    └────────┬────────┘
                             │ HTTPS / WSS
                    ┌────────▼────────┐
                    │   API Gateway   │  ← API Key 驗證、路由、CORS
                    └────────┬────────┘
        ┌──────────┬─────────┼─────────┬──────────┐
        ▼          ▼         ▼         ▼          ▼
   ┌─────────┐┌────────┐┌─────────┐┌────────┐┌──────────┐
   │  Auth   ││Storage ││Realtime ││Edge Fn ││ REST API │
   │(GoTrue) ││物件儲存││即時訂閱 ││ (Deno) ││(PostgREST)│
   └────┬────┘└───┬────┘└────┬────┘└───┬────┘└─────┬────┘
        └─────────┴──────────┴─────────┴───────────┘
                             │
                    ┌────────▼────────┐
                    │   PostgreSQL    │  ← 唯一真相來源
                    │  含 RLS、pgvector│    (Database + Vector)
                    └─────────────────┘

圖中每個「衛星」都是一個獨立的開源專案，但它們都指向同一個核心。這就是 Supabase 與傳統 BaaS 最大的不同：它不重新發明輪子，而是把圍繞 Postgres 的最佳開源工具，整合成一致的開發體驗。

再看一次資料的流向，會更清楚整體運作：你的應用程式（不論是網頁、手機 App、還是伺服器）透過 HTTPS 或 WebSocket 發出請求，請求先抵達 API Gateway（早期用 Kong，較新版本改用 Envoy）。這道閘門負責驗證 API 金鑰、路由到正確的服務、處理 CORS 與速率限制。通過閘門後，請求會被分派到對應的衛星服務，而幾乎所有服務最終都會回到中央的 Postgres 讀寫資料、套用 RLS 政策，再把結果沿原路送回。換句話說，資料庫是「終點」也是「圓心」，其他一切都是它的延伸。

六大服務各司其職

服務底層技術一句話職責
DatabasePostgreSQL資料庫核心，唯一真相來源
AuthGoTrue（Go）JWT 身份驗證、OAuth、MFA
StorageStorage APIS3 相容物件儲存，與 RLS 整合
RealtimeElixir/PhoenixWebSocket 即時訂閱與廣播
Edge FunctionsDeno全球邊緣執行的 TypeScript 函式
Vectorpgvector 擴充向量嵌入儲存與相似度搜尋

值得注意的是，REST API 是「自動生成」的。你不需要寫任何一行後端程式碼，Supabase 內的 PostgREST 會讀取你的資料庫 schema（資料表、視圖、函式），自動反射成一組 RESTful API 端點。你建一張 todos 資料表，馬上就有 GET /rest/v1/todos 可以用了。

讓我們用一段話快速認識每個衛星在做什麼：

  • Database（資料庫）：完整、無閹割的 PostgreSQL。支援 ACID 事務、JSON/JSONB、陣列、全文搜尋、視窗函式、觸發器、預存程序，以及超過 50 個擴充套件。每個 Supabase 專案都有一個專屬的 Postgres 實例，而非共享資料庫，確保資料隔離與效能可預測。
  • Auth（身份驗證）：底層是以 Go 撰寫的 GoTrue，負責發行與更新 JWT。支援 Email/密碼、Magic Link 無密碼登入、OTP、近 20 種 OAuth 社交登入（Google、GitHub、Apple 等）、SAML 企業 SSO 與多重因素驗證（MFA）。使用者資料存在 Postgres 的 auth schema，可與業務資料聯合查詢。
  • Storage（物件儲存）：S3 相容的物件儲存，用來放圖片、影片、文件。它與眾不同之處在於存取控制同樣走 Postgres 的 RLS，而檔案中繼資料也存在資料庫的 storage schema，讓你能用 SQL 查詢檔案資訊。
  • Realtime（即時訂閱）：以 Elixir/Phoenix 打造的 WebSocket 伺服器，提供三種機制——監聽資料表變更的 Postgres Changes、低延遲 pub/sub 的 Broadcast、追蹤在線狀態的 Presence，非常適合聊天室、協作、多人遊戲。
  • Edge Functions（邊緣函式）：在全球邊緣節點執行的 TypeScript/JavaScript 函式，執行環境是 Deno。用來處理自動 API 表達不了的自訂業務邏輯，例如串接第三方金流、寄送 Email、Webhook 處理。
  • Vector（向量搜尋）：透過 pgvector 擴充套件，讓 Postgres 直接成為向量資料庫。你可以把 AI 嵌入（Embeddings）和業務資料存在同一張表、同一個資料庫，是 RAG 與語意搜尋的絕佳基礎。

開源可自架：Supabase 的核心差異化

Supabase 的多數核心元件採用 Apache 2.0 授權，這帶來幾個實際好處，是它和多數閉源 BaaS 拉開差距的關鍵：

  • 完全透明：程式碼公開在 GitHub，你可以審閱、修改，甚至替換任何一個元件。
  • 可自架（Self-hosting）：官方提供 Docker Compose 方案，一鍵拉起完整的服務棧。對有資料主權需求（如 GDPR、台灣個資法）或想長期控制成本的團隊來說，這是無可取代的選項。
  • 高可攜性（Portability）：因為底層是標準 Postgres，一行 pg_dump 就能備份整個資料庫，不被任何專有格式綁死。哪天你想搬家，資料帶著走即可，沒有廠商鎖定（Vendor Lock-in）的焦慮。

換句話說，用 Supabase 雲端服務享受託管的方便，同時保留「隨時可以自架、隨時可以帶走資料」的退路。這種「開源做地基、雲端做加值」的模式，正是它獲得開發者信任的原因。

一句話看懂 Supabase vs Firebase

Supabase 常被稱為「開源的 Firebase 替代方案」，但兩者的根本差異值得先釐清：

維度SupabaseFirebase
資料庫類型PostgreSQL（關聯式）Firestore（NoSQL 文件）
完整 SQL / JOIN支援受限查詢 API
開源可自架是（Apache 2.0）否（Google 私有）
授權層RLS 在資料庫層，所有路徑皆受保護Security Rules 只作用於 SDK
離線優先實驗性成熟

一句話總結：需要關聯式資料、完整 SQL 與資料主權，選 Supabase；需要離線優先的行動應用、Google 生態深度整合，選 Firebase。 一個很實際的差異是資安：Supabase 的 RLS 政策寫在資料庫層，無論請求走哪條路都受同一套規則保護；Firebase 的 Security Rules 只管到 SDK，Admin SDK 可以直接繞過，授權邏輯容易散落在多處。另外在定價上，Firestore 按「讀取次數」收費，一次頁面載入可能觸發上百次讀取，高流量時成本難以預測；Supabase 採固定月費，對已知規模的應用更好估算。

關鍵術語

在後續文章你會反覆遇到這幾個名詞，先在這裡建立印象：

  • RLS（Row Level Security，資料列層級安全）：直接在資料庫層強制執行的存取控制政策。這是 Supabase 資安的基石——無論請求來自前端 SDK、REST API、直連還是排程腳本，都套用同一套規則。
  • anon key（匿名金鑰）：可以安全嵌入前端的公開金鑰，因為它受 RLS 保護。
  • service_role key（服務角色金鑰）：完全繞過 RLS 的超級金鑰，只能用在後端，絕不可暴露給前端。
  • 單一真相來源（Single Source of Truth）：所有服務的資料最終都落在同一個 Postgres，不會出現多個資料庫各說各話的問題。

實作範例

概念講完，我們用最小的可執行範例感受一下「圍繞資料庫」的實際樣貌。假設你已經在 Supabase Dashboard 建好一個專案（點「New Project」，2 分鐘完成），接下來只要兩步。

步驟一：在資料庫建一張表並開啟 RLS

在 Supabase Studio 的 SQL 編輯器貼上以下 SQL。這段同時展示了 Supabase 的兩個精神：完整 SQL 與 資安在資料庫層。

-- 建立一張 todos 資料表，關聯到內建的 auth.users
CREATE TABLE todos (
  id bigserial PRIMARY KEY,
  user_id uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  title text NOT NULL,
  is_complete boolean DEFAULT false,
  created_at timestamptz DEFAULT now()
);

-- 開啟 Row Level Security（資安基石，務必開啟）
ALTER TABLE todos ENABLE ROW LEVEL SECURITY;

-- 政策：使用者只能讀取自己的 Todo
CREATE POLICY "Users can view own todos."
  ON todos FOR SELECT
  USING ( user_id = auth.uid() );

-- 政策：使用者只能新增自己的 Todo
CREATE POLICY "Users can insert own todos."
  ON todos FOR INSERT
  WITH CHECK ( user_id = auth.uid() );

注意 user_id uuid REFERENCES auth.users(id) 這一行：你的業務資料表可以直接用外鍵（Foreign Key）關聯到 Auth 服務管理的使用者表——因為它們就在同一個資料庫裡。這在 Firestore 那種 NoSQL 世界是做不到的。

步驟二：用 supabase-js 連線並查詢

建完表之後，PostgREST 已經自動幫這張表生成 API 了。你不用寫後端，直接在前端用官方 SDK 存取。先安裝套件：

npm install @supabase/supabase-js

接著初始化客戶端並做一個簡單的查詢：

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

// 用 anon key 建立客戶端（可安全放在前端，受 RLS 保護）
const supabaseUrl = 'https://<你的專案ref>.supabase.co'
const supabaseAnonKey = '<你的 anon key>'
const supabase = createClient(supabaseUrl, supabaseAnonKey)

// 查詢 todos（RLS 會自動只回傳當前登入使用者的資料）
async function getTodos() {
  const { data, error } = await supabase
    .from('todos')                          // 對應 public.todos 資料表
    .select('id, title, is_complete')        // 選取欄位
    .order('created_at', { ascending: false })

  if (error) {
    console.error('查詢失敗：', error.message)
    return
  }
  console.log('我的待辦事項：', data)         // 輸出：只有自己的 todos
}

getTodos()

這段程式碼的關鍵在於：你從沒寫過任何後端 API，卻已經能安全地查詢資料庫。createClient 建立連線、.from('todos').select(...) 對應到 PostgREST 自動生成的端點，而 RLS 在背後確保你只拿得到自己的資料。這就是「圍繞資料庫」的威力——資料庫變了，API 自動跟著變，資安也一併鎖好。

常見錯誤與最佳實踐

初學者第一次接觸 Supabase，最常見的幾個誤解與正確心智模型：

誤解一：「Supabase 只是一個雲端資料庫」。 不對。Postgres 確實是核心，但 Supabase 是一整套 BaaS 平台。如果你只把它當資料庫用，就浪費了 Auth、Storage、Realtime、Edge Functions 這些圍繞它的服務。正確心智模型：Postgres 是地基，六大服務是蓋在地基上、共用同一份資料的樓層。

誤解二：「anon key 可以公開，那是不是不安全？」 anon 金鑰設計上就是要放在前端的，它本身不危險——真正保護你資料的是 RLS。如果你建了表卻忘記 ENABLE ROW LEVEL SECURITY，那才是災難：任何人拿到你的 anon key 就能讀寫整張表。所以最佳實踐是：建表就開 RLS，把資安當成第一步而不是最後一步。

誤解三：「把 service_role key 放進前端比較方便」。 千萬不要。service_role 金鑰完全繞過 RLS，等於資料庫的超級管理員鑰匙。它只能存在於後端環境變數（如 Edge Functions、你自己的伺服器），一旦洩漏到前端，整個資料庫門戶大開。

最佳實踐總結：

  • 每建一張表，第一件事就是開啟 RLS 並寫好政策
  • 前端只用 anon key，後端敏感操作才用 service_role key
  • 把 Postgres 當唯一真相來源，讓 Auth、Storage 的資料透過外鍵與業務資料關聯
  • 善用「自動 API」——多數 CRUD 不需要自己寫後端

小結

這篇作為 Supabase 系列教學的第 001 篇，我們建立了最重要的全局心智模型：

  • Supabase 是開源的 BaaS 平台，定位為「Firebase 替代方案」
  • Postgres 是單一真相來源，六大服務（Database、Auth、Storage、Realtime、Edge Functions、Vector）全都圍繞它運作
  • RLS 是資安基石，anon key 靠它保護，service_role key 則須嚴格保密
  • 開源可自架帶來可攜性與資料主權，這是與 Firebase 最大的差異之一
  • 一句話對比：需要關聯式資料與完整 SQL 選 Supabase，需要離線優先行動應用選 Firebase

下一篇《架構與元件》，我們會拆開這張架構圖，深入看 API Gateway、PostgREST、GoTrue、Supavisor 連線池等每個元件實際如何協作、請求是怎麼一路流到資料庫再流回來的。

這個 50 篇系列的五大主題路線如下，供你先建立整體地圖：

  • SB-1 平台與資料庫：平台總覽、架構、Postgres 基礎、SQL、擴充套件
  • SB-2 API 與客戶端：自動 REST API（PostgREST）、GraphQL、supabase-js 客戶端 SDK
  • SB-3 Auth 與資安：身份驗證、OAuth、RLS 政策設計、多租戶隔離
  • SB-4 儲存與即時：Storage 物件儲存、Realtime 三種機制、Edge Functions
  • SB-5 AI 與進階維運：pgvector 向量搜尋、RAG、自架、效能與部署

希望這篇能幫你建立對 Supabase 的第一印象。接下來我們會一路從基礎打到能上線的完整應用，跟著系列走就對了。

BenZ Software Developer

熱愛技術的軟體開發者，在這裡分享程式開發經驗與學習筆記。

本週主打

AI 自動化入門包

你每天手動在做的那些煩事,其實 AI 可以自己跑。這份給你 10 個照著做就會的自動化工作流 + 50 個複製即用的提示詞,不用會寫程式。

看看這個產品 →