客製化 SaaS 多租戶架構完整指南：3 種資料隔離模式、5 個踩雷點、3 條成本分歧曲線——中小企業 SaaS 老闆早期分租戶決策的關鍵框架

我們最近在幫一家做雲端排程 SaaS 的客戶做架構盤點時，遇到一個很典型的場景——他們去年用最快的方式把 MVP 推上線、現在每個月增 8 到 12 個客戶，到第 47 個客戶接洽要簽兩年約時，對方法務丟回一條問題：「請說明你們的 multi-tenant 資料隔離模式，是 schema-per-tenant 還是 row-level？」。創辦人愣了三秒，回我們訊息：「等等，這題我不知道怎麼答。」

這不是個案。過去半年我們經手的客製化 SaaS 評估，有八成以上的早期創辦人對「多租戶架構」三個字停在「就是大家共用一個系統」的模糊理解——但實際打開資料庫看，租戶之間的隔離是用 application 層 WHERE tenant_id 過濾，沒有 Row-Level Security、沒有 schema 切分、連備份還原都會把所有客戶資料一起翻出來。等到簽企業客戶、走資安問卷、過 SOC 2，那一刻才發現要砍掉重做的代價是六到九個月研發時間。

這篇要把客製化 SaaS 多租戶架構這道題講清楚——3 種主流隔離模式（單庫共表 + RLS、單庫多 schema、多庫多實例）的取捨點、5 個我們實際在案子裡踩到的雷、3 條成本曲線分歧點怎麼算，以及給中小企業 SaaS 老闆一張早期決策框架。先講結論：根據 AWS SaaS Factory 架構白皮書，多租戶 SaaS 在 50 個客戶以下時三種模式的維運成本差距不大，但跨過 200 客戶後，pool（單庫共表）模式的單客成本可以是 silo（多庫多實例）的 1/8——架構選錯，到 200 客戶那一刻你的毛利會被基礎建設吃掉一半。

先把名詞講清楚：multi-tenant、isolation、tenant-aware 三層概念

「多租戶」這個詞被濫用到很多老闆以為自己懂——但實務上要把三層概念分清楚：租戶模型（multi-tenant 還是 single-tenant）、資料隔離模式（pool / bridge / silo）、資源隔離模式（共用 compute 還是獨立 compute）。同一套 SaaS 可以是「多租戶租戶模型 + silo 資料隔離 + 共用 compute」——這在金融客戶要求資料分庫但又不想付獨立 EC2 的場景很常見。混淆這三層的後果是：跟工程廠商溝通時你說「我要 multi-tenant」，他理解成 pool 模式，結果交付的系統一進金融客戶就過不了資安問卷。

我們的判斷是：中小企業 SaaS 早期（< 100 客戶）幾乎都應該從 bridge（單庫多 schema）起步，pool 模式在後期客戶分層收費時太死、silo 模式在前期成本太貴；bridge 是少數能讓你在「客戶量從 10 漲到 500」這條路上不用砍掉重練的中間解。這跟 Microsoft Azure 的 multi-tenant 指南結論一致——他們把這條叫做「Database-per-tenant」模式，並標註「適用於成長期 SaaS、客戶數中等、需要明確隔離但又想集中維運」。

3 種主流資料隔離模式：pool / bridge / silo 完整對比

以下是我們把 3 種模式整理成的一張對照表，從技術實作、客戶上限、單客邊際成本、合規難度、客戶遷出成本五個維度比較。中小企業 SaaS 老闆挑選型時，把這張表印出來、把自己「未來 18 個月會接的客戶類型」對進去，答案大概就出來了。

Pool 模式：適合 SMB 工具型 SaaS、客戶數要衝量

Pool 的核心是「所有客戶共用同一張表，靠 tenant_id 欄位 + Row-Level Security 區隔」。優點是單客成本可以壓到極低（Notion、Linear 早期都走這條），但缺點是「一筆 SQL 寫錯漏了 WHERE tenant_id」就會跨租戶撈資料——而且這種 bug 通常要到客戶看到別人資料才會爆。實作時務必配 Postgres RLS policy 強制 enforce，不能只靠 ORM 層過濾。

