對於許多追求敏捷開發的後端團隊與全端開發者來說，Supabase 憑藉著開箱即用的 Data API 和 PostgreSQL 強大生態系，一直是快速建構產品的首選。然而，為了更嚴謹的資料庫安全，Supabase 近期宣布了一項破壞性更新 (Breaking Change)：未來在 public 結構下建立的新資料表，將不再自動透過 Data API 與 GraphQL API 對外公開。
這項改變意味著什麼？Vibe Coding 的用戶或開發團隊又該如何調整現有的工作流？本文將帶您一次看懂。
為什麼 Supabase 要取消「預設公開」？
1. 追求極致的「預設安全」 (Secure by Default)
在過去的預設中，只要你建立了一張新資料表，系統會自動賦予 anon、authenticated 和 service_role 完整的 CRUD（讀寫改刪）權限。這個機制的初衷是為了讓開發者能在客戶端馬上拉取到資料，但也帶來巨大的隱患——如果開發者忘記設定 RLS (Row Level Security)，這張資料表就會變成駭客的免費提款機。
隨著越來越多透過 CLI 腳本、自動化流程甚至是 AI 寫碼工具 (如 GitHub Copilot、Cursor) 建立的資料表產生，這些操作往往缺乏人類開發者的二次審查。取消自動公開，能從根本上杜絕「忘記上鎖」的資安悲劇。
2. 落實基礎設施代碼化 (Infrastructure as Code)
未來的存取控制將完全依賴明確的 PostgreSQL GRANT 聲明。這種做法讓權限控管變成可被搜尋 (Greppable)、可被差異比對 (Diffable) 的程式碼。對於團隊協作與版本控制來說，這是邁向企業級架構的重要一步。
這項更新對你的專案有什麼影響？
誰會受到影響？
如果你的應用程式符合以下條件，就必須採取行動：
- 透過 Data API（包含 PostgREST、GraphQL、
supabase-js或其他官方 Client Library）讀寫public中的資料表。 - 你使用的資料庫遷移腳本 (Migrations) 或部署流程中，建表時沒有明確寫出
GRANT聲明。 - 依賴 AI 工具或 CLI 自動建表，且預期它們一建好就能直接被 API 呼叫。
誰「不會」受到影響？
如果你的後端架構是透過直接連接 PostgreSQL（例如使用 Prisma、Drizzle 等 ORM 工具，或是透過連接字串直連），這項針對 Data API 曝光層的更新完全不會影響你。此外，原有的 storage、auth 與 realtime 等內建結構的行為維持不變。
關鍵的退場與生效時間軸
Supabase 採取了分段式的溫和退場機制，但時間已迫在眉睫：
- 2026 年 4 月 28 日：已在建立專案介面新增「是否自動曝光新資料表」的勾選選項供開發者先行適應。
- 2026 年 5 月 30 日：所有「新建立」的專案預設套用新制。新資料表不再自動曝光。
- 2026 年 10 月 30 日：強制擴及所有「現有專案」。在這個日期之後，即使是舊專案，新建的資料表若無明確
GRANT，API 將無法存取。（請放心，現有已經存在且運作中的資料表權限不會被更動）。
開發者該如何應對與調整？
1. 改變你的「建表起手式」
未來建立資料表並希望透過 API 提供存取時，請務必將以下三個步驟視為一個不可分割的整體：
- 建立明確權限 (Grant)： 賦予不同角色相對應的權限。例如：
grant select, insert, update, delete on public.your_table to authenticated;- 啟用 RLS (Row Level Security)：
alter table public.your_table enable row level security;- 新增存取策略 (Policy)： 寫下具體的商業邏輯規則。
值得一提的是，Supabase 針對缺失權限的情境優化了錯誤訊息。如果忘記 GRANT，API 會回傳帶有具體修復語法（Hint）的錯誤提示，這讓 AI 代理能夠自動判讀並自我修正：
{
"code": "42501",
"message": "permission denied for table your_table",
"hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}2. 現有專案的無痛接軌策略
如果你想在 10 月 30 日大限前，提早在現有專案套用這項高標準的安全規範，可以直接在 Supabase SQL Editor 執行官方提供的 revoke 語法，撤銷 postgres 角色對未來物件的預設權限賦予。這不會弄壞你正在運作的系統，但能確保未來的每一次建表都經過嚴格的權限檢驗。
或者你可以將以下 Prompt 貼到 Claude Code、Codex、Antigravity 或 Cursor 等 AI 開發工具裡面，讓 AI 幫你處理：
Supabase 即將對資料庫預設權限做出重大更新 (https://github.com/orgs/supabase/discussions/45329)，請掃描系統中資料庫的使用狀況，並使用 plan mode 分析並規劃 migration 步驟。必需取得我的同意才可進行變更。用一點點不便換來更穩固的資安防線
把「預設方便」轉為「預設安全」，短期內確實會增加全端開發者寫 Migration 的手腳功夫，但從長遠的產品生命週期來看，明確的權限宣告能替未來省下無數除錯與防堵漏洞的時間。趕緊檢查專案中的 Migration 腳本，準備迎接更嚴謹的 Supabase 開發時代吧！
