Pilihan model data SaaS multi-tenant untuk backend tanpa kode

Masalah: menjaga pemisahan tenant tanpa memperlambat layanan

Multi-tenancy berarti satu produk perangkat lunak melayani banyak pelanggan (tenant), dan setiap tenant hanya boleh melihat data mereka sendiri. Yang sulit adalah melakukan itu secara konsisten: bukan hanya di satu layar, tetapi di setiap panggilan API, panel admin, ekspor, dan pekerjaan latar belakang.

Model data Anda memengaruhi operasi sehari-hari lebih dari yang banyak tim duga. Ia membentuk izin, pelaporan, kecepatan kueri saat Anda tumbuh, dan seberapa berisiko sebuah bug "kecil" bisa menjadi. Lewatkan satu filter dan Anda bisa membocorkan data. Mengisolasi terlalu agresif dan pelaporan berubah jadi pekerjaan yang merepotkan.

Ada tiga cara umum untuk menyusun model data SaaS multi-tenant:

• Satu database di mana setiap tabel menyertakan tenant_id
• Skema terpisah per tenant di dalam satu database
• Database terpisah per tenant

Bahkan jika Anda membangun secara visual di backend tanpa kode, tradeoff yang sama berlaku. Alat seperti AppMaster menghasilkan kode backend dan struktur database nyata dari desain Anda, jadi keputusan pemodelan awal cepat terlihat dalam perilaku dan performa produksi.

Bayangkan sebuah alat helpdesk. Jika setiap baris tiket punya tenant_id, mudah untuk menanyakan “semua tiket terbuka,” tetapi Anda harus menegakkan pengecekan tenant di mana-mana. Jika setiap tenant punya skema atau database sendiri, isolasi lebih kuat secara default, tetapi pelaporan lintas-tenant (mis. “rata-rata waktu penutupan di semua pelanggan”) menjadi lebih rumit.

Tujuannya adalah pemisahan yang dapat Anda percayai tanpa menambah hambatan pada pelaporan, dukungan, dan pertumbuhan.

Cara cepat memilih: 4 pertanyaan yang mempersempit pilihan

Jangan mulai dari teori database. Mulai dari bagaimana produk akan digunakan dan apa yang Anda perlukan untuk mengoperasikannya setiap minggu.

Empat pertanyaan yang biasanya membuat jawabannya jelas

1. Seberapa sensitif datanya, dan apakah Anda berada di bawah aturan ketat? Kesehatan, keuangan, dan kontrak pelanggan yang ketat sering mendorong Anda ke isolasi yang lebih kuat (skema terpisah atau database terpisah). Ini bisa mengurangi risiko dan mempermudah audit.

2. Apakah Anda sering membutuhkan pelaporan lintas-tenant? Jika Anda secara rutin membutuhkan metrik “semua pelanggan” (penggunaan, pendapatan, performa), satu database dengan tenant_id biasanya yang paling sederhana. Database terpisah membuat ini lebih sulit karena Anda harus menanyakan banyak tempat dan menggabungkan hasil.

3. Seberapa berbeda tenant satu sama lain? Jika tenant memerlukan field kustom, alur kerja kustom, atau integrasi unik, skema atau database terpisah dapat mengurangi kemungkinan perubahan bocor ke tenant lain. Jika sebagian besar tenant berbagi struktur yang sama, tenant_id tetap rapi.

4. Apa yang tim Anda realistis dapat operasikan? Isolasi yang lebih besar biasanya berarti lebih banyak pekerjaan: lebih banyak backup, lebih banyak migrasi, lebih banyak bagian yang bergerak, dan lebih banyak tempat bagi kegagalan untuk bersembunyi.

Pendekatan praktis adalah membuat prototipe dua pilihan teratas Anda, lalu menguji titik-titik nyeri nyata: aturan izin, kueri pelaporan, dan bagaimana perubahan diluncurkan saat model berkembang.

Pendekatan 1: satu database dengan tenant_id di setiap baris

