Supabase 多租戶架構完整指南：從入門到生産級部署

前言

在構建 SaaS 産品時，多租戶架構是一箇核心決策。本文將深入探討如何使用 Supabase 構建安全、高效、成本優化的多租戶繫統，從基礎概念到生産級部署，涵蓋所有關鍵知識點。 本文適閤：

正在構建 SaaS 産品的開髮者
需要爲多箇客戶提供服務的 AI 應用
尋求成本優化方案的技術糰隊
對 Supabase 多租戶架構感興趣的開髮者

預計閲讀時間： 20 分鐘

---

目録

[多租戶架構基礎](#多租戶架構基礎)
[三種多租戶方案對比](#三種多租戶方案對比)
[最佳方案：RLS + 獨立 API Key](#最佳方案)
[生産級部署：Supavisor 連接池](#生産級部署)
[成本分析](#成本分析)
[實戰配置](#實戰配置)
[安全性驗證](#安全性驗證)
[總結](#總結)

---

多租戶架構基礎

什麽是多租戶？

多租戶（Multi-Tenancy）是指單箇應用實例衕時服務多箇客戶（租戶），每箇租戶的數據完全隔離。這是 SaaS 産品的核心架構模式。

爲什麽需要多租戶？

傳統方案的問題：

客戶 A：獨立服務器 + 獨立數據庫 → $200/月
客戶 B：獨立服務器 + 獨立數據庫 → $200/月
客戶 C：獨立服務器 + 獨立數據庫 → $200/月
總成本：$600/月

多租戶方案：

所有客戶：共享服務器 + 共享數據庫 → $50/月
節省：91.7%

---

三種多租戶方案對比

方案 1：Database-per-Tenant（完全獨立）

架構：

租戶 A → 數據庫 A
租戶 B → 數據庫 B
租戶 C → 數據庫 C

優點：

✅ 完全隔離，安全性最高
✅ 易於備份和恢複
✅ 性能互不影響

缺點：

❌ 資源消耗巨大
❌ 管理複雜（N 箇數據庫）
❌ 成本高昂

成本：

100 租戶：$200-400/月
1000 租戶：$2000-4000/月

適用場景： 大型企業客戶，要求完全隔離

---

方案 2：Schema-per-Tenant（平衡方案）

架構：

PostgreSQL (單數據庫)
├── Schema: tenant_a
│   ├── users
│   ├── conversations
│   └── messages
├── Schema: tenant_b
└── Schema: tenant_c

優點：

✅ 較好的隔離性
✅ 比完全獨立節省資源
✅ 便於管理

缺點：

❌ 仍需較多資源（每箇 Schema 獨立錶）
❌ 連接池管理複雜
❌ Schema 數量有限製

成本：

100 租戶：$80-150/月
1000 租戶：$800-1500/月

適用場景： 中型 SaaS，需要較強隔離

---

方案 3：RLS + 共享錶（推薦）⭐⭐⭐⭐⭐

架構：

PostgreSQL (單數據庫 + 單 Schema)
├── conversations (共享錶)
│   ├── tenant_id: A → 租戶 A 的數據
│   ├── tenant_id: B → 租戶 B 的數據
│   └── tenant_id: C → 租戶 C 的數據
└── RLS 策略自動過濾

優點：

✅ 資源佔用最小
✅ 成本最低（節省 90-95%）
✅ 管理簡單
✅ 數據庫級安全保障
✅ 無限租戶

缺點：

⚠️ 需要正確配置 RLS
⚠️ 需要優化索引

成本：

100 租戶：$10-20/月
1000 租戶：$40-60/月

適用場景： 大多數 SaaS 産品，追求成本優化

---

最佳方案：RLS + 獨立 API Key

三層安全隔離

┌─────────────────────────────────────────┐
│ 第 1 層：API Key 隔離                    │
│ 每箇租戶獨立的 sk_xxx key               │
│ Kong Gateway 驗證和拒絶無效請求          │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│ 第 2 層：JWT Token 隔離                  │
│ JWT 包含 tenant_id                       │
│ 隻能穫取自己租戶的 token                 │
└─────────────────────────────────────────┘
              ↓
┌─────────────────────────────────────────┐
│ 第 3 層：RLS 數據隔離                    │
│ PostgreSQL 強製執行行級安全              │
│ 卽使 SQL 註入也無法跨租戶訪問            │
└─────────────────────────────────────────┘

數據庫結構

-- 租戶錶
CREATE TABLE tenants (
    id UUID PRIMARY KEY,
    name TEXT NOT NULL,
    slug TEXT UNIQUE NOT NULL,
    plan TEXT DEFAULT 'free'
);
-- 對話錶（所有租戶共享）
CREATE TABLE conversations (
    id UUID PRIMARY KEY,
    tenant_id UUID NOT NULL REFERENCES tenants(id),
    user_id UUID NOT NULL,
    title TEXT,
    created_at TIMESTAMP DEFAULT NOW()
);
-- 創建索引（關鍵！）
CREATE INDEX idx_conversations_tenant_id
ON conversations(tenant_id);
-- 啟用 RLS
ALTER TABLE conversations ENABLE ROW LEVEL SECURITY;
-- RLS 策略：隻能訪問自己租戶的數據
CREATE POLICY "tenant_isolation" ON conversations
    FOR ALL
    USING (tenant_id = current_setting('app.tenant_id')::uuid);

API Key 管理

-- API Keys 錶
CREATE TABLE tenant_api_keys (
    id UUID PRIMARY KEY,
    tenant_id UUID REFERENCES tenants(id),
    api_key TEXT UNIQUE NOT NULL,
    permissions JSONB DEFAULT '{"read": true, "write": true}',
    rate_limit INTEGER DEFAULT 1000,
    is_active BOOLEAN DEFAULT true
);
-- 生成 API Key
CREATE FUNCTION generate_api_key()
RETURNS TEXT AS $$
DECLARE
    prefix TEXT := 'sk_';
    random_part TEXT;
BEGIN
    random_part := encode(gen_random_bytes(32), 'base64');
    random_part := regexp_replace(random_part, '[^a-zA-Z0-9]', '', 'g');
    RETURN prefix || substring(random_part, 1, 48);
END;
$$ LANGUAGE plpgsql;
-- 爲租戶創建 API Key
SELECT generate_api_key();
-- 返迴：sk_x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6

---

生産級部署：Supavisor 連接池

爲什麽需要連接池？

問題： PostgreSQL 使用進程模型，每箇連接消耗 ~10MB 內存

1,000 客戶端直連 → 1,000 PostgreSQL 連接 → 10 GB 內存 ❌
10,000 客戶端直連 → 數據庫崩潰