Bridge 模式：成長期最划算、我們的預設推薦

Bridge 是「每個租戶一個 schema、共用一個 DB instance」。優點是 schema 級隔離天然把 tenant_id 寫死、合規容易說、schema migration 可以分批做（先在 5 個 schema 上跑驗證再 rollout 給全體）。缺點是 schema 數量到 500+ 後，PostgreSQL 的 catalog 會開始拖累 query plan——這是我們在實際案子裡到 320 個 schema 那一刻才注意到的拐點，需要做 schema 分群 + 多 DB cluster。

Silo 模式：金融/政府/醫療合規場景、毛利要算清楚

Silo 是「每個租戶一個獨立 DB 甚至獨立 VPC」。物理隔離最強、合規最容易過、但單客邊際成本是 pool 的 8-10 倍。我們建議：除非你的客戶單合約年費 ≥ 50 萬台幣，否則走 silo 模式毛利會被吃掉一半；如果客戶要求 silo 但合約金額撐不起，可以做「silo at DB level + pool at compute level」的折衷——資料庫獨立但 K8s pod 共用。

5 個我們實際踩過的多租戶架構雷點

以下五條是我們陪客戶實際做 SaaS 架構評估時，反覆遇到的踩雷點。每一條的代價都在六位數研發工時起跳——早期決策時把這五條檢查一遍，可以省下後期 80% 的重構成本。

• 雷 1：用 application 層 WHERE 過濾當 isolation。這是「能跑起來但不能上企業客戶」的最大來源——一個 SQL 漏 WHERE 就跨租戶。永遠要配 Postgres RLS / MySQL VIEW 強制，不要相信 ORM。
• 雷 2：認證 token 沒綁 tenant_id。JWT 裡只有 user_id 沒有 tenant_id，導致使用者切換工作區時整個權限模型崩塌。Token 簽發那一刻就要把 tenant 綁進去。
• 雷 3：背景 job 沒帶 tenant context。Celery / Sidekiq queue worker 跑批次時忘了傳 tenant_id，結果 A 客戶的排程 job 去動到 B 客戶的資料。每個 queue message 都要強制塞 tenant_id。
• 雷 4：分析平台共用一張表沒區分。把所有客戶的 event log 倒進同一張 Postgres 表，做客戶儀表板時忘了濾 tenant_id，客戶在自己後台看到別家公司的數據。Event ingestion 必須在 source 就分流。
• 雷 5：備份 / 還原沒按 tenant 切。整庫 dump、整庫 restore——出事要還原單一客戶要花 8 小時 + 影響全平台。早期就要設計 per-tenant export / restore SOP，不然 SLA 寫不出來。

3 條成本分歧曲線：你的 SaaS 在哪一點要重新評估架構

中小企業 SaaS 老闆最常問的問題是「我什麼時候要動架構」——這題不能用直覺答，要看三條曲線。我們把它整理成這張對照：

多租戶 SaaS 架構不要用快速 MVP 的方式賭

多租戶架構是 SaaS 的「基底決策」——MVP 階段可以省的東西很多，但 isolation 這條不能省。我們在客製化 SaaS 接案的前期評估會議裡，永遠把「未來 24 個月會接的客戶類型」放在第一張白板上問：如果有任何一個會走金融 / 醫療 / 政府合規，那 bridge 是最低標、不能走 pool；如果客戶單合約年費 ≥ 50 萬，可以提早規劃 silo at DB level；如果只是 SMB 工具、客戶不會問 SOC 2，pool 模式可以衝量到 500+。架構這題不能補考——選錯要砍掉重練。

想要我們幫你做客製化 SaaS 的多租戶架構評估，可以從 客製化 SaaS 開發服務頁 預約半小時諮詢，我們會帶你把目標客戶類型、合規門檻、客戶量預估走過一遍，給你一張 18 個月的架構升級路徑圖。