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