Ini adalah setup yang paling umum: semua pelanggan berbagi tabel yang sama, dan setiap record milik tenant membawa tenant_id. Dari sisi operasional sederhana karena Anda menjalankan satu database dan satu set migrasi.

Aturannya ketat: jika sebuah baris milik tenant, baris itu harus menyertakan tenant_id, dan setiap kueri harus memfilternya. Tabel yang dimiliki tenant biasanya meliputi users, roles, projects, tickets, invoices, messages, metadata file, dan tabel join yang menghubungkan data tenant.

Untuk mengurangi kebocoran, perlakukan tenant_id sebagai hal yang tidak bisa dinegosiasikan:

• Jadikan tenant_id required (NOT NULL) pada tabel milik tenant
• Tambahkan index yang dimulai dengan tenant_id (misalnya, tenant_id, created_at)
• Buat aturan unik menyertakan tenant_id (seperti email unik per tenant)
• Lewatkan tenant_id ke setiap API dan alur bisnis, bukan hanya form UI
• Tegakkan di backend, bukan hanya filter sisi klien

Di PostgreSQL, kebijakan row-level security bisa menambah jaring pengaman yang kuat, terutama ketika kueri dibuat secara dinamis.

Data referensi biasanya jatuh ke salah satu dari dua kelompok: tabel bersama (seperti countries) tanpa tenant_id, dan katalog yang berskala tenant (seperti tag kustom atau pipeline) yang menyertakan tenant_id.

Jika Anda membangun dengan AppMaster, kebiasaan sederhana mencegah sebagian besar insiden: set tenant_id dari tenant pengguna yang terautentikasi sebelum operasi create atau read dalam logika Business Process Anda, dan pertahankan pola itu konsisten.

Dampak pada izin: apa yang berubah dengan tiap pendekatan

Izin adalah tempat multi-tenancy berhasil atau gagal. Tata letak data yang Anda pilih mengubah cara Anda menyimpan users, cara memfilter query, dan cara menghindari momen “oops” di layar admin.

Dengan satu database dan tenant_id pada setiap baris, tim sering menggunakan satu tabel Users bersama dan menghubungkan setiap user ke sebuah tenant dan satu atau lebih peran. Aturan besarnya tetap sama: setiap read dan write harus menyertakan scope tenant, bahkan untuk tabel “kecil” seperti settings, tags, atau logs.

Dengan skema terpisah, Anda sering menyimpan layer identitas bersama (login, password, MFA) di satu tempat, sementara data tenant hidup di skema per tenant. Izin menjadi sebagian masalah routing: aplikasi harus mengarahkan query ke skema yang benar sebelum logika bisnis dijalankan.

Dengan database terpisah, isolasi paling kuat, tetapi logika izin bergeser ke infrastruktur: memilih koneksi database yang tepat, mengelola kredensial, dan menangani akun staf “global”.

Di ketiga pendekatan, beberapa pola konsisten mengurangi risiko lintas-tenant:

• Masukkan tenant_id ke dalam session atau klaim token auth dan anggap itu wajib.
• Sentralisasikan pengecekan tenant di satu tempat (middleware atau Business Process bersama), jangan menyebarkannya di berbagai endpoint.
• Di alat admin, tampilkan konteks tenant dengan jelas dan minta pergantian tenant yang eksplisit.
• Untuk akses support, gunakan impersonation dengan log audit.

Di AppMaster, ini biasanya berarti menyimpan konteks tenant segera setelah autentikasi dan menggunakannya kembali di endpoint API dan Business Processes sehingga setiap kueri tetap ter-scope. Agen support hanya boleh melihat order setelah aplikasi menyetel konteks tenant, bukan karena UI kebetulan memfilter dengan benar.

Pelaporan dan performa dengan model tenant_id

Dengan pendekatan single-database tenant_id, pelaporan biasanya sederhana. Dashboard global (MRR, signup, penggunaan) bisa menjalankan satu kueri untuk semua, dan laporan tingkat-tenant adalah kueri yang sama dengan filter.

