Supabase

前言#

自己寫的一些專案做到最後總會遇到同一個問題：後端要放哪裡。用 AWS、GCP 這類大型雲平台當然做得到，但對一個個人專案來說，光是搞懂 IAM 權限和計費模型就要花掉好幾個晚上，而真正需要的其實只有一個資料庫、一套帳號系統和一個檔案儲存空間。

Supabase 就是為了填補這個空缺而存在的。它把上述這些東西打包成一個服務，底層是 PostgreSQL，不是自創的私有資料庫，所以就算之後要搬走，也不會被綁死在特定廠商上。不論在資源有效利用或是價格上，對個人專案來說都是很好的選擇。

這篇會走過 Supabase 的計費方案與主要功能，讓你判斷它適不適合你的專案。程式碼開發的部分不在這篇的範圍內。

這一步不多做說明，用 GitHub 帳號登入是最快的，網路上也有很多資源。

Supabase 有提供 Free plan 給使用者，使用量限制如下：

以 Database 來說，0.5 GB 大概就是 500,000,000 bytes。假設一張表欄位很多，每個欄位都是 8 bytes 塞好塞滿，再加上 overhead 抓 512 bytes 好了，那也還可以存下大約 1,000,000 筆資料。對自己做的小型服務來說，其實是非常夠用的。

真正要留意的反而不是容量，而是免費專案在連續七天沒有任何請求後會被自動暫停。作品集類型的網站很容易踩到這一點，重新啟用雖然只要在後台按一下，但如果剛好有人在那個時間點打開你的網站，看到的就是一個壞掉的頁面。

在 Project 頁面這邊可以新增專案。這裡有一個選擇之後改不掉：伺服器位置。盡量選擇跟你服務的使用者地區較近的位置，效能上會更好，不然每一次查詢都會多出可觀的來回延遲。

這邊先額外插入一個話題：Supabase 有提供整合服務，可以幫你把環境變數直接同步到你的 GitHub repo 或是 Vercel 專案上，省去手動複製金鑰的麻煩。不過前面的串接程式碼還是要自己完成。

Supabase 很好心地提供了各式語言和框架下該如何連接的說明，直接複製對應的連線字串就能用。

這裡要注意的是它給的兩把金鑰：anon key 是可以放在前端的公開金鑰，權限受到 Row Level Security 規則的限制；service_role key 則會繞過所有 RLS 規則，只能放在後端，一旦外洩等於整個資料庫對外開放。

Table Editor & SQL Editor

在這兩個地方可以建立你要的資料表，然後寫 query 做測試。Table Editor 適合快速建表，SQL Editor 則適合驗證比較複雜的查詢。
Database

可以視覺化檢視 schema，還有待會提到的 function。所有對資料庫的管理都集中在這裡，包含索引、觸發器與備份。
Authentication

這是一套完整的帳號系統，包含：
- 各類登入方式（Email、OAuth、Magic Link）
- session 管理
- 使用者資料管理
- Webhook 等等
直接省去開發資訊服務時建立帳號系統的大量時間。而且它和資料庫是整合的，登入後的使用者身分可以直接用在 Row Level Security 規則裡，做到「使用者只能讀寫自己的資料」而不需要寫任何後端程式碼。
Storage

就是一個物件儲存服務，類似 AWS S3，專門放檔案（圖片、影片、PDF⋯）。上傳後檔案會獲得 URL，就可以直接在網頁或 App 前端顯示。
Functions

也就是 Serverless Functions，跑在 Supabase 的全球 Edge Node 上。可以在上面寫 API、設定排程、撰寫 Webhook 等等，適合放那些不能暴露在前端的邏輯，例如呼叫第三方 API 時要用到的金鑰。
Realtime

在事件發生時透過 WebSocket 把 Postgres 資料表的變更推送到前端，做到即時同步。聊天室、共同編輯、即時儀表板這類需求，用它就不需要自己維護一套 WebSocket 伺服器。

除了內建關於記憶體容量或是 Function calls 次數的報表之外，也可以針對註冊人數做自己的 custom report，或者是其他想觀察的趨勢，都可以在這裡完成。

Supabase 對新創或個人專案的後端來說是非常友善的，可以在發展到企業規模之前先有一個產品輸出，不用一開始就跳進 AWS、Azure、GCP 這些大型服務。

而因為底層就是標準的 PostgreSQL，就算哪天真的成長到需要自架，資料也搬得走，這大概是它相較於其他 BaaS 平台最大的優勢。

那這篇文章就到這邊，之後也會出一篇完整專案的介紹文章。