Supabase 雲端 vs 自架與定價全解析 | Supabase 完整教學

決定用 Supabase 開發後，第一個要做的選擇是：把專案交給 雲端託管，還是自己用 Docker Compose 自架？這個決定牽動成本、維運負擔與可用功能。本篇帶你看懂雲端 vs 自架的取捨、拆解 Free / Pro / Team 定價方案，並手把手建立你的第一個雲端專案、走一遍 Dashboard。

前言

一句話定義本篇主題：這篇要幫你做兩個決定——「該用雲端還是自架」以及「該用哪個定價方案」——然後帶你實際建立第一個雲端專案並熟悉 Dashboard。

上一篇《架構與元件》我們把 Supabase 的內部拆開了：知道它是一群圍繞 Postgres 的開源微服務，也知道這些服務全都是可自架的 GitHub 專案。既然元件都開源、都能自架，一個很自然的問題就浮現了：那我到底該讓 Supabase 幫我託管，還是自己拉起這一整套？

如果用現實世界的類比，這個抉擇很像「租房」與「買地自建」。雲端託管就像租一間附管理服務的公寓——你付月租，水電網路、公共設施維護、保全都有人負責，拎包入住、幾分鐘就能開始生活；缺點是你得照房東的規矩來，長期租金累積也不便宜。自架則像自己買地蓋房——房子是你的、想怎麼改都行、資料完全掌握在自己手上；但地基、水電管線、防漏、保全樣樣得自己張羅，出問題半夜也是你自己爬起來修。兩者沒有絕對優劣，只有「適不適合你現在的處境」。

而定價方案就像「租房的坪數與服務等級」。Supabase 分成 Free（試住）、Pro（標準戶）、Team（含物業與合規服務的高階戶）、Enterprise（客製整棟）。搞懂各方案給你什麼、限制在哪，才不會選錯而卡在額度或功能上。

本篇你會學到：

• 雲端 vs 自架的取捨：兩種部署方式在成本、維運、功能、資料主權上的真實差異
• 定價方案怎麼看：Free / Pro / Team / Enterprise 的定位，以及 Free 方案的關鍵限制與「閒置暫停」機制
• 動手建立第一個雲端專案：從註冊、選 region、設密碼，到拿到 URL 與 anon key
• Dashboard 導覽：Table Editor、SQL Editor、Auth、Storage、Logs 各分頁分別在做什麼，並跑出你的第一個查詢

核心概念

雲端 vs 自架：一張表看懂取捨

先把兩種部署方式攤開對照。與其糾結細節，不如記住一個大原則：雲端用「錢與部分控制權」換「時間與省心」，自架用「時間與維運人力」換「完整控制權與潛在的成本優化」。

這張表最重要的一列是**「實際總成本」**。很多人一看到「自架軟體免費」就以為自架比較省，這是最常見的誤區。自架省下的是「軟體授權費」（本來就是 0），但你換來的是伺服器費、頻寬費，以及最貴的——維運人力。你得自己做備份、盯監控、打安全補丁、半夜處理當機。對一個沒有專職維運的個人或小團隊，雲端的 Free 或 Pro 幾乎一定更划算；只有當你已具備 DevOps 能力、或有明確的資料主權/合規需求、或規模大到雲端月費顯著高於自架時，自架才真正有意義。

自架在技術上是把上一篇提到的那一整套開源服務（官方 Docker Compose 約 13 個服務）用容器拼起來：

# 自架的大致流程（僅示意，細節依官方文件為準）
git clone --depth 1 https://github.com/supabase/supabase
cd supabase/docker

# 複製環境變數範本並填入 POSTGRES_PASSWORD、JWT_SECRET、ANON_KEY 等
cp .env.example .env

# 拉起整套服務
docker compose up -d

看起來只有幾行，但真正的工作在 docker compose up 之後才開始：憑證、備份策略、防火牆、監控、版本升級——這些才是自架的重頭戲。本系列後續會有專篇深入自架，這裡先讓你理解「自架不是零成本」這個核心觀念就好。

定價方案概觀：Free / Pro / Team / Enterprise

若你選擇雲端，接下來要決定用哪個方案。Supabase 以組織（Organization）為計費單位，採分層定價，每層包含一定額度，超出部分按量計費。下表是概觀（所有數字均以官方定價頁為準，本文僅供理解方案定位）：

幾個理解方案時的重點：

• Free 是「開發用」而非「營運用」。它足以讓你把整套功能玩過一輪、做出 side project 的雛形，但因為有閒置暫停與無自動備份等限制，不適合承載真實、不能中斷的流量。
• Pro（約 $25/月起）是大多數正式專案的起點。它解除了閒置暫停、提供每日備份與 Email 支援。要注意的是這個基礎月費通常只含一個很小的運算實例，實際生產環境常需要加購更大的 Compute，帳單會比 $25 高——這點在下一節「常見錯誤」會再提醒。
• Team 面向需要合規認證（如 SOC 2）、稽核日誌、更嚴謹存取控制的團隊。
• Enterprise 走客製路線，適合有 SLA、專屬支援、自帶雲端基礎設施（BYO Cloud）需求的大型組織。

