Supabase vs Firebase：開源 PostgreSQL 基礎設施 vs Google 全家桶評測
&& request.auth.uid == resource.data.userId;
allow write: if request.auth != null
&& request.auth.uid == request.resource.data.userId;
這種計費模型的風險在於：即時監聽會計費。每個訂閱的文件變更都會算一次讀取。如果你的 App 有一千個使用者同時開著一個看板，每秒有十筆更新，那數字會非常可觀。另外 Cloud Functions 的呼叫次數、運算時間、網路出口也各別計費。
5.2 Supabase 的計費邏輯：按資源與月費
Supabase 免費方案提供 500 MB 資料庫、1 GB 檔案儲存、5 GB 頻寬、五萬月活躍使用者（MAU），以及有限的邊緣函數呼叫。Pro 方案每月 25 美元，包含 8 GB 資料庫、100 GB 檔案儲存、250 GB 頻寬、十萬 MAU，超過的部分按資源加購。它的計費相對可預測：你付的是資料庫容量與流量，不是查詢次數。對查詢密集但資料量小的應用（例如大量即時讀取），Supabase 通常便宜很多。
5.3 三種情境的成本試算
情境
Firebase 估算
Supabase 估算
小型 Side Project（100 使用者，每日數千次讀寫）
免費方案可涵蓋
免費方案可涵蓋
中型 SaaS（5,000 使用者，日讀取 200 萬次）
約 40～80 美元／月，含即時監聽成本可能更高
Pro 方案 25 美元／月起，視資料量加購
即時協作應用（1,000 並發在線，持續訂閱）
即時監聽計費容易失控，需仔細設計查詢範圍
Realtime 連線數與訊息量計費，相對線性
要注意的是，Firebase 有「讀取放大」的特性：一個包含 20 份文件的查詢，就算你只需要 1 份，只要客戶端接收了 20 份，就計 20 次讀取。Supabase 則是按查詢與回傳資料量算，不會因為「監聽」而反覆計費。這是很多團隊從 Firebase 搬到 Supabase 的直接原因。
六、效能、擴展性與可靠性
6.1 延遲與冷啟動
Firestore 的讀寫延遲通常在全球多區域複寫下維持在數十毫秒級，Google 的骨幹網路是它的護城河。Cloud Functions 的冷啟動在 Node.js 上大約 1～3 秒，可以靠最小實例數改善，但要多付費。Supabase 的資料庫延遲取決於你選的區域，選對區域（例如新加坡、東京）台灣使用者大約 20～50 毫秒；邊緣函數冷啟動極快，但資料庫查詢仍要回到主要區域，這是它的架構限制。
6.2 水平擴展與熱點
Firestore 天生就是分散式系統，擴展性極強，但代價是「熱點」問題——同一個文件或同一個索引前綴的高頻寫入會受限。業界常用「分片計數器」等技巧繞過。PostgreSQL 的擴展性比較傳統：垂直擴展（更大的機器）很簡單，水平擴展（讀寫分離、分片）需要更多架構設計。Supabase 在 Pro 以上方案提供讀取副本（Read Replica）與連線池（PgBouncer），對多數中小型應用已足夠。
6.3 資料落地與法規
Firebase 提供多區域與區域性部署選項，資料存放位置在建立專案時決定，之後難以更改。Supabase 讓你在建立專案時選區域，Pro 方案可以加購多個專案做地理分散。對有 GDPR、個資法合規需求的團隊，兩邊都能滿足，但 Supabase 的自託管選項讓你能把資料完全放在自己的機房，這是金融與醫療產業的關鍵。
七、開發者體驗與生態系
7.1 本地開發與 CLI
Firebase 的模擬器套件（Emulator Suite）非常成熟，可以本地跑 Firestore、Auth、Functions、Storage、Hosting，並與正式環境隔離。Supabase 的 CLI 可以本地啟動整套服務（需要 Docker），也能用遷移檔（migration）管理資料庫結構，這對團隊協作是巨大優勢——資料庫變更可以進 Git，走 CI/CD。
如果你重視「資料庫結構即程式碼」，Supabase 的體驗明顯更好；如果你重視「模擬器一鍵啟動、規則可單元測試」，Firebase 略勝一籌。
7.2 SDK 與框架整合
Firebase 的 SDK 覆蓋面極廣，從 Swift、Kotlin、Unity 到 Flutter、React Native，幾乎所有行動框架都有官方支援。Supabase 的 JavaScript/TypeScript 生態最強，Flutter、Swift、Kotlin、Python、Dart 也都有官方或社群維護的套件，但成熟度與文件完整度仍有落差。若你的團隊以 Web 與 TypeScript 為主，這個差距幾乎不存在。
7.3 學習曲線與社群
Firebase 的學習資源量體龐大，官方文件、YouTube 教學、Stack Overflow 答案都很齊全。Supabase 的社群相對年輕但非常活躍，官方 Discord 回應速度快，GitHub issue 也常見到核心團隊直接回覆。文件品質方面，Supabase 的官方文件簡潔但偶爾省略細節；Firebase 的文件詳盡但版本混亂（舊版與新版 API 常讓人混淆）。
八、供應商鎖定與可攜性：三年後你還能搬走嗎
8.1 Firebase 的鎖定深度
Firebase 的鎖定是多層的。資料層是專有格式，查詢語言是專有的，權限規則是專有的，函數觸發器綁定 Google 事件模型。你可以匯出資料，但應用邏輯幾乎要重寫。此外，FCM、Crashlytics、Remote Config 這些服務在 Google 生態外沒有等價替代品，遷移成本極高。
8.2 Supabase 的開源與自託管
Supabase 的核心全部開源（Apache 2.0 或 MIT），你可以用官方提供的 docker-compose 在自己的伺服器上跑起整套服務。資料就是 PostgreSQL，查詢就是 SQL，權限就是標準 RLS。就算你哪天不想用 Supabase Cloud，把 pg_dump 拿出來還原到任何 Postgres 實例即可，應用程式碼通常只需要改連線字串與 API 端點。
8.3 逃生路線的現實評估
話說回來，Supabase 也不是零鎖定。它的 SDK 語法、Realtime 頻道模型、Storage API 都是自家設計，搬家時仍要改程式碼。但關鍵差別在於：底層資料是開放的，且沒有商業授權限制。你隨時可以 fork 或自架，不必擔心定價政策改變或服務下架。這種「最壞情況下我還能把東西帶走」的安心感，是很多團隊選擇 Supabase 的情感因素，也是理性的風險管理。
九、選型建議：什麼情況該選哪一個
9.1 選 Firebase 的情境
團隊不想維運資料庫：完全不想碰 SQL、索引、連線池、備份策略。
資料模型天生是文件樹：例如聊天訊息、使用者設定、內容草稿。
9.2 選 Supabase 的情境
資料關係複雜：需要 join、聚合、交易、外鍵約束的商業應用。
成本需要可預測：查詢密集但資料量不大，不想被讀取次數帳單嚇到。
重視資料主權與可攜性：有自託管需求，或不想被單一雲商綁死。
團隊熟悉 SQL：工程師能直接寫查詢、除錯、優化效能。
想用開源生態：希望每個元件都能被替換、被審計。
9.3 混合與替代方案
實務上不一定要二選一。常見的混合模式是：用 Supabase 當主要資料庫與驗證，用 FCM 做推播，用 Firebase Analytics 做行為追蹤。反過來也有人用 Firebase Auth 搭配自架 Postgres，但這樣就失去了 Supabase 的整合便利。另外值得留意的替代方案還有 Appwrite（開源、支援多種資料庫）、Nhost（GraphQL + Postgres）、PocketBase（單一執行檔的輕量 BaaS），可以依團隊規模評估。
十、常見問題 FAQ
10.1 Supabase 能撐起大型專案嗎？
可以，但要看你怎麼用。PostgreSQL 本身能處理數億筆資料與每秒數萬次查詢，關鍵在於索引設計、連線池、讀取副本與分區策略。Supabase 官方客戶中有不少月活躍使用者達百萬級的案例。真正需要小心的是 Realtime 的連線數與 Edge Functions 的資源限制，這些要另外規劃。
10.2 Firebase 會不會被 Google 關掉？
機率極低。Firebase 是 Google Cloud 的重要入口產品，年營收規模龐大。但歷史上 Google 確實關閉過不少服務（如 Firebase 舊版 Hosting 功能、Firebase Invites 等），所以「個別功能被整併或淘汰」的風險是存在的。選擇 Firebase 時，建議核心邏輯不要過度依賴單一邊緣功能。
10.3 從 Firebase 搬到 Supabase 難嗎？
中等難度。你需要做三件事：把文件資料轉成關聯式結構、把 Security Rules 改寫成 RLS 政策、把客戶端 SDK 呼叫改成 Supabase 語法。資料轉換通常是最花時間的部分，尤其是原本高度反正規化的文件樹。建議在專案早期就決定，越晚搬遷成本越高。
十一、結論：不是誰取代誰，而是兩種取捨
如果把這場對決簡化成「Supabase 會不會取代 Firebase」，那問題本身就問錯了。Firebase 賣的是一條龍的行動應用平台，它的價值在於整合、在於 Google 的基礎設施、在於那些你不想自己做的雜事。Supabase 賣的是一組開放、可組合、以 PostgreSQL 為核心的基礎設施，它的價值在於透明、在於可攜、在於你隨時可以接手控制權。
對台灣的開發團隊來說，我的實務建議是這樣：如果你的產品以行動 App 為主、需要推播與離線體驗、團隊規模小且不想碰資料庫，Firebase 仍然是最高效率的選擇。如果你的產品資料關係複雜、查詢需求高、重視成本可預測性與資料主權，或者你打算做 AI 相關應用，Supabase 會讓你少走很多冤枉路。
最後一個提醒：無論選哪一邊，都不要把商業邏輯寫死在平台專屬的功能裡。把核心邏輯抽成獨立層，把資料結構保持乾淨，把匯出備份排進例行工作。這樣即使三年後你決定搬家，也不會是災難，而只是一次重構。工具會變，但這種「為離開做準備」的工程習慣，才是真正讓你立於不敗之地的東西。
希望這篇評測能幫你在兩者之間做出適合自己團隊的決定。如果你有實際使用的踩雷經驗或成本數據，也歡迎在雅寶社區 · 頂客論壇的討論區分享，讓更多開發者少繳一點學費。