Supabase 免費嗎？Cloud 限制與自架比較

Supabase 免費嗎？

Supabase 有兩種不同意義的免費方案，兩者並不是同一種優惠。託管式 Free 方案不收費。Supabase 的計費文件要求付費方案必須登錄信用卡，但未說明 Free 方案也需要信用卡。Supabase 採用開放原始碼授權，因此在自己的 VPS（virtual private server）上執行完整技術堆疊，不需支付授權費用。其中一種方案以資源限制計費。另一種方案則以維運工作計費。

截至 20 October 2026 查閱的 supabase.com/pricing 頁面，Free 方案包含 0.5 GB 資料庫容量、1 GB 檔案儲存空間、5 GB 輸出流量，以及每月 50,000 名活躍使用者，最多可使用兩個作用中的專案。同一頁面還列出一項會影響大多數使用情境的說明：「Free 專案在閒置 1 week 後會暫停」。規劃時請重新確認這些數值，因為定價頁面可能會變動。

免費方案實際提供的內容

[
  {
    "plan": "Free",
    "db_gb": 0.5,
    "file_storage_gb": 1,
    "egress_gb": 5
  },
  {
    "plan": "Pro",
    "db_gb": 8,
    "file_storage_gb": 100,
    "egress_gb": 250
  }
]

MAU（每月活躍使用者）會計算一個計費週期內產生任何 Auth 事件的不重複使用者。Supabase 列出的範例包括登入、權杖更新與登出，因此，已登入使用者即使當月沒有重新登入，只要工作階段在背景中靜默更新，也會被計入。每位使用者在每個週期只計算一次，因此 50,000 對仍在開發中的服務通常已相當充裕。最先用完的幾乎從來不是使用者數量，而是 0.5 GB 的 Postgres 儲存空間，或開始從 Storage 提供圖片與檔案後的 5 GB 輸出流量。

兩個啟用中的專案是較不明顯的限制。1 個 production 專案加上 1 個 staging 專案，就已經用滿 Free 方案，因此第三個構想不是得等待，就是得與不應共用資料庫的其他專案共用。

暫停機制比儲存空間上限更重要的原因

「閒置 1 週後，免費專案會暫停」這句話，是多數免費方案最終會遇到的限制。連續 7 天沒有人查詢的專案會停止提供請求服務。README 中的示範連結，或每月只使用 1 次的 staging API，可能會在你分享連結的對象點擊時無法使用。恢復方式是在 Supabase dashboard 中按下 Resume project 按鈕。專案暫停後 1 年內都能使用這項功能，因此修復很快，但前提是有人留意到問題。Supabase 會在暫停專案前約 1 週寄送警告電子郵件，但只有在有人閱讀該收件匣時才有幫助。

這就是託管免費方案的實際代價。你不必支付費用，但必須承擔可用性受限，以及無法提高的上限；若要解除這些限制，就必須升級方案。

Free 額度用完後 Pro 與 Team 的費用

[
  {
    "plan": "Free",
    "usd_per_month": 0
  },
  {
    "plan": "Pro",
    "usd_per_month": 25
  },
  {
    "plan": "Team",
    "usd_per_month": 599
  }
]

Pro 每月起價為 $25，每個專案包含 8 GB 磁碟空間、100 GB 檔案儲存空間，以及 250 GB 對外傳輸流量。超過這些額度後，磁碟空間每 GB 收費 $0.125，檔案儲存空間每 GB 收費 $0.0213，未快取的對外傳輸流量每 GB 收費 $0.09。快取的對外傳輸流量另有 250 GB 額度，超過後每 GB 收費 $0.03。以上價格截至 20 October 2026。Pro 也會停用因閒置而暫停服務的機制。Team 每月起價為 $599，適用於需要合規與存取控制功能的組織，不是為只有一名開發者的個人 side project 設計。

Pro 方案預設會啟用支出上限。這項預設設定很重要：超過包含的額度時，服務會受到限制，而不是在你未察覺時持續增加帳單。關閉上限代表你是有意選擇另一種故障模式。這與比較 代管 Postgres 的帳單與自行管理的 VPS 時所做的計算相同，因為代管費用主要是在支付他人的 on-call 輪值。