再次強調：以上月費是「概略定位」，Supabase 的定價與額度會隨時間調整，請以 Supabase 官方定價頁 的即時數字為準，不要把本文的數字當成報價。

關鍵術語：Compute、MAU、Egress

看定價頁時會遇到幾個常被誤解的計費維度，先建立正確認知：

• Compute（運算資源）：你的 Postgres 實例規格（CPU / RAM）。這是最容易被低估的費用。基礎方案內含的運算實例通常很小，正式服務往往需要加購更大規格，這部分是獨立計價的。
• MAU（Monthly Active Users，每月活躍使用者）：每月至少呼叫一次 Auth API 的唯一使用者數，是 Auth 的計費依據。
• Egress（出站流量）：資料從 Supabase 傳出的流量（API 回應、檔案下載）。CDN 快取命中通常不計入。
• Storage（儲存空間）：物件儲存的容量，與資料庫容量分開計算。

理解這幾個維度，你就能看懂帳單為什麼長那樣，也能在估算成本時抓對變數。

實作範例

概念講完，動手建立你的第一個雲端專案，並走一遍 Dashboard。這一段做完，你就有一個可用的 Supabase 後端，並知道每個分頁的用途。

步驟一：註冊並建立專案

前往 https://supabase.com/dashboard 用 GitHub 或 Email 註冊登入。登入後你會看到「組織（Organization）」的概念——它是帳單與成員的頂層容器，一個組織下可以有多個專案。

接著點擊 New Project，會要求你填幾個關鍵欄位：

• Name（專案名稱）：辨識用，之後可改。
• Database Password（資料庫密碼）：這是 Postgres 超級使用者的密碼，請用密碼管理器產生強密碼並妥善保存。之後直連資料庫、做遷移都會用到，遺失需重設。
• Region（區域）：資料庫機房位置，直接影響延遲。選離主要使用者或後端最近的區域，服務台灣使用者常選 Tokyo 或 Singapore。特別注意：region 建立後通常無法更改，選錯只能建新專案遷移，務必想清楚。
• Pricing Plan：先用 Free 即可，之後隨時能升級。

按下建立後，Supabase 會替你佈建一個專屬的 Postgres 實例與周邊服務，大約 兩分鐘 完成。這兩分鐘背後，就是上一篇講的那整套微服務被自動拉起——只是你完全不用碰。

步驟二：拿到 URL 與 anon key

專案建好後，到左側選單的 Project Settings → API（或 Data API 相關頁面）取得兩樣連接應用程式必備的東西：

• Project URL：形如 https://<你的專案ref>.supabase.co，是所有 API 請求的基底網址。
• anon（匿名）public key：可安全放在前端的公開金鑰，實際資料存取由 RLS 把關。

# 你會在 Dashboard 的 API 設定頁看到類似這樣的值
Project URL:  https://abcdefghijklmnop.supabase.co
anon key:     eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVC...（很長的 JWT 字串）

同一頁通常還有一把 service_role key——這把金鑰完全繞過 RLS，等同資料庫管理員權限，只能放在後端（伺服器環境變數、Edge Functions），絕對不可出現在前端或提交進版本庫。這點在上一篇已強調，這裡再次提醒，因為它是最常見也最嚴重的資安事故來源。

拿到這兩個值，就能初始化客戶端：

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

// URL 與 anon key 都從 Dashboard 的 API 設定頁複製而來
const supabase = createClient(
  'https://<你的專案ref>.supabase.co',
  '<你的 anon key>'
)

步驟三：Dashboard 導覽

進到專案後，左側是主要的功能分頁。逐一認識它們，你就掌握了日常操作 Supabase 的地圖：

其中 Table Editor 與 SQL Editor 是兩種操作資料的方式：前者適合快速、視覺化的操作，後者適合精確、可重複、需要版本控制的操作。兩者背後都是同一個 Postgres，改哪邊都一樣生效。而 Logs 是初學者最容易忽略、卻在除錯時最救命的分頁——當 API 回傳意外結果、或 RLS 把資料擋掉時，Logs 往往能告訴你真正發生了什麼。

步驟四：跑出你的第一個查詢

打開 SQL Editor，貼上以下 SQL 建一張表並開啟 RLS。這一步同時驗證了你的專案真的能用：

-- 建立一張最簡單的 notes 資料表
CREATE TABLE notes (
  id bigserial PRIMARY KEY,
  content text NOT NULL,
  created_at timestamptz DEFAULT now()
);

-- 開啟 Row Level Security（正式資料表務必第一步就開）
ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

