title: Supabase 重大變動：Data API 不再預設公開資料表，開發團隊該如何應對？

---

**Category**

- [AI](https://www.soft4fun.net/category/tech/ai)
- [科技](https://www.soft4fun.net/category/tech)

**Tag**

- [AI 開發](https://www.soft4fun.net/tag/ai-%e9%96%8b%e7%99%bc)
- [RLS](https://www.soft4fun.net/tag/rls)
- [Supabase](https://www.soft4fun.net/tag/supabase)
- [Vibe Codeing](https://www.soft4fun.net/tag/vibe-codeing)

**圖片清單**

- ![supabase-data-api-breaking-change-2026](https://cf.img.soft4fun.net/2026/05/supabase-data-api-breaking-change-2026-scaled.jpg "supabase-data-api-breaking-change-2026")

---

對於許多追求敏捷開發的後端團隊與全端開發者來說，[Supabase](https://www.soft4fun.net/tag/supabase) 憑藉著開箱即用的 Data API 和 PostgreSQL 強大生態系，一直是快速建構產品的首選。然而，為了更嚴謹的資料庫安全，Supabase 近期宣布了一項**破壞性更新 (Breaking Change)**：**未來在 `public` 結構下建立的新資料表，將不再自動透過 Data API 與 GraphQL API 對外公開**。

 

這項改變意味著什麼？Vibe Coding 的用戶或開發團隊又該如何調整現有的工作流？本文將帶您一次看懂。

                   快速導覽           

1. [為什麼 Supabase 要取消「預設�
  �開」？](#為什麼-supabase-要取消-預設�
  �開)
  1. [1. 追求極致的「預設安�
  �」 (Secure by Default)](#1-追求極致的-預設安�
  �-secure-by-default)
  2. [2. 落實基礎設施代碼化 (Infrastructure as Code)](#2-落實基礎設施代碼化-infrastructure-as-code)
2. [這�
  更新對你的專案有什麼影響？](#這�
  更新對你的專案有什麼影響)
  1. [誰會受到影響？](#誰會受到影響)
  2. [誰「不會」受到影響？](#誰-不會-受到影響)
3. [關鍵的退場與生效時間軸](#關鍵的退場與生效時間軸)
4. [開發�
  該如何應對與調整？](#開發�
  該如何應對與調整)
  1. [1. 改變你的「建表起手式」](#1-改變你的-建表起手式)
  2. [2. 現有專案的無痛接軌策略](#2-現有專案的無痛接軌策略)
5. [用一點點不便換來更穩固的資安防線](#用一點點不便換來更穩固的資安防線)

     

## 為什麼 Supabase 要取消「預設公開」？

 

### 1. 追求極致的「預設安全」 (Secure by Default)

 

在過去的預設中，只要你建立了一張新資料表，系統會自動賦予 `anon`、`authenticated` 和 `service_role` 完整的 CRUD（讀寫改刪）權限。這個機制的初衷是為了讓開發者能在客戶端馬上拉取到資料，但也帶來巨大的隱患——如果開發者忘記設定 [RLS](https://www.soft4fun.net/tag/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 開發](https://www.soft4fun.net/tag/ai-%e9%96%8b%e7%99%bc)工具裡面，讓 AI 幫你處理：

 

```
Supabase 即將對資料庫預設權限做出重大更新 (https://github.com/orgs/supabase/discussions/45329)，請掃描系統中資料庫的使用狀況，並使用 plan mode 分析並規劃 migration 步驟。必需取得我的同意才可進行變更。
```

 

## 用一點點不便換來更穩固的資安防線

 

把「預設方便」轉為「預設安全」，短期內確實會增加全端開發者寫 Migration 的手腳功夫，但從長遠的產品生命週期來看，明確的權限宣告能替未來省下無數除錯與防堵漏洞的時間。趕緊檢查專案中的 Migration 腳本，準備迎接更嚴謹的 Supabase 開發時代吧！

  📖 延伸閱讀：AI 為你整理的 5 個重點問題[Q1. 為什麼 Supabase 決定取消資料表「預設公開」的機制？→](https://www.soft4fun.net/tech/supabase-data-api-breaking-change-2026.htm/faq/1)[Q2. 這項更新會影響到哪些開發者？哪些情況則不受影響？→](https://www.soft4fun.net/tech/supabase-data-api-breaking-change-2026.htm/faq/2)[Q3. Supabase 針對這項破壞性更新設定了哪些關鍵的時間節點？→](https://www.soft4fun.net/tech/supabase-data-api-breaking-change-2026.htm/faq/3)[Q4. 在新的規範下，開發者建立資料表並希望透過 API 存取時，應遵循哪些步驟？→](https://www.soft4fun.net/tech/supabase-data-api-breaking-change-2026.htm/faq/4)[Q5. 現有專案的開發者可以採取哪些策略來提早因應這項變革？→](https://www.soft4fun.net/tech/supabase-data-api-breaking-change-2026.htm/faq/5)想知道這些問題的解答嗎？