改為自行代管的成本

授權條款不會產生費用。Supabase 文件指出，Docker 是「最快且建議的自行代管方式」，而這套服務堆疊可在一般 VPS 上執行。費用會轉化為維運工作，而文件也明確列出這些工作將由你負責：

• 伺服器佈建與維護
• 安全強化，以及持續更新 OS 與服務
• 服務設定與管理
• Postgres 資料庫維護
• 高可用性與擴充性
• 備份與災難復原
• 監控與正常運作時間

請將這些視為每週成本，而不是一次性的設定成本。佈建只需執行一次。更新與備份檢查則會永久持續。如果誠實來說，沒有人會測試還原，代管方案其實比表面上更便宜，因為從未執行過的還原作業，不能算是備份。

自架 Supabase 不包含的功能

自架堆疊不是代管平台的複製版本。文件列出無法使用的功能：「branching、超出日誌範圍的進階 metrics、managed backups 與 PITR、analytics 與 vector buckets、ETL，以及 Management API」。PITR（point in time recovery）是許多人遷移後才發現缺少的功能。在代管方案中，這只需開啟一項設定。在自己的伺服器上，則需要 base backup、WAL（write ahead log）封存機制，以及伺服器外部用來保存這兩者的位置，還需要進行演練，確認整套流程能正確運作。pgBackRest 等工具就是為此用途而設計，相關設定則由你自行負責。

Studio 這個網頁儀表板在自架環境中「不支援多個 organizations 或 projects」。一個堆疊就是一個 project。因此，如果你自架的原因是要避開兩個 project 的限制，應規劃在不同的連接埠或不同的伺服器上部署第二個堆疊，而不是在同一個儀表板中建立第二個 project。

您會獲得什麼

根據文件說明，自行託管的 Supabase「不會向外回報或收集任何遙測資料」。您的資料列與使用者資料表都位於您直接租用的硬體上。當客戶合約或監管機關要求資料必須留在特定國家時，這正是自行託管的主要理由。

您也會取得 Postgres 本身。代管平台會替您調校並管理伺服器。在自己的主機上，shared_buffers、max_connections、擴充功能清單，以及前端的連線池器都由您自行設定。最後這一項很快就會成為問題，因為無伺服器函式或繁忙的應用程式可能建立超過 Postgres 可承受數量的連線。到了這個階段，在自己的 VPS 上執行 PgBouncer 或 Supavisor 就不再是選擇性項目。

自行託管最明顯能消除的限制是對外傳輸流量上限。當 Storage 開始向實際訪客提供圖片或音訊時，5 GB 很快就會用完。多數 VPS 方案包含以 TB 計算的傳輸量，因此檔案量大的應用程式往往早在伺服器負載達到瓶頸前，就先碰到代管平台的上限。如果您是因為 Storage 才閱讀本文，請先估算磁碟成本，再估算運算資源：block storage 或 object storage 上 1 TB 的實際成本對總成本的影響高於 CPU。

啟動自架服務堆疊

文件建議的做法是對儲存庫中的 docker 目錄執行淺層複製，並固定使用自架版本標籤。截至 20 October 2026，該標籤為 self-hosted/v0.8.3。此標籤於 16 October 2026 建立，包含 Storage 與 Realtime 的安全性修正，因此仍使用較舊標籤的安裝值得更新。Debian、Ubuntu、RHEL、CentOS 與 Fedora 均可使用 supabase.link/setup.sh 的官方設定腳本；如果希望將檔案樹保留在自己的 git 儲存庫中，則下方的手動複製方式較適合。

git clone --depth 1 --branch self-hosted/v0.8.3 https://github.com/supabase/supabase
mkdir supabase-project
cp -rf supabase/docker/. supabase-project
cd supabase-project && cp .env.example .env
printf 'ref=self-hosted/v0.8.3\n' > .supabase-version
docker compose pull
sh utils/generate-keys.sh
sh utils/add-new-auth-keys.sh
sh run.sh start

