Mendesain Skema Database Multi-Tenant: Siloed vs Pooled Architecture

Memilih Pondasi Data untuk Produk SaaS Anda

Ketika membangun platform Software-as-a-Service (SaaS), salah satu keputusan arsitektural yang paling menentukan biaya operasional dan keamanan jangka panjang adalah strategi multi-tenancy.

flowchart TD
    subgraph Siloed["Siloed Architecture"]
        T1["Tenant A"] --> DB1[("Database Dedicated A")]
        T2["Tenant B"] --> DB2[("Database Dedicated B")]
    end
    subgraph Pooled["Pooled Architecture (RLS)"]
        T3["Tenant A"] --> PDB[("Shared Database (tenant_id)")]
        T4["Tenant B"] --> PDB
    end

1. Siloed Architecture (Database Per Tenant)

• Kelebihan: Keamanan data mutlak terisolasi. Jika satu tenant terkena insiden, tenant lain tidak terdampak. Mudah melakukan backup dan migrasi data per klien enterprise.
• Kekurangan: Biaya infrastruktur sangat tinggi dan pemeliharaan skema migrasi untuk ribuan database menjadi mimpi buruk operasional.

2. Pooled Architecture dengan Row Level Security (RLS)

Dengan PostgreSQL RLS, seluruh tenant berbagi satu tabel yang sama, namun engine database secara otomatis menyaring baris berdasarkan sesi tenant yang terotentikasi:

-- Aktifkan RLS pada tabel transaksi
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

-- Buat policy isolasi tenant
CREATE POLICY tenant_isolation_policy ON invoices
  FOR ALL
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

Pendekatan ini memangkas biaya infrastruktur hingga 80% dengan jaminan keamanan level engine tanpa khawatir kebocoran query developer.