Tradeoff-nya adalah performa seiring waktu. Saat tabel tumbuh, satu tenant yang sibuk bisa menjadi noisy neighbor dengan menciptakan lebih banyak baris, memicu lebih banyak penulisan, dan membuat kueri umum lebih lambat jika database harus memindai terlalu banyak data.

Indexing menjaga model ini sehat. Sebagian besar pembacaan yang berskala tenant harus bisa menggunakan index yang dimulai dengan tenant_id, sehingga database bisa langsung ke irisan data tenant tersebut.

Baseline yang baik:

• Tambahkan composite index dengan tenant_id sebagai kolom pertama (misalnya, tenant_id + created_at, tenant_id + status, tenant_id + user_id)
• Pertahankan index global hanya jika Anda benar-benar membutuhkan kueri lintas-tenant
• Waspadai join dan filter yang “lupa” tenant_id, yang bisa menyebabkan pemindaian lambat

Retention dan penghapusan juga perlu rencana karena riwayat satu tenant bisa membengkakkan tabel untuk semua orang. Jika tenant punya kebijakan retensi berbeda, pertimbangkan soft deletes plus pengarsipan terjadwal per tenant, atau memindahkan baris lama ke tabel arsip yang diberi key tenant_id.

Pendekatan 2: skema terpisah per tenant

Dengan skema terpisah, Anda masih menggunakan satu database PostgreSQL, tetapi setiap tenant mendapat skema sendiri (misalnya tenant_42). Tabel di dalam skema itu hanya milik tenant tersebut. Rasanya seperti memberi setiap pelanggan “mini database”, tanpa overhead menjalankan banyak database.

Setup umum menyimpan layanan global di skema bersama dan data tenant di skema tenant. Pemisahan biasanya tentang apa yang harus dibagikan antar pelanggan versus apa yang tidak boleh bercampur.

Pembagian tipikal:

• Skema bersama: tabel tenants, plans, catatan tagihan, feature flags, pengaturan audit
• Skema tenant: tabel bisnis seperti orders, tickets, inventory, projects, field kustom
• Sisi mana pun (bergantung produk): users dan roles, terutama jika user bisa mengakses beberapa tenant

Model ini mengurangi risiko join lintas-tenant karena tabel berada di namespace berbeda. Ini juga bisa mempermudah backup atau restore satu tenant dengan menargetkan satu skema.

Yang mengejutkan tim adalah migrasi. Saat Anda menambahkan tabel atau kolom baru, Anda harus menerapkan perubahan ke setiap skema tenant. Dengan 10 tenant mudah diatur. Dengan 1.000, Anda perlu proses: lacak versi skema, jalankan migrasi secara batch, dan gagal dengan aman sehingga satu tenant rusak tidak memblokir yang lain.

Layanan bersama seperti auth dan billing biasanya hidup di luar skema tenant. Pola praktis adalah auth bersama (satu tabel user dengan tabel keanggotaan tenant) dan billing bersama (ID pelanggan Stripe, invoice), sementara skema tenant menyimpan data bisnis milik tenant.

Jika Anda menggunakan AppMaster, rencanakan sejak awal bagaimana model Data Designer memetakan ke skema bersama vs tenant, dan jaga layanan global stabil sehingga skema tenant bisa berkembang tanpa merusak login atau pembayaran.

Pelaporan dan performa dengan skema terpisah

Skema terpisah memberikan pemisahan yang lebih kuat secara default daripada model murni tenant_id karena tabel secara fisik terpisah dan izin dapat disetel per skema.

Pelaporan bagus ketika sebagian besar laporan bersifat per-tenant. Kueri tetap sederhana karena Anda membaca dari tabel tenant tanpa terus-menerus memfilter tabel bersama. Model ini juga mendukung tenant “spesial” yang membutuhkan tabel ekstra atau kolom kustom tanpa memaksa semua orang lain membawa perubahan itu.

Pelaporan agregat lintas-tenant adalah tempat skema mulai menyulitkan. Anda harus memiliki lapisan pelaporan yang bisa menanyakan banyak skema, atau mempertahankan tabel ringkasan bersama di skema umum.

