--- tags: - backend - baas - supabase - pocketbase - appwrite - firebase aliases: - BaaS 比較 - 後端即服務選擇 created: 2024-12-22 updated: 2024-12-22 --- # Supabase 替代品完整指南：5 個值得考慮的開源後端方案 ![baas-comparison-cover](https://hackmd.io/_uploads/HkOETcvmWl.jpg) ## 當 Supabase 不是唯一選擇 Supabase 確實很棒。PostgreSQL 的強大、即時訂閱的便利、還有那個漂亮的管理介面，讓它成為很多開發者的首選。但實際使用一段時間後，你可能會遇到一些問題： - 免費額度用完後，費用跳升明顯 - 專案閒置會被暫停（雖然可以理解，但還是麻煩） - 自託管的文件不夠完整，設定起來比想像中複雜 - 某些地區的連線延遲讓即時功能打了折扣 這不是說 Supabase 不好，而是不同專案有不同需求。有時候你需要的是更輕量的方案，有時候是完全的資料掌控權，有時候單純是預算考量。 這篇文章整理了目前主流的替代方案，包含各自的優缺點和適用場景，幫你在下一個專案做出更適合的選擇。 --- ## 快速比較表 在深入介紹之前，先看整體比較： | 平台 | 開源 | 自託管難度 | 資料庫類型 | 最適合場景 | |------|------|-----------|-----------|-----------| | **Supabase** | ✅ | 中高 | PostgreSQL | 需要複雜 SQL 查詢的中大型專案 | | **PocketBase** | ✅ | 極低 | SQLite | 個人專案、快速原型 | | **Appwrite** | ✅ | 低 | MariaDB | 團隊協作、完整功能需求 | | **Firebase** | ❌ | N/A | NoSQL | Google 生態整合、成熟企業專案 | | **Nhost** | ✅ | 中 | PostgreSQL + Hasura | GraphQL 優先的專案 | --- ## 1. PocketBase：單檔案的極簡後端 ### 定位 一個 Go 語言編寫的後端服務，打包成單一執行檔。下載、執行、完成。 ### 核心優勢 **部署極簡**：整個後端就是一個檔案，不需要 Docker、不需要資料庫安裝、不需要任何依賴。放到任何 Linux 主機上就能跑。 **永久免費**：沒有額度限制，因為你自己託管。伺服器成本就是你唯一的成本。 **內建完整功能**： - SQLite 資料庫（支援即時訂閱） - 使用者認證（包含 OAuth2） - 檔案儲存 - Admin 管理介面 - REST API 自動生成 **可擴充性**：可以用 JavaScript Hooks 或直接用 Go 擴充功能。 ### 主要限制 - SQLite 的並發處理能力有限，不適合高流量場景 - 沒有原生的 Serverless Functions - 社群相對較小，遇到問題可能找不到現成解法 - 不支援水平擴展（單機限制） ### 適用場景 ``` ✅ 個人部落格後端 ✅ 小型 SaaS 的 MVP ✅ 內部工具 ✅ 學習後端開發 ✅ 需要完全掌控資料的專案 ❌ 高併發應用 ❌ 需要複雜查詢的資料分析 ❌ 多區域部署需求 ``` ### 快速體驗 ```bash # 下載 wget https://github.com/pocketbase/pocketbase/releases/download/v0.28.4/pocketbase_0.28.4_linux_amd64.zip unzip pocketbase_*.zip # 啟動 ./pocketbase serve # 開啟 http://127.0.0.1:8090/_/ 設定管理員帳號 ``` --- ## 2. Appwrite：功能完整的開源 BaaS ### 定位 功能最接近 Firebase 的開源替代品，提供完整的後端服務套件。 ### 核心優勢 **功能完整度高**： - 資料庫（類 NoSQL 操作，底層是 MariaDB） - 認證（支援 30+ OAuth 提供者） - 儲存（含圖片處理） - Functions（支援多種語言） - 即時訂閱 - 推播通知 **開發體驗**：SDK 覆蓋全面，文件清楚，Console 介面直觀。 **自託管友好**：Docker Compose 一鍵部署，文件完整。 **活躍的社群**：Discord 社群活躍，核心團隊回應快。 ### 主要限制 - 資源佔用較大（Docker 容器多） - 查詢能力不如原生 SQL 靈活 - 部分進階功能仍在開發中 - 雲端版本的定價不算便宜 ### 適用場景 ``` ✅ 需要完整 BaaS 功能的專案 ✅ 團隊協作開發 ✅ 從 Firebase 遷移 ✅ 需要 Serverless Functions ❌ 需要複雜 SQL 查詢 ❌ 資源有限的伺服器 ❌ 極簡需求的小專案 ``` ### 快速體驗 ```bash # Docker 部署 docker run -it --rm \ --volume /var/run/docker.sock:/var/run/docker.sock \ --volume "$(pwd)"/appwrite:/usr/src/code/appwrite:rw \ --entrypoint="install" \ appwrite/appwrite:1.5.7 # 完成後開啟 http://localhost/ ``` --- ## 3. Firebase：成熟穩定的商業方案 ### 定位 Google 的 BaaS 服務，市場上最成熟的解決方案之一。 ### 核心優勢 **成熟穩定**：經過多年發展，功能穩定，文件完整，社群資源豐富。 **Google 生態整合**：與 Google Cloud、Google Analytics、Google Ads 無縫整合。 **全球基礎設施**：多區域部署，低延遲。 **完整功能**： - Firestore（NoSQL 資料庫） - Authentication - Cloud Storage - Cloud Functions - Hosting - Cloud Messaging ### 主要限制 - **非開源**：無法自託管，資料在 Google 手中 - **廠商鎖定**：資料結構和 API 都是專有的，遷移成本高 - **成本不可預測**：流量計費模式可能導致帳單爆炸 - **NoSQL 限制**：複雜查詢需要繞路處理 ### 適用場景 ``` ✅ 企業專案，預算充足 ✅ 需要 Google 生態整合 ✅ 團隊熟悉 Firebase ✅ 全球用戶分佈 ❌ 需要資料自主權 ❌ 預算敏感的專案 ❌ 需要複雜關聯查詢 ``` ### 定價提醒 Firebase 的免費額度看起來很慷慨，但要注意： - Firestore 讀取按次計費，高頻讀取很快超標 - Cloud Functions 的冷啟動時間影響用戶體驗 - 超出免費額度後的單價不低 --- ## 4. Nhost：GraphQL 優先的 Hasura 整合方案 ### 定位 在 Hasura GraphQL Engine 之上包裝認證、儲存、Serverless Functions 的完整方案。 ### 核心優勢 **GraphQL 原生**：Hasura 自動根據資料庫 schema 生成 GraphQL API，包含訂閱功能。 **PostgreSQL**：享受完整的 SQL 能力，複雜查詢沒問題。 **開源**：可以自託管，資料完全掌控。 **完整功能**： - 認證（含 OAuth2、Magic Link） - 儲存 - Serverless Functions - 即時訂閱 ### 主要限制 - Hasura 有學習曲線 - 自託管的元件較多，維護複雜度高 - 社群規模相對較小 - 雲端版本定價不算親民 ### 適用場景 ``` ✅ 團隊熟悉 GraphQL ✅ 需要複雜關聯查詢 ✅ 前端使用 Apollo、urql 等 GraphQL 客戶端 ✅ 需要即時資料同步 ❌ 團隊不熟悉 GraphQL ❌ 簡單 CRUD 需求（殺雞用牛刀） ❌ 資源有限的環境 ``` --- ## 5. 其他值得關注的選項 ### Directus **定位**：Headless CMS，但可作為通用後端使用。 **適合**：內容管理為主的專案、需要非技術人員操作後台的場景。 **特點**： - 視覺化的資料庫管理 - 自動生成 REST 和 GraphQL API - 角色權限管理完整 - 可連接現有資料庫 ### Convex **定位**：新一代的反應式後端，強調開發體驗。 **適合**：需要即時功能、願意嘗試新技術的團隊。 **特點**： - TypeScript 原生 - 自動快取和即時同步 - Serverless 架構 - 目前只有雲端版本 ### Turso（LibSQL） **定位**：SQLite 的分散式版本。 **適合**：需要 SQLite 的簡單性，但又要多區域部署的場景。 **特點**： - 邊緣部署 - SQLite 相容 - 低延遲 --- ## 如何選擇？ 根據你的需求，可以用這個決策流程： ```mermaid flowchart TD A[需要後端服務] --> B{資料主權重要嗎？} B -->|非常重要| C{團隊規模？} B -->|可接受雲端| D{預算充足嗎？} C -->|個人/小團隊| E[PocketBase] C -->|中大型團隊| F{需要 GraphQL？} F -->|是| G[Nhost] F -->|否| H[Appwrite] D -->|是| I{已在 Google 生態？} D -->|預算敏感| J[Supabase / Appwrite 雲端] I -->|是| K[Firebase] I -->|否| L[Supabase] ``` ### 簡單版建議 | 你的情況 | 推薦選擇 | |---------|---------| | 個人專案，想快速上線 | PocketBase | | 小團隊，需要完整功能 | Appwrite 或 Supabase | | 企業專案，預算充足 | Firebase 或 Supabase Pro | | 前端團隊，熟悉 GraphQL | Nhost | | 需要複雜 SQL 查詢 | Supabase 或 Nhost | | 內容管理為主 | Directus | --- ## 遷移考量 如果你正在考慮從某個平台遷移，這裡是一些重點： ### 從 Firebase 遷移 - Firestore 的資料結構需要重新設計（NoSQL → SQL） - Authentication 的 UID 需要處理 - Cloud Functions 需要重寫 - 建議：先在新平台建立 MVP，確認可行後再完整遷移 ### 從 Supabase 遷移 - PostgreSQL 資料可以直接 dump/restore - RLS（Row Level Security）規則需要用新平台的方式重寫 - 即時訂閱的實作方式可能不同 ### 通用建議 1. 先評估資料量和複雜度 2. 建立詳細的遷移計畫 3. 考慮過渡期的雙寫策略 4. 預留足夠的測試時間 --- ## 結語 沒有完美的後端方案，只有最適合當前需求的選擇。 Supabase 依然是很棒的選項，特別是需要 PostgreSQL 強大查詢能力的場景。但了解替代品能讓你在不同專案中做出更好的決策。 如果你是個人開發者，想要最快上手、最低維護成本的方案，PocketBase 值得一試。如果你需要完整的 BaaS 功能又想保持開源，Appwrite 是穩健的選擇。 下一篇文章會深入介紹 PocketBase 的實際操作，從安裝到部署一個完整的應用。如果你對這個輕量級方案有興趣，可以繼續閱讀 [[Blog-PocketBase入門到實作完整教學]]。 --- ## 參考資源 - [PocketBase 官方網站](https://pocketbase.io/) - [Appwrite 官方文件](https://appwrite.io/docs) - [Supabase vs Appwrite 比較](https://appwrite.io/blog/post/appwrite-compared-to-supabase) - [開源 BaaS 列表](https://github.com/PARC6502/awesome-baas)