Side Project 後端選型：Supabase 好用，但多專案成本會先爆炸
作者原本喜歡用 Supabase 做 side projects，因為 CLI、migration、Auth 與 Realtime 整合很順。但 Pro plan 雖是 US$25/月，額外 project 會再增加 compute 成本；如果有 10 個 projects，很容易變成上百美元。作者因此考慮改成 Neon + Clerk，Realtime 自己處理。
留言提出 PocketBase、Appwrite self-hosted、Turso + Clerk + R2、CockroachDB、VPS 自架 Postgres 等替代方案；也有人提醒 Firebase 若開 Cloud Functions 仍可能有費用，Neon 免費層多專案隔離也要注意。
Supabase 官方 pricing 顯示 Free 限 2 個 active projects；Pro from US$25/月，first project included，additional projects from US$10/mo，paid plans include US$10/mo compute credits enough for one Micro instance。Firebase Spark 有 no-cost usage limits、Blaze 是 pay-as-you-go；Neon Free 標示 100 projects 與 usage limits；Clerk Hobby Free 支援 unlimited applications 且每 app 有 MRU 限額。
這不是「哪個平台最好」，而是哪種成本曲線適合你的專案
| 組合 | 最適合 | 優點 | 主要風險 |
|---|---|---|---|
| Supabase | 單一產品、快速 MVP、需要 Postgres + Auth + Realtime + Storage + Edge Functions | 開發體驗完整；CLI / migration / local dev 友善；Postgres 生態熟悉 | 多專案會遇到額外 project / compute 成本；Free active projects 有限制；低流量多專案不一定划算 |
| Firebase | 前端導向、低流量、想用 no-cost tier 撐早期開發 | Spark plan 有 generous no-cost usage limits；低流量開發階段成本可控；Google 生態成熟 | 資料模型與 vendor lock-in；後續遷移較痛；Cloud Functions / Blaze / 使用量上升後仍可能產生成本 |
| Neon + Clerk | 想保留 Postgres、Auth 外包、低流量多專案 | Neon serverless Postgres、可 scale to zero；Clerk Auth DX 佳且支援多 apps；成本可拆分 | Realtime 要自建或另找服務；跨服務整合與 webhook / session / RLS 設計要自己處理；免費層隔離與限制需確認 |
| Turso + Clerk + R2 | 全球邊緣讀取、SQLite/libSQL、輕量 CRUD | 架構輕、邊緣友善、搭配 R2 可降低物件儲存/egress 成本 | 不是標準 Postgres；複雜 relational / analytics / extensions 需求要先驗證 |
| PocketBase / Appwrite self-hosted | 想要 BaaS 體驗但願意自架 | 單機/小團隊成本低；功能集中；可部署在 VPS | 維運、備份、升級、安全、監控都回到自己身上；serverless 便利性下降 |
| VPS 自架 Postgres | 成本敏感、技術可控、低流量專案集合 | US$5～10/月可跑很多低流量專案；隔離策略可自訂 | 備份、升級、資安、連線池、HA、監控、災難復原都要自己負責 |
多專案 side project 的選型規則
- 先算固定成本，不要只看流量成本：side project 常常不是流量燒錢，而是「每個 project 一份 compute / add-on / dev environment」先堆出月費。
- 把 project 數量納入架構設計：一個產品用一個 Supabase project 很合理；十個小實驗都開獨立 paid project，就會變成成本災難。
- Auth、DB、Realtime 不一定要同一家：Supabase 的整合度高，但 Neon + Clerk 代表把 Postgres 與 Auth 拆開；Realtime 可以用 polling、WebSocket、server-sent events、trigger + queue、或第三方服務補上。
- 看遷移成本：Firebase 早期可能便宜，但資料模型與 Cloud Functions 生態綁定較深；Supabase/Neon 的 Postgres 可攜性較好，但平台功能仍有差異。
- 如果不想維運，就不要假裝 self-hosted 免費：VPS 帳單便宜，不代表總成本低。備份、更新、安全、監控與事故處理都是真實成本。
實用決策框架
如果目標是快速打磨一個正式產品，而且會用到 Auth、Realtime、Storage、Edge Functions、Dashboard 與 SQL migration，Supabase 的整合價值通常值得付費。
優先考慮固定成本低、可 scale to zero、可多 project / app 管理的方案，例如 Firebase Spark、Neon Free/Launch + Clerk Hobby、或把多個實驗共用一個 DB instance 並用 schema / tenant 隔離。
如果 Realtime 是產品核心，Supabase 仍有優勢；如果只是通知、狀態更新或簡單協作，可以先用 polling / SSE / WebSocket gateway / managed pub-sub，避免為每個實驗專案付完整 BaaS 成本。
可以考慮 PocketBase、Appwrite、自架 Postgres 或 Turso，但要把備份、監控、更新與安全列入成本。對不想維護 native cloud 的開發者，serverless 仍是合理偏好。
可直接採用的分級策略
| 專案階段 | 建議架構 | 原因 |
|---|---|---|
| 想法驗證 / Demo | Firebase Spark、Neon Free、SQLite/Turso、單一共用 DB | 先降低固定費用，不要為還沒驗證的想法付 production stack 成本 |
| MVP 有少量使用者 | Neon + Clerk、Supabase Free/Pro 單 project、Firebase Blaze 控制預算 | 開始需要 Auth、部署穩定性與資料可攜性，但仍要避免多 project 固定費用膨脹 |
| 正式產品 | Supabase Pro/Team、Neon paid + Clerk paid、Firebase Blaze + GCP 管理 | 此時付費買 DX、備份、支援、監控與擴展能力比較合理 |
| 長期低流量工具 | VPS / self-hosted / shared Postgres / PocketBase | 如果能接受維運，集中部署可以把多個小工具的固定成本壓低 |
- Threads 原文：@calvin.j.ku：Supabase 多專案成本與 Neon + Clerk 遷移想法
- Supabase Pricing：https://supabase.com/pricing
- Supabase Billing Docs：https://supabase.com/docs/guides/platform/billing-on-supabase
- Neon Pricing：https://neon.com/pricing
- Clerk Pricing：https://clerk.com/pricing
- Firebase Pricing：https://firebase.google.com/pricing