Supabase Architecture：SDK、API、Auth、Postgres、RLS 到底在哪一層

Learning outcomes

• 能畫出 Browser → Supabase API → Postgres 的資料流。
• 能區分 client SDK 與 database engine。
• 能把 Auth、RLS、constraint 放到正確責任層。
• 能依 failure evidence 判斷是哪一層出問題。

1. 最小架構圖

Browser / Android App
   ↓ client SDK
HTTPS
   ↓
Supabase Platform APIs
   ├─ Auth
   ├─ Data API
   ├─ Storage
   └─ Realtime
         ↓
PostgreSQL
   ├─ schema
   ├─ constraints
   ├─ indexes
   └─ RLS policies

SDK 只是 client-side abstraction；真正資料庫規則仍在 Postgres。

2. Web SDK 通常在 Browser runtime

const supabase =
  createClient(
    projectUrl,
    publicClientKey
  );

這段 JavaScript 是 Browser 執行。SDK 不會把 Browser 直接變成 PostgreSQL process。

3. Data API 是 HTTP boundary

因此 Browser Network 能看到 request/response；policy/constraint evidence 則屬資料層。

4. 四個責任不要混

5. Failure layer

Project checkpoint：Course Workspace v1

Browser
  ↓ Supabase client
courses table

course:
  id
  owner_id
  title
  score
  created_at

下一課決定哪些 credentials 可以在 Browser，哪些必須留在 trusted server boundary。

2026 current model：API key、Auth、GRANT、RLS 是四層

現在的 Supabase 要特別避免把「能連到 project」和「能看到某些 rows」混成一件事。API key 先辨識 application component；Auth 建立 user identity；Postgres privilege / GRANT 決定 role 能不能碰 table；RLS 再決定這個 identity 能看到或修改哪些 rows。

Application key
  ↓
Auth identity
  ↓
Table privilege / Data API exposure
  ↓
RLS row policy
  ↓
Constraint / trigger / transaction

因此「table 存在」不代表 Data API 一定可查；「已登入」也不代表所有 rows 一定可見。Debug 時要沿這條 chain 找最早失敗層。