Supabase 替代品完整指南：5 個值得考慮的開源後端方案

Supabase 替代品完整指南：5 個值得考慮的開源後端方案

baas-comparison-cover

當 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
✅ 內部工具
✅ 學習後端開發
✅ 需要完全掌控資料的專案

❌ 高併發應用
❌ 需要複雜查詢的資料分析
❌ 多區域部署需求

快速體驗

# 下載
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 查詢
❌ 資源有限的伺服器
❌ 極簡需求的小專案

快速體驗

# 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 圖表 — 原始 HackMD 版本可正常渲染]

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]</div>

簡單版建議

你的情況 推薦選擇
個人專案，想快速上線 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入門到實作完整教學]]。

參考資源

本文最初發布於 HackMD @BASHCAT。

留言

張貼留言

這個網誌中的熱門文章

Arduino 課本可能沒教的事(1)

圖片
　　相信有用過Arduino的人都會知道，在一個開發板上的IO腳，有分為"數位腳"、"類比輸入"，也就是板子上場看到的數字0～13與A0~A5，在比較常見的教材中，往往很少提到A0~A5腳位的使用方式，正常都是說明，如何在上面接上一個可變電阻，在由可變電阻調整電壓進入類比輸入端，再有數位腳輸出對應的亮度，重點來了，因為這樣可能有些人認為A0~A5"只能"做類比的事情，但這些類比腳，亦可拿來當數位腳使用，可以從下圖看到，A0～A5於粉紅色區塊標示為14～19，代表其實該腳位要用於數位時，它的編號，而MEGA版本也是相同道理，數位腳由53之後轉為，A0=54、A1=55…以此類推，總而言之，這樣UNO版本腳位其十就很多，足以供一般專案使用。
閱讀完整內容

SI4432 搭配Arduino

圖片
        前陣子從購入兩片si4432模組，拿來搭配arduino使用，傳輸效果算是相當不錯，訊號從1樓可以打到5F，由於已經作成模組化了，使用上也不會太困難，但需要同時接收/發射，所提供的範例是不夠用的。         Arduino&si4432連接方法，由於Si4432工作電壓用的是3.3V，所以建議以CD4050做電位轉換， 但我測試的時候，是使用arduino mini pro ，工作電壓直接接上3.3V所以沒有在做轉換，要使用5V的MCU則需要加，如果不怕燒掉的話也是可以直接上。 arduino mini pro si4432 library則是使用RF22 http://www.airspayce.com/mikem/arduino/RF22/ 檔案中包含了基本的範例，可以直接使用。
閱讀完整內容

燒錄 Arduino mini Pro 燒錄

圖片
    Arduino Mini Pro 算是Uno的縮小板，使用上也沒太大變化，可以注意的是，市面上可能分為有幾個版本16Mhz、8Mhz就連電壓也會有5V、3.3V，但我這邊使用的是5V-16Mhz，工作於3.3V的時候也是可以正常工作，    該有的腳位也都拉出來了，這塊mini上面還有A4~A7，網路上有些比較精簡的版本就沒有這4pin。     接下來介紹燒錄方法，需要準備一組USB to TTL轉換，有RX/TX就可以了， 將 mini RX->TTL TX mini TX->TTL RX mini VCC->TTL VCC mini GND->TTL GND 接妥後，開啟自己的CODE，這邊用範例Blink測試，按下上傳後，等出現Uploading...這時候，立刻馬上，按下mini的 Reset，成功後就會將CODE Upload上去了。  手腳太慢就會出現下面這畫面  網路上還有領外一個使用Uno對燒的方式，也是相同原理，只是Reset是接Uno板子上的Reset這樣就不用手去按他了。
閱讀完整內容