-- 塞一筆測試資料
INSERT INTO notes (content) VALUES ('我的第一筆 Supabase 筆記');

按下 Run 執行成功後，切到 Table Editor，你會在 notes 表裡看到剛插入的那一筆資料——這代表 SQL Editor 與 Table Editor 操作的是同一個資料庫。接著回到 SQL Editor 跑一個查詢：

-- 查詢剛剛建立的資料
SELECT id, content, created_at
FROM notes
ORDER BY created_at DESC;

你會拿到剛插入的那一列。到這裡，你已經完成了：建立雲端專案 → 取得 URL/anon key → 認識 Dashboard → 建表並查詢。一個能用的 Supabase 後端就位了。

常見錯誤與最佳實踐

初次部署與選方案時，最常踩的幾個坑：

坑一：Free 專案閒置被自動暫停，以為服務壞了。 Free 方案的專案在閒置一段時間（官方描述約一週無活動）後會自動 pause（暫停），這時 API 會連不上。很多人以為是 bug，其實是設計如此——這是免費方案節省資源的機制。正確認知：Free 適合開發與練習，被暫停可到 Dashboard 手動喚醒（restore）；只要是不能中斷的正式服務，就升級到 Pro（Pro 不會閒置暫停）。別把 Free 專案拿去接生產流量。

坑二：以為「自架 = 零成本」。 如前所述，Supabase 軟體開源免費，但伺服器、頻寬、以及最貴的維運人力都要你自己出。備份、監控、安全更新、故障處理都是持續的隱形成本。正確做法：先誠實評估自己有沒有 DevOps 能力與時間；個人與小團隊多數情況下，雲端 Free/Pro 的「省心」價值遠高於自架省下的那點軟體授權費（何況授權本來就免費）。

坑三：Region 選錯，延遲高又難改。 建立專案時隨手用預設 region，結果機房遠在他洲，每個請求都慢半拍；更麻煩的是 region 通常建立後無法更改，得重建專案遷移。正確做法：建立前先確認主要使用者/後端在哪，選最近的區域（台灣常用 Tokyo / Singapore），並把資料落地與合規需求一併考慮進去。

坑四：只看 Pro 的 $25 基礎費就估算成本。 Pro 的基礎月費通常只含一個很小的 Compute 實例，正式服務往往需要加購更大規格，加上 Egress、儲存等按量費用，實際帳單會高於 $25。正確做法：估算時把 Compute、MAU、Egress、Storage 都算進去，並善用 Spend Cap（消費上限）避免意外超支。所有數字以官方定價頁為準。

坑五：把 service_role key 當一般金鑰用。 它完全繞過 RLS、權限等同資料庫管理員，一旦放進前端或提交進 Git 就等於門戶大開。正確做法：前端只用 anon key，service_role 僅存在後端環境變數。

最佳實踐總結：

• 個人練習、side project 用 Free；正式、不能中斷的服務用 Pro（避開閒置暫停）
• 建立專案時慎選 region，記住它通常不可改
• 用強密碼設定資料庫密碼並妥善保存
• 估成本時把 Compute / MAU / Egress / Storage 都算進去，並以官方定價頁為準
• 除錯先看 Logs 分頁；service_role key 永遠只留在後端
• 「自架軟體免費」不等於「自架零成本」，先評估維運能力再決定

小結

這篇是 Supabase 系列教學的第 003 篇。承接上一篇《架構與元件》——我們知道 Supabase 是一群可自架的開源服務後，這篇就來回答「部署與上手」的兩個核心決定：

• 雲端 vs 自架：雲端用月費換省心、上手快、維運低；自架軟體免費但要自己扛伺服器與維運人力，適合有 DevOps 能力或資料主權需求的團隊。「自架免費」不等於「自架零成本」
• 定價方案：Free（開發用，會閒置暫停、無自動備份）→ Pro（約 $25 起，正式上線起點）→ Team（合規與進階管理）→ Enterprise（客製）。所有數字以官方定價頁為準
• 建立第一個雲端專案：註冊 → New Project → 慎選 region 與強密碼 → 兩分鐘佈建完成 → 取得 Project URL 與 anon key
• Dashboard 地圖：Table Editor（視覺化改資料）、SQL Editor（寫 SQL）、Auth（管使用者）、Storage（管檔案）、Logs（除錯救命）

至此，Supabase 的平台總覽告一段落：你已經知道它是什麼、內部怎麼組成、以及該怎麼部署與上手。從下一篇開始，我們要一頭鑽進這個平台的地基——Postgres 資料庫。

下一篇《Postgres 資料庫入門》，我們會從最基礎的建表、資料型別、主鍵與關聯講起，帶你打好整個 Supabase 賴以運作的資料庫底子。把後端建起來之後，是時候學會怎麼設計裡面的資料了。下一篇見。