Pola umum:

• Dashboard per-tenant yang hanya query ke skema tenant tersebut
• Skema analytics pusat dengan rollup malam dari masing-masing tenant
• Job ekspor yang menyalin data tenant ke format yang ramah data warehouse

Performa biasanya solid untuk beban kerja tingkat tenant. Index lebih kecil per tenant, dan penulisan berat di satu skema cenderung tidak memengaruhi yang lain. Tradeoff-nya adalah overhead operasional: provisioning tenant baru berarti membuat skema, menjalankan migrasi, dan menjaga setiap skema selaras saat model berubah.

Skema cocok ketika Anda menginginkan isolasi lebih ketat tanpa biaya banyak database, atau ketika Anda mengharapkan kustomisasi per-tenant.

Pendekatan 3: database terpisah per tenant

Dengan database terpisah per tenant, setiap pelanggan mendapat database sendiri (atau database mereka sendiri di server yang sama). Ini opsi paling terisolasi: jika data satu tenant korup atau miskonfigurasi, kecil kemungkinannya menyebar ke tenant lain.

Cocok untuk lingkungan yang teregulasi (kesehatan, keuangan, pemerintahan) atau pelanggan enterprise yang mengharapkan pemisahan ketat, aturan retensi kustom, atau performa khusus.

Onboarding menjadi workflow provisioning. Saat tenant baru mendaftar, sistem Anda perlu membuat atau mengkloning database, menerapkan skema dasar (tabel, index, constraint), membuat dan menyimpan kredensial dengan aman, dan merutekan request API ke database yang tepat.

Jika Anda membangun dengan AppMaster, pilihan desain kuncinya adalah di mana menyimpan direktori tenant (peta pusat tenant ke koneksi database) dan bagaimana memastikan setiap request menggunakan koneksi yang benar.

Upgrade dan migrasi adalah tradeoff utama. Perubahan skema bukan lagi “jalankan sekali”, melainkan “jalankan untuk setiap tenant.” Itu menambah pekerjaan operasional dan risiko, sehingga tim sering memberi versi skema dan menjalankan migrasi sebagai job terkontrol yang melacak progres per tenant.

Keuntungannya adalah kontrol. Anda bisa migrasi tenant besar dulu, mengawasi performa, lalu gulirkan perubahan secara bertahap.

Pelaporan dan performa dengan database terpisah

Database terpisah paling mudah dijelaskan. Pembacaan lintas-tenant yang tidak sengaja jauh lebih kecil kemungkinannya terjadi, dan kesalahan izin cenderung hanya memengaruhi satu tenant.

Performa juga menjadi kekuatan. Kueri berat, impor besar, atau laporan runaway di Tenant A tidak akan memperlambat Tenant B. Ini proteksi kuat terhadap noisy neighbors, dan memungkinkan penyesuaian sumber daya per tenant.

Tradeoff muncul di pelaporan. Analitik global menjadi tersulit karena data terpisah secara fisik. Pola yang umum berhasil di praktik meliputi menyalin event kunci atau tabel ke database pelaporan pusat, mengirim event ke dataset bergaya warehouse, menjalankan laporan per-tenant dan mengagregasi hasil (ketika jumlah tenant kecil), dan memisahkan metrik produk dari data pelanggan.

Biaya operasional adalah faktor besar lainnya. Lebih banyak database berarti lebih banyak backup, upgrade, monitoring, dan respons insiden. Anda juga bisa cepat menemui batas koneksi karena setiap tenant mungkin perlu pool koneksi sendiri.

Kesalahan umum yang menyebabkan kebocoran data atau masalah di kemudian hari

Sebagian besar masalah multi-tenant bukanlah kegagalan desain besar. Mereka adalah kelalaian kecil yang berkembang menjadi bug keamanan, pelaporan yang berantakan, dan pembersihan yang mahal. Multi-tenancy berhasil ketika pemisahan tenant diperlakukan sebagai kebiasaan, bukan fitur yang dipasang di kemudian hari.

