Arsitektur Multi-Tenant PostgreSQL: RLS vs Schema SaaS

Tepat pukul 08.00 WIB saat ujian serentak tingkat nasional dimulai, ribuan sekolah mengakses platform Software-as-a-Service (SaaS) EduTech secara bersamaan. Dalam hitungan detik, lonjakan kueri SQL memukul basis data utama, CPU server melonjak hingga 100%, dan latensi membengkak dari 15 milidetik menjadi timeout 2.400 ms. Lebih mengerikan lagi, kebocoran data antar-sekolah mengintai jika logika isolasi tenant di tingkat aplikasi mengalami bug. Bagi engineering lead, kondisi krisis ini membuka dilema mendasar: bagaimana merancang Arsitektur Multi-Tenant EduTech yang sanggup mengisolasi data secara absolut tanpa memicu pembengkakan biaya infrastruktur yang tak terkendali?

Ketika membangun sistem EduTech skala menengah hingga besar, evaluasi pola arsitektur Modular Monolith sering kali menjadi langkah awal sebelum membedah batas-batas isolasi pada storage layer. Dalam ekosistem PostgreSQL, perdebatan utama berpusat pada dua strategi dominan: Row-Level Security (RLS) dan Schema-per-Tenant. Masing-masing opsi membawa trade-off nyata antara efisiensi sumber daya, kompleksitas operasional, dan garansi isolasi keamanan.

Membedah Model Isolasi Data: RLS vs Schema-per-Tenant

Pada model Row-Level Security (RLS), seluruh tenant berbagi tabel dan skema database yang sama (public). Pemisahan data dipaksakan langsung oleh engine PostgreSQL melalui kebijakan (policy) yang memeriksa variabel sesi seperti app.current_tenant_id. Kebijakan ini mengeksekusi filter otomatis pada setiap kueri SELECT, UPDATE, dan DELETE tanpa mengandalkan klausa WHERE manual di kode aplikasi.

Sebaliknya, Schema-per-Tenant mengisolasi setiap lembaga pendidikan ke dalam skema PostgreSQL terpisah dalam satu basis data yang sama. Jalur akses data dikontrol melalui search_path. Model ini mengeliminasi risiko kebocoran data akibat kelalaian koding kueri, namun memperkenalkan overhead metadata yang signifikan ketika jumlah sekolah berkembang melampaui ribuan tenant.

Analisis Dampak Resource Overhead dan Connection Pooling

Penggunaan Schema-per-Tenant dalam skala besar menderita problem catalog bloat. Ketika jumlah skema mencapai 2.000 dengan 40 tabel per skema, PostgreSQL harus mengelola 80.000 relasi di dalam catalog pg_class. Hal ini menguras shared buffers dan meningkatkan konsumsi RAM shared catalog cache hingga 2.4 GB hanya untuk menyimpan metadata relasi. Selain itu, migrasi DDL (ALTER TABLE) pada 2.000 skema membutuhkan waktu eksekusi hingga 45 menit dan mengunci relasi secara sekuensial.

Pada model RLS, migrasi DDL hanya berjalan sekali pada satu tabel terintegrasi. Namun, RLS memiliki kompleksitas pada connection pooling. Saat menggunakan PgBouncer dengan mode transaction pooling, penggunaan SET LOCAL app.current_tenant_id = 'uuid' wajib dilakukan di dalam setiap transaksi agar variabel sesi tidak bocor ke koneksi lain yang digunakan oleh tenant berbeda.

• Konsumsi Memory Catalog (pg_class) — Row-Level Security (RLS) Shared Schema: Sangat Rendah (< 50 MB untuk 10.000 tenant) | Schema-per-Tenant (Isolated Schemas): Sangat Tinggi (> 2 GB pada 2.000 tenant)
• Durasi Migrasi Schema (DDL 1000 Tenant) — Row-Level Security (RLS) Shared Schema: Fast (< 3 Detik, Single Migration) | Schema-per-Tenant (Isolated Schemas): Slow (15–45 Menit, Loop Execution)
• Risiko Kebocoran Data (Human Error) — Row-Level Security (RLS) Shared Schema: Sedang (Tergantung ketepatan RLS Policy & Session) | Schema-per-Tenant (Isolated Schemas): Sangat Rendah (Isolasi namespace via search_path)
• Kompabilitas PgBouncer Transaction Mode — Row-Level Security (RLS) Shared Schema: Perlu SET LOCAL transaksi ketat | Schema-per-Tenant (Isolated Schemas): Membutuhkan reset search_path per transaksi
• Batas Esktensibilitas (Tenant Capacity) — Row-Level Security (RLS) Shared Schema: > 100.000 Tenant per Cluster | Schema-per-Tenant (Isolated Schemas): ~2.500 Tenant per Cluster (Catalog Bottleneck)

Strategi Hybrid dan Pengelolaan Infrastruktur Engine

Untuk mengatasi kendala ini, tim engineering skala enterprise sering menerapkan pendekatan hibrida: sekolah standar (tipe K-12/Warung SaaS) dialokasikan ke dalam tabel shared bertenaga RLS, sedangkan kampus besar atau instansi pemerintah dengan kebutuhan audit khusus ditempatkan pada skema terisolasi dedicated.

Pengelolaan basis data berbeban tinggi ini menuntut kestabilitas compute IOPS dan latensi disk yang konsisten. Menjalankan kluster PostgreSQL dengan PgBouncer dan pemantauan kueri pg_stat_statements membutuhkan fondasi infrastruktur VPS yang transparan tanpa oversubscription. Penggunaan infrastruktur Hostinger KVM VPS berbasis storage NVMe memberikan fleksibilitas root access penuh untuk mengonfigurasi parameter shared_buffers = 4GB, work_mem = 64MB, serta max_worker_processes yang optimal saat memproses spike kueri ujian simultan.

Infrastruktur di atas mendukung skalabilitas proses operasional jangka panjang.

Checklist Implementasi Operasional Multi-Tenant

Sebelum meluncurkan arsitektur multi-tenant ke lingkungan produksi, pastikan seluruh item validasi teknis berikut telah dipenuhi:

1. Uji Kebocoran RLS via Integration Test: Jalankan pengujian automated testsuite dengan dua session context berbeda secara bersamaan untuk memastikan kueri tenant A mengembalikan 0 rows saat mengakses ID tenant B.
2. Terapkan SET LOCAL pada Middleware: Pastikan objek ORM atau query builder selalu mengeksekusi SET LOCAL app.current_tenant_id di dalam blok transaksi SQL yang sama sebelum kueri utama dijalankan.
3. Batasi Hak Akses PostgreSQL User: Pastikan database user yang digunakan oleh aplikasi web tidak memiliki peran SUPERUSER atau hak BYPASSRLS, karena role tersebut secara otomatis mengabaikan aturan RLS.
4. Monitor PostgreSQL Catalog Bloat: Pasang alert Promethean jika jumlah tuple pada pg_class atau ukuran shared catalog cache melampaui 15% dari total allocated RAM server.
5. Otomatisasi Isolation Indexing: Buat indeks komposit (tenant_id, primary_key) pada setiap tabel shared untuk menjamin index scan tidak membaca data tenant lain.

Transparansi: Beberapa tautan di artikel ini adalah tautan afiliasi yang dapat memberikan komisi bagi kami tanpa biaya tambahan bagi Anda.