你做一個網站，需要存使用者資料。最開始可能只想找一個地方放 table，結果打開 Supabase 之後，旁邊還有 Authentication、Storage、Realtime、Edge Functions、API Keys。這時很容易出現一個疑問：我不是只想要資料庫嗎？為什麼突然多出一整排東西？
因為 Supabase 不是單純的 database hosting。比較準確的說法是：它是一個以 PostgreSQL 為核心，往外整合 API、登入、檔案、即時通訊與 server-side function 的後端平台。資料最後仍然落在真正的 Postgres 裡，但你不必自己從零架起所有周邊服務。
一句話先記住：Supabase ≠「比較簡單的 PostgreSQL」；它比較像「Postgres + 一組已接好的 backend building blocks」。
核心仍然是完整的 PostgreSQL
Supabase 官方文件直接寫得很清楚：每個 project 都有一個完整的 Postgres database。你仍然有 table、row、column、foreign key、index、view、function、trigger、transaction，也可以用 SQL 查詢。
所以如果你已經理解 relational database，Supabase 並不是另一套完全不同的資料模型。你在 Table Editor 裡按按鈕新增欄位，底下依然是在修改 Postgres schema；你開 SQL Editor 寫 SQL，也是在操作同一個資料庫。
↓
Supabase 提供的 API / Auth / Realtime / Functions
↓
PostgreSQL
這點很重要，因為它代表你不是被鎖在一個只有 Dashboard 才能理解的黑盒子裡。很多資料庫能力仍然來自 Postgres 本身。
那 Supabase 多做了什麼？第一個是 Data API
如果只有 PostgreSQL，前端瀏覽器通常不會直接拿 database password 去連資料庫。傳統做法是自己寫 backend：前端呼叫你的 API，backend 再查 database。
Supabase 在 Postgres 上面提供 auto-generated Data API。資料表與 schema 建好之後，就能透過 REST 介面存取資料；官方的 REST API 是由 PostgREST 產生，而且會跟著 database schema 反映變化。你也可以透過 supabase-js 這類 client library 呼叫它，而不是自己手刻每一個 CRUD endpoint。
↓ supabase-js / REST
Data API
↓
Postgres
這也是 Supabase 很容易讓初學者產生「沒有 backend」錯覺的地方。其實 backend 並沒有消失，而是一部分通用 backend 能力已經由平台幫你提供。
前端可以直接讀資料，不代表安全性可以省掉
既然 browser 可以直接打 Data API，最重要的問題就變成：那使用者是不是可以隨便改 request，看到別人的資料？答案取決於你的權限規則。
Supabase 很依賴 PostgreSQL 的 Row Level Security，RLS。RLS 可以把規則直接掛在 table 上，例如「登入使用者只能讀自己的資料」；資料庫每次處理 query 時都會套用 policy。官方也明確要求，暴露給 Data API 的 table 應該啟用 RLS 並正確設定權限。
↓ RLS policy
只留下 user_id = 目前登入者 的 rows
所以 publishable key 可以出現在前端，不代表它是一把萬能資料庫鑰匙。真正限制使用者能看到哪些 row 的，是 role、JWT 與 RLS policy。相反地，能繞過 RLS 的 secret / service-role 類金鑰就不能放進 browser。
Auth：幫你處理「這個使用者是誰」
Supabase Auth 是另一個獨立但和資料庫整合得很深的部分。它可以處理 Email、Passwordless、Social Login 等登入流程，使用者登入後取得身分資訊與 token，再讓 database policy 知道現在是哪個 user 在操作。
這裡可以接回前面幾篇文章的概念：OAuth / OIDC 負責第三方授權與登入協定；session / token 負責延續登入狀態；Supabase Auth 則把這些機制整理成可以直接整合進產品的服務。
但「有 Auth」仍不等於「資料就安全」。Auth 回答的是你是誰，RLS / authorization 規則才回答你可以做什麼。
Storage：不是把圖片塞進 database column
照片、影片、PDF 這類檔案，通常不適合直接當成普通欄位資料處理。Supabase Storage 提供 bucket 與 object storage，負責檔案上傳、下載與存取控制，也能和 Auth、RLS 類型的權限模型一起使用。
常見架構會是：database 保存檔案的路徑、擁有者、metadata 等結構化資料；真正的大型 binary file 放在 Storage。這樣資料庫和檔案系統各自處理自己擅長的部分。
Realtime：不是一直重新查 Database
如果你做聊天室、協作工具或 live dashboard，畫面不能每秒都手動重新整理。Supabase Realtime 提供 Broadcast、Presence 與 Postgres Changes 等能力，讓 client 能透過長連線收到即時事件。
例如資料庫某筆內容被更新後，前端可以訂閱變化；多人協作時，也可以同步在線狀態或自訂 message。這是另一層服務，不代表 PostgreSQL 自己突然變成前端 WebSocket server。
Edge Functions：當 auto-generated API 不夠時
很多功能不適合直接讓 client 呼叫 database。付款 webhook、寄信、使用第三方 secret key、管理員操作、呼叫外部 API，通常都需要真正的 server-side logic。
Supabase Edge Functions 就是拿來放這類程式碼的。官方目前提供全球分散的 TypeScript / Deno 相容執行環境，可以接 webhook、驗證 request、讀取 secrets，再呼叫 Supabase 或其他外部服務。
├→ Postgres / Auth / Storage
└→ Stripe / Email / 其他第三方 API
所以使用 Supabase 不代表你的應用永遠不需要 backend code。比較準確的說法是：簡單 CRUD 可以直接用平台產生的 API；需要商業邏輯與秘密憑證時，再放到可信任的 server-side environment。
「Firebase 的開源替代品」可以幫你入門，但不能當完整定義
Supabase 常被拿來和 Firebase 比較，因為兩者都會提供 database、auth、storage、serverless functions 等整合能力。這個類比可以幫你快速理解產品類型，但底層思路並不相同。
Supabase 很大一部分設計建立在 PostgreSQL 和其他既有開源元件上，而且 relational model、SQL、Postgres extensions、RLS 都是核心。把它只理解成「Firebase clone」會漏掉最重要的技術特徵：它不是另外發明一套資料庫，而是把 Postgres 放在平台中心。
Supabase Studio 只是控制面板，不是資料本身
Dashboard 裡的 Table Editor、Auth Users、Storage Browser 很方便，但它們只是管理介面。你關掉網頁，database 還是 database；真正重要的是 schema、policy、function、migration、storage object 和程式碼。
這也代表正式專案不應該只靠「我記得昨天在 Dashboard 點了什麼」。資料庫 schema 與 policy 最好能透過 migration 或 SQL 留下版本，Edge Functions 也應放進 source control。否則專案一旦換環境、多人協作或需要回滾，只有 Dashboard 操作紀錄很難重建完整狀態。
Supabase 省掉的是基礎設施工作，不是系統設計
開一個 Supabase project 很快，登入也可以很快接上，table 幾分鐘就能建立。但平台沒有替你決定資料表怎麼設計、RLS policy 應該怎麼寫、哪些 operation 必須放 server、secret 怎麼管理、index 該建在哪裡。
因此它真正降低的是「自己部署 Postgres、自己架 Auth server、自己做 Storage API、自己維護 Realtime infrastructure」這一類重複工程；資料模型、權限邊界與應用邏輯還是你的責任。
Supabase 幫你少造很多輪子，但不會替你決定輪子應該裝在哪裡。
把整個 Supabase project 拆成一張圖
│
├─ Data API ───────────→ PostgreSQL
├─ Auth ───────────────→ 使用者身分 / JWT
├─ Storage ────────────→ 檔案
├─ Realtime ───────────→ 即時事件
└─ Edge Functions ─────→ 自訂 server-side logic
Postgres RLS / Roles / Policies：控制資料能不能被讀寫
看到這張圖之後，「Supabase 到底是資料庫還是 backend？」這個問題就比較好回答了：它同時包含 database 與多種 backend service，但核心 database 是 PostgreSQL。
如果只把 Supabase 當成「有漂亮介面的資料庫」，你會錯過它最重要的價值，也可能忽略最重要的安全邊界。理解 Postgres、API、Auth、RLS、Storage、Realtime 和 Functions 各自負責哪一層，才是真的在理解 Supabase。
資料來源
本文依據 Supabase 官方 Platform 與 Features 文件整理產品架構；Data API 依據 Data REST API；前端資料存取與權限部分依據 Row Level Security 與 Securing your data；Edge Functions 與 Realtime 則參考各自官方指南。