Kebocoran umum adalah lupa menambahkan field tenant pada satu tabel, terutama tabel join seperti user_roles, invoice_items, atau tags. Semua tampak baik-baik saja sampai laporan atau pencarian melakukan join melalui tabel itu dan menarik baris dari tenant lain.

Masalah lain sering kali adalah dashboard admin yang melewati filter tenant. Sering dimulai sebagai “hanya untuk support,” lalu digunakan kembali. Alat tanpa kode tidak mengubah risiko ini: setiap query, business process, dan endpoint yang membaca data tenant membutuhkan scope tenant yang sama.

ID juga bisa menjebak. Jika Anda berbagi ID yang mudah dibaca antar tenant (seperti order_number = 1001) dan berasumsi mereka unik secara global, alat support dan integrasi akan mencampur record. Jaga identifier yang berskala tenant terpisah dari primary key internal, dan sertakan konteks tenant dalam lookup.

Akhirnya, tim meremehkan migrasi dan backup saat mereka skala. Yang mudah di 10 tenant bisa lambat dan berisiko di 1.000.

Pemeriksaan cepat yang mencegah sebagian besar masalah:

• Buat kepemilikan tenant eksplisit pada setiap tabel, termasuk tabel join.
• Gunakan satu pola scoping tenant dan pakai ulang di mana-mana.
• Pastikan laporan dan ekspor tidak dapat dijalankan tanpa scope tenant (kecuali memang global).
• Hindari identifier ambigu tenant di API dan alat support.
• Latih langkah restore dan migrasi lebih awal, bukan setelah pertumbuhan.

Contoh: agen support mencari “invoice 1001” dan menarik tenant yang salah karena lookup melewatkan scope tenant. Ini bug kecil dengan dampak besar.

Daftar periksa cepat sebelum Anda menetapkan pilihan

Sebelum Anda mengunci model data multi-tenant, jalankan beberapa tes. Tujuannya adalah menangkap kebocoran data sejak awal dan mengonfirmasi pilihan Anda tetap bekerja saat tabel membesar.

Pemeriksaan cepat yang bisa Anda lakukan dalam sehari

• Bukti isolasi data: buat dua tenant (A dan B), tambahkan record serupa, lalu verifikasi setiap read dan update ter-scope ke tenant aktif. Jangan mengandalkan hanya filter UI.
• Tes pelanggaran izin: masuk sebagai user Tenant A dan coba buka, edit, atau hapus record Tenant B hanya dengan mengubah ID record. Jika ada yang sukses, anggap itu blocker rilis.
• Keamanan jalur tulis: konfirmasi record baru selalu mendapatkan nilai tenant yang benar (atau mendarat di skema/database yang benar), bahkan saat dibuat lewat background job, import, atau otomasi.
• Uji pelaporan: pastikan Anda bisa melakukan pelaporan khusus tenant dan pelaporan “semua tenant” (untuk staf internal), dengan aturan jelas siapa yang boleh melihat tampilan global.
• Cek performa: tambahkan strategi index sekarang (khususnya untuk (tenant_id, created_at) dan filter umum lain), dan ukur setidaknya satu kueri lambat dengan sengaja sehingga Anda tahu seperti apa kondisi "buruk".

Untuk membuat uji pelaporan konkret, pilih dua pertanyaan yang Anda tahu akan diperlukan (satu tenant-scoped, satu global) dan jalankan terhadap data sampel.

-- Tenant-only: last 30 days, one tenant
SELECT count(*)
FROM tickets
WHERE tenant_id = :tenant_id
  AND created_at >= now() - interval '30 days';

-- Global (admin): compare tenants
SELECT tenant_id, count(*)
FROM tickets
WHERE created_at >= now() - interval '30 days'
GROUP BY tenant_id;

Jika Anda membuat prototipe di AppMaster, bangun pemeriksaan ini ke dalam alur Business Process Anda (read, write, delete), dan isi dua tenant di Data Designer. Ketika tes ini lulus dengan volume data realistis, Anda bisa melangkah dengan percaya diri.

