---
# System prepended metadata

title: Supabase 替代品完整指南：5 個值得考慮的開源後端方案
tags: [pocketbase, appwrite, supabase, firebase, baas, backend]

---

---
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)
