Multi-tenant SaaS (jedna platforma SaaS dla wielu klientów)

Salesforce sprzedawał pierwszą komercyjną multi-tenant SaaS w 2000 roku jako alternatywę do on-premise CRM. Od tego czasu multi-tenant stał się standardem ekonomicznym dla SaaS, single-tenant pozostał niszą dla regulowanych branż. W erze AI dyskusja wraca: czy multi-tenant pozwala bezpiecznie hostować modele i dane różnych klientów na jednej infrastrukturze.

Trzy poziomy izolacji

Database-level isolation. Wszyscy klienci w jednej bazie danych, separacja przez tenant_id na każdym rekordzie. Najtańsze, najwydajniejsze, ale ryzyko wycieku przy błędach kodu.

Schema-level isolation. Każdy klient ma osobny schema w tej samej bazie. Lepsza izolacja, gorsza wydajność dla cross-tenant analitytyki (której zwykle nie potrzeba).

Instance-level isolation. Każdy klient ma osobną instancję serwera, osobną bazę, osobny vector store. To single-tenant w czystej formie. Najbezpieczniejsze, najdroższe, niewydajne ekonomicznie poniżej 100 klientów.

W praktyce dojrzałe SaaS stosują hybrydę: kontrole dostępu na poziomie aplikacji, partycjonowanie na poziomie bazy, monitoring na poziomie infrastruktury.

Multi-tenant w kontekście AI

Trzy specyficzne wyzwania, których klasyczne multi-tenant SaaS nie miało.

Vector embeddings cross-tenant leakage. Jeśli embeddings różnych klientów żyją w tym samym vector indexie, źle skonfigurowany retrieval może zwrócić dokumenty klienta A na zapytanie klienta B. Mitigant: namespace izolacja per tenant w vector DB.

Fine-tuned models per tenant. Jeśli model jest fine-tunowany na danych klienta A, należy do klienta A. Multi-tenant model wymaga albo single-base-model plus prompt engineering plus RAG (separacja na poziomie kontekstu), albo per-tenant fine-tuned models (separacja na poziomie modelu, droższa).

Audit trail per tenant. Logi muszą być cięte na tenancie. AI Act wymaga osobnych logów dla każdego klienta korzystającego z systemu wysokiego ryzyka.

Wybór dla polskiej firmy

Decyzja multi-tenant vs single-tenant zależy od trzech czynników. Pierwszy, regulacje: sektor finansowy regulowany (banki, ubezpieczenia) często wymaga single-tenant z polskim hostingiem. Drugi, skala: poniżej 50 klientów multi-tenant nie daje przewagi kosztowej. Trzeci, model przychodów: enterprise sales z high ACV uzasadnia single-tenant.

Dwa nasze produkty wewnętrzne, EXCORE i CBTL, są multi-tenant w 2026, z partition strategy database-level plus namespace vector DB.

Architekturę multi-tenant dla custom platformy klienta projektujemy w ramach Custom platformy, aplikacje, AI.