sh utils/generate-keys.sh 是不可略過的步驟。.env.example 預設包含任何人都能在公開儲存庫中讀取的佔位密鑰，因此使用這些值啟動的堆疊，任何找到該連接埠的人都能存取。文件會緊接著執行 sh utils/add-new-auth-keys.sh，以加入新的 API 金鑰與非對稱金鑰組。啟動堆疊前，請檢視這兩個腳本的輸出，並確認 .env。.supabase-version 檔案會記錄啟動時使用的標籤，讓內建的 update.sh 日後可以升級安裝。也請在 .env 中設定 DASHBOARD_PASSWORD，因為 Studio 受到 HTTP basic authentication 保護，且文件要求該密碼至少包含一個字母。

使用 docker compose ps 檢查結果。輸出應列出每項服務均處於 running 或 healthy 狀態。接著在 port 8000 開啟 Studio，並使用 dashboard 憑證登入。需要再次取得產生的金鑰時，請執行 sh run.sh secrets；sh run.sh stop 則會停止整個堆疊。不要直接將 port 8000 發布到網際網路：請在前方設定支援 TLS（transport layer security）的反向代理，或將其保留在私有網路中。完整操作流程，包括該代理與建議優先修改的 .env 值，請參閱使用 Docker Compose 自架 Supabase 的逐步指南。

哪一種 Free 方案適合你

在專案仍處於建置階段、尚未正式使用，且暫停服務不會造成損失時，選擇代管的 Free 方案。這是真正可用的方案，且提供寬裕的使用者數量上限。不過，這個方案的設計前提是你日後會升級離開它。

當專案已有使用者會注意服務中斷時，選擇每月 $25 的 Pro 方案。這筆費用低於你單一月份花在備份檢查上的工時成本，因此付費是排程上的決策，不代表失敗。

當你已經執行 VPS，且也為其他用途在該 VPS 上處理維運工作；資料不得離開你的管轄區；或儲存空間與輸出流量的需求增長速度已超過伺服器價格時，選擇自行託管。這項取捨也適用於所有開放核心產品。n8n 免費社群版與付費方案的區分 和 免費 Nextcloud Hub 與企業訂閱的區分 都在相同位置劃出同一條界線。免費軟體已完整到足以承載實際工作負載。付費產品販售的是沒有人喜歡自行負責的部分。

FAQ

Supabase 免費方案是否永久免費？

截至 20 October 2026，定價頁面未為 Free 方案設定期限或試用期，計費文件則要求付費方案留存信用卡資料，未要求 Free 方案提供信用卡。Free 方案改以配額限制為主：資料庫 0.5 GB、檔案儲存空間 1 GB、輸出流量 5 GB、每月活躍使用者 50,000 人，以及 2 個啟用中的專案。對多數使用者而言，導致免費使用結束的不是配額，而是「Free projects are paused after 1 week of inactivity」這項規則。

免費 Supabase 專案暫停後會發生什麼事？

專案會停止處理請求。API 呼叫會失敗，控制面板也會將專案標示為暫停，直到有人按下 Resume project 按鈕將其恢復；文件指出，暫停後 1 年內仍可使用此按鈕。Supabase 會在暫停前約 1 週寄出警告，但應用程式本身不會收到警告。因此，若你在 1 個月前分享過示範專案，通常在有人通知你之前，專案早已停止運作。若專案必須在每天的任何時段都能處理請求，請升級至 Pro，或改為自行代管。

自行代管的 Supabase 與代管版本相同嗎？

不相同。文件列出自行代管不包含的功能：「branching、超出日誌範圍的進階指標、代管備份與 PITR、analytics 與 vector buckets、ETL，以及 Management API」。Studio 也「不支援多個組織或專案」，因此一個自行代管的 stack 只能對應 1 個專案。資料庫、驗證、儲存空間、realtime 與 edge function 元件，則與代管平台執行的軟體相同。

自行代管的 Supabase 會將任何資料傳回 Supabase 嗎？

不會。自行代管文件表示，自行代管的部署「不會回傳資料或收集任何遙測資料」。執行 docker compose pull 時，容器會從公開 registry 擷取映像檔；這只是一般的映像檔下載，不是回報你的資料。此後所有資料都留在你的伺服器上，也表示每次備份與每項安全性更新都由你負責。