Skenario contoh: dari pelanggan pertama hingga skala

Perusahaan berukuran 20 orang meluncurkan portal pelanggan untuk kliennya: invoices, tickets, dan dashboard sederhana. Mereka mengharapkan 10 tenant di bulan pertama, dengan rencana tumbuh ke 1.000 dalam setahun.

Di awal, model paling sederhana biasanya satu database dengan setiap tabel yang menyimpan data pelanggan menyertakan tenant_id. Ini cepat dibangun, mudah dilaporkan, dan menghindari setup yang duplikat.

Dengan 10 tenant, risiko terbesar bukan performa. Itu adalah izin. Satu filter yang terlewat (misalnya, query “list invoices” yang lupa tenant_id) bisa membocorkan data. Tim harus menegakkan pengecekan tenant di satu tempat konsisten (business logic bersama atau pola API yang dapat digunakan ulang) dan menganggap scoping tenant tidak bisa dinegosiasikan.

Saat mereka bergerak dari 10 ke 1.000 tenant, kebutuhan berubah. Pelaporan menjadi lebih berat, support meminta “ekspor semua untuk tenant ini,” dan beberapa tenant besar mulai mendominasi lalu lintas dan memperlambat tabel bersama.

Jalur upgrade praktis sering terlihat seperti ini:

1. Pertahankan logika aplikasi dan aturan izin yang sama, tetapi pindahkan tenant ber-volume tinggi ke skema terpisah.
2. Untuk tenant terbesar (atau klien kepatuhan ketat), pindahkan mereka ke database terpisah.
3. Pertahankan lapisan pelaporan bersama yang membaca dari semua tenant, dan jadwalkan laporan berat di luar jam sibuk.

Pilih model paling sederhana yang menjaga data aman hari ini, lalu rencanakan jalur migrasi untuk masalah “beberapa tenant besar” daripada mengoptimalkan untuk itu sejak hari pertama.

Langkah selanjutnya: pilih model dan buat prototipe di backend tanpa kode

Pilih berdasarkan apa yang perlu Anda lindungi terlebih dulu: isolasi data, kesederhanaan operasional, atau skala per-tenant. Keyakinan datang dari membangun prototipe kecil dan berusaha merusaknya dengan kasus izin dan pelaporan nyata.

Panduan mulai sederhana:

• Jika sebagian besar tenant kecil dan Anda membutuhkan pelaporan lintas-tenant yang sederhana, mulai dengan satu database dan tenant_id pada setiap baris.
• Jika Anda membutuhkan pemisahan lebih kuat namun tetap ingin satu database untuk dikelola, pertimbangkan skema terpisah per tenant.
• Jika tenant menuntut isolasi keras (kepatuhan, backup khusus, risiko noisy-neighbor), pertimbangkan database terpisah per tenant.

Sebelum membangun, tulis batas tenant dalam bahasa sehari-hari. Definisikan peran (owner, admin, agent, viewer), apa yang bisa dilakukan tiap peran, dan apa arti data “global” (plans, templates, audit logs). Putuskan bagaimana pelaporan harus bekerja: hanya per-tenant, atau "semua tenant" untuk staf internal.

Jika Anda menggunakan AppMaster, Anda bisa membuat prototipe pola ini dengan cepat: modelkan tabel di Data Designer (termasuk tenant_id, constraint unik, dan index yang dibutuhkan kueri Anda), lalu tegakkan aturan di Business Process Editor sehingga setiap baca dan tulis tetap ter-scope tenant. Jika Anda ingin titik acuan untuk platform, AppMaster tersedia di appmaster.io.

Tes akhir yang praktis: buat dua tenant (A dan B), tambahkan users dan orders serupa, dan jalankan alur yang sama untuk keduanya. Coba ekspor laporan untuk tenant A, lalu sengaja kirim ID tenant B ke endpoint yang sama. Prototipe Anda hanya “aman cukup” ketika upaya tersebut selalu gagal dan laporan kunci Anda tetap cepat dengan ukuran data realistis.