Supabase Storage 與 Cloudflare R2 都能存圖片、影片、附件與使用者上傳檔案，但它們解決的問題不同：Supabase Storage 是以資料庫與使用者權限為中心的應用儲存；Cloudflare R2 是以物件儲存、S3 相容 API 與網路分發為中心的基礎設施。
因此，選型不應只問「每 GB 多少錢」，而要先回答四個問題：檔案是否和會員、資料列權限綁在一起？讀取流量是否很大？團隊是否已使用 Workers？未來是否需要把儲存服務換到其他 S3-compatible 平台？
一張表先看懂
| 比較面向 | Supabase Storage | Cloudflare R2 |
|---|---|---|
| 核心定位 | 應用程式的檔案儲存，與 Supabase 專案整合 | S3-compatible 物件儲存 |
| 權限模型 | Bucket、物件路徑與 Postgres RLS／Auth 整合 | API token、bucket 權限、Workers 驗證，應用權限需自行設計 |
| API | Supabase client、REST 與 Storage API | Workers API、S3-compatible API、REST API、Wrangler |
| 資料庫關係 | 適合和使用者、訂單、metadata 同一個 Supabase 專案管理 | 物件 metadata 與交易資料通常要另外放資料庫 |
| 網路流量 | 依方案有 cached／uncached egress 額度，超額計費 | 直接由 R2、Workers API、S3 API 或 r2.dev egress 不收資料傳輸費 |
| 遷移彈性 | 需要依 Supabase API 與資料模型規劃 | S3 相容，既有 S3 SDK 較容易重用 |
| 適合場景 | 會員頭像、私人附件、SaaS 上傳、快速 MVP | 圖片 CDN、影片、備份、下載量大的公開素材、Workers 應用 |
Supabase Storage 的優勢與限制
Supabase 官方文件把 Storage 分成 Files、Folders 與 Buckets，並建議依不同安全與存取規則建立 bucket。這使它很適合「檔案是產品功能的一部分」的系統：使用者上傳履歷、客服附件、團隊文件或會員頭像時，可以沿用 Supabase Auth 與資料庫中的 owner id、tenant id 和業務狀態。
另一個優點是落地速度。前端可用 Supabase client 上傳，資料庫存檔案 metadata，RLS 負責限制誰可以讀寫。對小型團隊而言，少維護一層簽名 URL、權限同步與 webhook，通常比追求最低儲存單價更有價值。
成本上，Supabase 目前 Free 方案包含 1 GB file storage；Pro 方案包含 100 GB，超出後為每 GB 每月 0.0213 美元。Pro 另有 250 GB uncached egress 與 250 GB cached egress 額度，超出額度分別為每 GB 0.09 與 0.03 美元。這些額度是組織與方案的一部分，不能只拿 Storage 單項價格比較。
限制是：如果主要需求是大量公開檔案下載，Supabase 的 egress 額度可能成為成本與流量設計重點；若檔案本身和會員權限沒有關係，Supabase 的整合優勢也可能用不到。
Cloudflare R2 的優勢與限制
Cloudflare R2 的定位更接近傳統 object storage。官方提供 Workers API、S3-compatible API 與 REST API，也能透過 Wrangler 管理 bucket。已有 AWS S3 SDK 的團隊，通常只需調整 endpoint 與憑證範圍，就能重用部分程式碼。
R2 Standard storage 目前為每 GB-month 0.015 美元，Class A 操作每百萬次 4.50 美元，Class B 操作每百萬次 0.36 美元；每月免費額度為 10 GB-month、100 萬次 Class A 與 1,000 萬次 Class B。直接由 R2、Workers API、S3 API 或 r2.dev 傳出資料不收 egress 費，但串接其他 Cloudflare 服務仍可能產生該服務的費用。
這個模型對圖片、影片、下載檔等「儲存量大且讀取流量高」的情境有吸引力。不過免 egress 不代表免費：大量小物件會增加操作次數，頻繁 list、rewrite、multipart upload 或影像處理也要納入成本；公開 bucket、簽名 URL、租戶隔離與刪除流程則需要應用層自行設計。
依情境選擇
選 Supabase Storage
- 檔案權限跟 Supabase Auth 使用者或 Postgres row 綁定。
- 需要快速完成會員上傳、私人附件與後台管理。
- 團隊已使用 Supabase Database、RLS、Edge Functions，不想再維護一套物件權限系統。
- 檔案流量中等，方案內的 egress 額度足夠。
選 Cloudflare R2
- 圖片、影片、備份或資料集會被大量公開讀取。
- 應用已部署在 Cloudflare Workers，需要低延遲存取 bucket。
- 團隊希望使用 S3-compatible SDK，降低未來更換 object storage 的成本。
- 需要把儲存與主要資料庫分離，獨立擴充與計算成本。
混合架構
不要把所有檔案放進同一個服務。常見做法是：Supabase 保存使用者、權限與檔案 metadata；R2 保存公開圖片、影片或大型附件。資料庫只保存 object key、checksum、mime type、size、owner 與狀態，不保存檔案本體。
使用者 → API 驗證 → metadata（Supabase Postgres）
↘ signed upload URL → object（Supabase Storage 或 R2）
混合架構的代價是同步與刪除流程更複雜。要定義 upload pending、uploaded、scan_failed、deleted 等狀態，並以背景工作清理 orphan objects，否則資料庫刪掉紀錄後，物件仍會持續計費。
先用實際用量試算
至少估算以下欄位，再放入兩家的計價器或帳單模型：
stored_gb = 平均儲存量
read_gb = 每月下載量
write_ops = 每月上傳、覆寫與 multipart 操作
read_ops = 每月 GET、HEAD、LIST 操作
private_ratio = 私有檔案比例
Supabase 要把方案月費、Storage 超額、cached／uncached egress、Image Transformations 與可能的 compute 一起算。R2 則要把 GB-month、Class A、Class B、Infrequent Access retrieval 與 Workers 或 CDN 相關費用一起算。兩者的費用頁都會更新，正式採購前應重新讀取官方價格。
上線前的五個檢查
- 權限：用一般使用者、跨租戶使用者與管理員測試讀寫，不只測成功案例。
- 網址：公開 URL、signed URL 與下載回應的
Content-Type、快取與到期時間符合預期。 - 一致性：資料庫 metadata 與 object key、size、checksum、刪除狀態一致。
- 成本：用實際檔案大小、下載量與操作次數做高低流量試算。
- 復原：測試上傳中斷、重試、重複檔案、惡意檔案掃描失敗與 orphan object 清理。
結論
如果你的問題是「如何最快把有權限的檔案功能接進會員系統」，先看 Supabase Storage。如果你的問題是「如何以物件儲存承載大量公開流量，並靠 Workers 或 S3 API 彈性整合」，先看 Cloudflare R2。
最穩妥的選法不是預先猜哪一家永遠便宜，而是用一個真實 workload 做小型壓測：同樣的檔案大小、上傳次數、下載流量、權限案例與保留週期，量測成本、延遲、失敗重試與維護時間，再決定單一或混合架構。
來源與日期
- Supabase Pricing，2026-09-12 查閱：方案、Storage 額度與 egress 計價。官方來源
- Supabase Storage Quickstart，2026-09-12 查閱：Files、Folders、Buckets 與安全規則概念。官方文件
- Supabase Storage Pricing，2026-09-12 查閱：Storage 使用量計費。官方文件
- Cloudflare R2 Pricing，2026-09-13 查閱、頁面標示 2026-08-07 更新：儲存、操作、免費額度與 egress。官方文件
- Cloudflare R2 S3 API，2026-09-13 查閱、頁面標示 2026-04-21 更新：S3-compatible API 與憑證範圍。官方文件