Multi-tenant — co to jest i jak wybrać architekturę SaaS dla wielu klientów

Kiedy planujesz produkt SaaS, jedna z pierwszych decyzji architektonicznych brzmi niewinnie: czy każdy klient dostaje własną kopię aplikacji i bazy danych, czy wszyscy korzystają z jednej, wspólnej? Ta druga odpowiedź to multi-tenant (pisane też „multi tenant” albo „multitenancy”, po polsku: wielodzierżawczość). Od tej decyzji zależy, ile zapłacisz za infrastrukturę, jak szybko wdrożysz poprawkę u wszystkich klientów, co powiesz dużemu klientowi, który zapyta o izolację danych — i jak poważne będą skutki jednego błędu w kodzie.

Ten tekst tłumaczy, co oznacza architektura multi-tenant według norm i dokumentacji dużych dostawców chmury, jakie modele pośrednie opisują AWS i Microsoft, jak w praktyce rozdziela się dane klientów w bazie i gdzie ta izolacja potrafi zawieść. Opieramy się wyłącznie na źródłach, które da się sprawdzić — normach, dokumentacji technicznej, komunikatach bezpieczeństwa i tekście RODO.

Multi-tenant — co to jest

Najstarsza powszechnie cytowana definicja chmury, NIST SP 800-145 z września 2011 roku, wymienia współdzielenie zasobów wśród pięciu podstawowych cech chmury obliczeniowej: „Resource pooling. The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand.” (tłumaczenie własne: „Łączenie zasobów w pulę. Zasoby obliczeniowe dostawcy są łączone w pulę, aby obsługiwać wielu konsumentów w modelu wielodzierżawczym, a różne zasoby fizyczne i wirtualne są dynamicznie przydzielane i ponownie przydzielane zgodnie z zapotrzebowaniem konsumentów”) (NIST SP 800-145).

NIST mówi więc, że model wielodzierżawczy jest sposobem, w jaki chmura w ogóle działa. Nie mówi natomiast, czego ten model wymaga. To dopowiada norma ISO/IEC 17788:2014 (identyczna z zaleceniem ITU-T Y.3500), która definiuje dwa pojęcia (ITU-T Y.3500):

• multi-tenancy (§3.2.27): „Allocation of physical or virtual resources such that multiple tenants and their computations and data are isolated from and inaccessible to one another.” (tłumaczenie własne: „Przydział zasobów fizycznych lub wirtualnych w taki sposób, że wielu najemców oraz ich obliczenia i dane są od siebie odizolowane i wzajemnie niedostępne”);
• tenant (§3.2.37): „One or more cloud service users sharing access to a set of physical and virtual resources.” (tłumaczenie własne: „Jeden lub więcej użytkowników usługi chmurowej współdzielących dostęp do zbioru zasobów fizycznych i wirtualnych”).

Ważne jest słowo „najemca” (tenant). To nie pojedynczy użytkownik, tylko jednostka, którą izolujesz — w typowym SaaS-ie B2B jest nią firma klienta, razem ze wszystkimi swoimi pracownikami. W definicji ISO sedno nie leży we współdzieleniu, tylko w izolacji: zasoby są wspólne, ale dane jednego najemcy mają być dla drugiego niedostępne. Cała reszta tego tekstu jest o tym, jak to zapewnić i ile to kosztuje.

Czym jest sama chmura i czym różnią się modele IaaS, PaaS i SaaS, wyjaśniamy osobno w tekście o chmurze obliczeniowej.

Single tenant a multi-tenant — co zyskujesz, a co tracisz

Dwa bieguny są proste do opisania. W modelu single tenant każdy klient ma własne środowisko: własną instancję aplikacji, własną bazę danych, często własne serwery. W modelu multi-tenant wszyscy klienci korzystają z tej samej aplikacji i tej samej infrastruktury, a ich dane oddziela logika aplikacji i bazy.

Różnice najlepiej widać w czterech obszarach, które interesują zarówno właściciela firmy, jak i osobę odpowiedzialną za technologię.

Koszt. Współdzielenie zasobów to powód, dla którego SaaS może kosztować klienta kilkadziesiąt złotych miesięcznie. W single tenant każdy nowy klient oznacza nowe środowisko do uruchomienia i opłacenia — nawet jeśli korzysta z niego pięć osób raz w tygodniu. W multi-tenant nowy klient to kilka nowych wierszy w bazie.

Aktualizacje. W modelu wspólnym wdrażasz poprawkę raz i wszyscy klienci mają ją od razu. W modelu z osobnymi środowiskami każde wdrożenie trzeba powtórzyć dla każdego klienta — a jeśli nie jest to w pełni zautomatyzowane, środowiska szybko zaczynają się różnić wersjami.

Izolacja. Tu przewaga jest po stronie single tenant. Gdy dane każdego klienta leżą w osobnej bazie, błąd w zapytaniu nie pokaże firmie A danych firmy B, bo tych danych po prostu w jej bazie nie ma. W modelu wspólnym tę granicę wyznacza kod i konfiguracja bazy — i każdy błąd w nich jest potencjalnym wyciekiem między klientami.

Personalizacja. Osobne środowisko łatwiej dopasować do jednego klienta: inny region przechowywania danych, inne okno aktualizacji, własna domena, czasem własne rozszerzenia. W modelu wspólnym każda taka różnica musi być obsłużona w jednej aplikacji — zwykle przez ustawienia per najemca.

AWS zwraca uwagę na rzecz, o której łatwo zapomnieć: nawet osobne środowiska dla każdego klienta nie czynią z produktu usługi zarządzanej. W SaaS Lens czytamy, że „a silo environment still relies on a shared identity, onboarding, and operational experience … This differentiates SaaS from a managed service model” (tłumaczenie własne: „środowisko silo nadal opiera się na wspólnej tożsamości, wspólnym procesie wdrażania klientów i wspólnym sposobie utrzymania … To odróżnia SaaS od modelu usługi zarządzanej”) (AWS SaaS Lens). Innymi słowy: jeśli każdy klient ma inaczej zbudowane i ręcznie utrzymywane środowisko, to nie jest już SaaS, tylko hosting na zamówienie.

Trzy modele według AWS: silo, pool i bridge

W praktyce mało który produkt jest w stu procentach po jednej stronie. AWS w dokumencie Well-Architected SaaS Lens opisuje trzy modele (AWS, „Silo, Pool, and Bridge Models”):

• silo — „The silo model refers to an architecture where tenants are provided dedicated resources.” (tłumaczenie własne: „Model silo oznacza architekturę, w której najemcy otrzymują dedykowane zasoby”);
• pool — „the pool model of SaaS refers to a scenario where tenants share resources. This is the more classic notion of multi-tenancy” (tłumaczenie własne: „model pool oznacza scenariusz, w którym najemcy współdzielą zasoby. To bardziej klasyczne rozumienie wielodzierżawczości”);
• bridge — „Bridge is meant to acknowledge the reality that SaaS businesses aren't always exclusively silo or pool.” (tłumaczenie własne: „Bridge ma uwzględniać rzeczywistość, w której firmy SaaS nie są zawsze wyłącznie silo albo pool”).

Model bridge jest w praktyce najczęstszy, choć rzadko tak się go nazywa. Typowy przykład: jedna wspólna aplikacja webowa, ale osobne bazy danych dla klientów, którzy tego wymagają. Albo odwrotnie — wspólna baza dla wszystkich, ale osobne kolejki zadań dla klientów generujących największy ruch.

AWS ma też osobny dokument poświęcony wyłącznie izolacji, „SaaS Tenant Isolation Strategies” z 1 sierpnia 2020 roku. Warto go znać, ale z zastrzeżeniem: sam AWS oznacza go dziś jako „for historical reference only” — materiał wyłącznie historyczny (AWS whitepaper). Konkretne rozwiązania techniczne w nim opisane mogły się zestarzeć. Jedno zdanie pozostaje jednak aktualne i dobrze oddaje stawkę: „Crossing this boundary in any form would represent a significant and potentially un-recoverable event for a SaaS business.” (tłumaczenie własne: „Przekroczenie tej granicy w jakiejkolwiek formie byłoby dla firmy SaaS poważnym i potencjalnie nieodwracalnym zdarzeniem”).

Cztery modele według Microsoftu

Microsoft w Azure Architecture Center opisuje ten sam problem od strony wdrożeń i wyróżnia cztery modele (Microsoft Learn, „Tenancy models for a multitenant solution”):

1. Zautomatyzowane wdrożenia single-tenant — „you deploy a dedicated set of infrastructure for each tenant” (tłumaczenie własne: „dla każdego najemcy wdrażasz dedykowany zestaw infrastruktury”). Słowo „zautomatyzowane” jest tu kluczowe: osobne środowiska mają sens tylko wtedy, gdy powstają z jednego szablonu, a nie ręcznie.
2. W pełni wielodzierżawcze wdrożenia — „a fully multitenant deployment in which all components are shared” (tłumaczenie własne: „wdrożenie w pełni wielodzierżawcze, w którym wszystkie komponenty są współdzielone”).
3. Wdrożenia partycjonowane pionowo — „Use a combination of single-tenant and multitenant deployments” (tłumaczenie własne: „łączysz wdrożenia single-tenant i multitenant”). Na przykład klienci z planu podstawowego trafiają do wspólnego środowiska, a klienci korporacyjni dostają własne.
4. Wdrożenia partycjonowane poziomo — „you have some shared components but maintain other components with single-tenant deployments. For example, you can build a single application tier and then deploy individual databases for each tenant” (tłumaczenie własne: „część komponentów jest współdzielona, a inne utrzymujesz jako wdrożenia single-tenant. Możesz na przykład zbudować jedną warstwę aplikacji i wdrożyć osobne bazy danych dla każdego najemcy”).

Dwa zdania z tego dokumentu warto zapamiętać bardziej niż same nazwy modeli. Pierwsze: „Instead of viewing isolation as a discrete property, consider it a spectrum.” (tłumaczenie własne: „Zamiast traktować izolację jako cechę zero-jedynkową, traktuj ją jak spektrum”). Drugie: „Selecting a tenancy model isn't only a technical decision. It's also a commercial decision.” (tłumaczenie własne: „Wybór modelu najemców nie jest wyłącznie decyzją techniczną. Jest też decyzją handlową”). To, co możesz obiecać klientowi w umowie i za ile, wynika bezpośrednio z tego, jak zbudowałeś izolację.

Jak rozdziela się dane: osobna baza, osobny schemat czy wspólne tabele

Najważniejsza część izolacji to dane. Niezależnie od nazwy modelu, na poziomie bazy danych masz do wyboru trzy podstawowe podejścia.

Osobna baza danych dla każdego klienta. Najsilniejsza separacja logiczna: zapytanie wykonane w bazie klienta A fizycznie nie ma dostępu do tabel klienta B. Łatwo też odtworzyć kopię zapasową jednego klienta, przenieść go do innego regionu albo usunąć wszystkie jego dane po zakończeniu umowy. Ceną jest utrzymanie: każda zmiana struktury bazy musi zostać przeprowadzona w każdej bazie osobno, a liczba połączeń i kosztów rośnie z liczbą klientów.

Wspólna baza, osobny schemat dla każdego klienta. Rozwiązanie pośrednie: jedna instancja bazy, ale tabele każdego klienta leżą w osobnej przestrzeni nazw. Separacja jest słabsza niż przy osobnych bazach, a problem migracji struktury zostaje — tyle że wewnątrz jednego serwera.

Wspólne tabele z kolumną `tenant_id`. Klasyczny model pool: wszystkie rekordy wszystkich klientów leżą w tych samych tabelach, a każdy wiersz ma identyfikator najemcy. To najtańsze i najprostsze w utrzymaniu rozwiązanie, ale Microsoft opisuje jego słaby punkt wprost: „When multiple tenants share a single deployment … you typically rely on your application code and a tenant identifier that's in a database to keep each tenant's data separate.” (tłumaczenie własne: „Gdy wielu najemców współdzieli jedno wdrożenie, … zwykle polegasz na kodzie aplikacji i identyfikatorze najemcy zapisanym w bazie, aby oddzielić dane każdego z nich”) (Microsoft Learn). Jedno zapytanie bez warunku WHERE tenant_id = … i dane wszystkich klientów są na wierzchu.

Row Level Security w PostgreSQL — druga linia obrony

Właśnie dlatego w modelu ze wspólnymi tabelami warto nie polegać tylko na kodzie aplikacji. PostgreSQL ma mechanizm, który przenosi tę kontrolę do samej bazy — Row Level Security (RLS). Dokumentacja opisuje go tak: tabele „can have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands. This feature is also known as Row-Level Security.” (tłumaczenie własne: „mogą mieć polityki bezpieczeństwa wierszy, które dla każdego użytkownika ograniczają, jakie wiersze mogą zostać zwrócone przez zwykłe zapytania albo wstawione, zmienione lub usunięte przez polecenia modyfikujące dane”) (PostgreSQL, 5.9 Row Security Policies).

W uproszczeniu, dla tabeli z kolumną tenant_id, może to wyglądać tak (szkic, nie gotowy kod produkcyjny):

1ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
2ALTER TABLE invoices FORCE ROW LEVEL SECURITY;
3
4CREATE POLICY tenant_isolation ON invoices
5  USING (tenant_id = current_setting('app.tenant_id')::uuid);
Copy

Aplikacja ustawia identyfikator najemcy dla połączenia, a baza sama dokłada warunek do każdego zapytania. Nawet jeśli programista zapomni o filtrze, baza nie zwróci cudzych wierszy.

Z dokumentacji PostgreSQL wynikają trzy zasady, które decydują o tym, czy RLS rzeczywiście chroni:

• Domyślna odmowa. „If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified.” (tłumaczenie własne: „Jeśli dla tabeli nie istnieje żadna polityka, stosowana jest domyślna odmowa — żadne wiersze nie są widoczne ani nie mogą być zmienione”). Włączenie RLS bez polityk zamyka tabelę, a nie ją otwiera.
• Superużytkownicy i rola z atrybutem BYPASSRLS zawsze omijają polityki. Jeśli aplikacja łączy się z bazą jako superużytkownik, RLS po prostu nie działa.
• Właściciel tabeli też zwykle je omija. Dokumentacja: „Table owners normally bypass row security as well, though a table owner can choose to be subject to row security with ALTER TABLE ... FORCE ROW LEVEL SECURITY.” (tłumaczenie własne: „Właściciele tabel zwykle także omijają zabezpieczenia wierszy, choć właściciel może poddać się im poleceniem ALTER TABLE ... FORCE ROW LEVEL SECURITY”). To częsta pułapka: aplikacja łączy się tą samą rolą, która utworzyła tabele, i polityki na nią nie działają. Stąd druga linia w przykładzie powyżej.

Supabase: RLS jest włączone tak, jak je skonfigurujesz

Supabase to popularna platforma oparta na PostgreSQL, z której wiele startupów korzysta przy budowie MVP. Tutaj RLS ma jeszcze większe znaczenie, bo tabele mogą być dostępne bezpośrednio z przeglądarki przez API. Dokumentacja jest jednoznaczna: „A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema.” (tłumaczenie własne: „Tabela w udostępnionym schemacie bez RLS może być odczytywana i zapisywana przez każdą rolę, która ma do niej uprawnienia. Włącz RLS na każdej tabeli w udostępnionym schemacie”) (Supabase, Row Level Security).

Dwie dalsze pułapki z tej samej dokumentacji:

• klucz service_role daje „Full access. It bypasses RLS, so keep it server-side” (tłumaczenie własne: „Pełny dostęp. Omija RLS, więc trzymaj go po stronie serwera”) — jeśli trafi do kodu frontendu, izolacja najemców przestaje istnieć;
• widoki: „Views bypass RLS by default because they are usually created with the postgres user.” (tłumaczenie własne: „Widoki domyślnie omijają RLS, bo zwykle tworzy się je jako użytkownik postgres”). Widok zbudowany na tabeli z politykami może więc pokazać wszystkie wiersze wszystkich klientów. Od PostgreSQL 15 widok można zmusić do respektowania polityk opcją security_invoker = true.

Supabase przypomina też, że dodanie polityk nie odbiera domyślnych uprawnień nadanych rolom („Adding policies doesn't remove them”). RLS to druga linia obrony, nie zamiennik dla przemyślanych uprawnień.

Hałaśliwy sąsiad i inne koszty współdzielenia

Izolacja danych to nie jedyny problem wspólnej infrastruktury. Drugi ma nazwę tak obrazową, że przyjęła się w dokumentacji: hałaśliwy sąsiad (noisy neighbor). Microsoft definiuje go tak: „The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant.” (tłumaczenie własne: „Problem hałaśliwego sąsiada występuje, gdy wydajność jednego najemcy spada z powodu działań innego najemcy”) (Azure Architecture Center, „Noisy Neighbor Antipattern”).

W SaaS-ie wygląda to zwykle banalnie: jeden klient importuje duży plik, generuje ciężki raport albo jego integracja wysyła tysiące zapytań na minutę — i aplikacja zwalnia wszystkim pozostałym. Microsoft dodaje zdanie, które warto mieć na uwadze przy obietnicach w umowie: „Sharing a single resource inherently carries the risk of noisy neighbor problems that you can't completely avoid.” (tłumaczenie własne: „Współdzielenie jednego zasobu z natury niesie ryzyko problemów z hałaśliwym sąsiadem, którego nie da się całkowicie uniknąć”).

Można je ograniczać: limitami zapytań per najemca, osobnymi kolejkami dla ciężkich zadań, monitoringiem zużycia zasobów przez poszczególnych klientów, a w skrajnym przypadku przeniesieniem największego klienta do osobnego środowiska — czyli przejściem na model bridge. Jeśli planujesz dawać klientom gwarancję dostępności lub czasu odpowiedzi, hałaśliwy sąsiad jest jednym z ryzyk, które musisz wliczyć w te obietnice (o samych gwarancjach piszemy w tekście o SLA).

Inne koszty współdzielenia są mniej widoczne, ale realne: trudniej odtworzyć dane jednego klienta z kopii zapasowej wspólnej bazy bez naruszania pozostałych, trudniej trwale usunąć wszystkie dane klienta po zakończeniu umowy, a każda migracja bazy dotyka wszystkich naraz.

Kiedy izolacja zawodzi: ChaosDB i ExtraReplica

Czy wielodzierżawczość jest bezpieczna? Najlepszą odpowiedzią są przypadki, w których izolację najemców udało się przełamać — i to u dostawcy o skali Microsoftu. Dwa takie przypadki opisali badacze z firmy Wiz, a Microsoft potwierdził je we własnych komunikatach. W obu przypadkach chodzi o podatności wykryte przez badaczy, a nie potwierdzone wycieki danych.

ChaosDB — Azure Cosmos DB, 2021. 27 sierpnia 2021 roku Microsoft Security Response Center opisał podatność w funkcji Jupyter Notebook usługi Cosmos DB, która „could potentially allow a user to gain access to another customer's resources by using the account's primary read-write key” (tłumaczenie własne: „potencjalnie mogła pozwolić użytkownikowi uzyskać dostęp do zasobów innego klienta przy użyciu głównego klucza odczytu i zapisu konta”). Podatność zgłoszono 12 sierpnia 2021, a Microsoft wyłączył funkcję w wersji zapoznawczej i poprosił klientów, którzy korzystali z niej między 7 a 13 sierpnia, o wygenerowanie nowych kluczy. Najważniejsze zdanie komunikatu: „No customer data was accessed because of this vulnerability by third parties or security researchers.” (tłumaczenie własne: „W wyniku tej podatności ani osoby trzecie, ani badacze bezpieczeństwa nie uzyskali dostępu do danych klientów”) (MSRC, 27.08.2021). Badacze z Wiz opisali potencjalny zasięg tak: „complete unrestricted access to the databases of several thousand Microsoft Azure customers” (tłumaczenie własne: „pełny, nieograniczony dostęp do baz danych kilku tysięcy klientów Microsoft Azure”); za zgłoszenie otrzymali nagrodę w wysokości 40 000 dolarów (Wiz, ChaosDB).

ExtraReplica — Azure Database for PostgreSQL Flexible Server, 2022. 28 kwietnia 2022 roku Microsoft opisał podatność, która umożliwiała „unauthorized cross-account database access in a region” (tłumaczenie własne: „nieuprawniony dostęp do baz danych innych kont w obrębie regionu”). Przyczyną było między innymi „an improperly anchored regular expression to bypass authentication” (tłumaczenie własne: „niepoprawnie zakotwiczone wyrażenie regularne pozwalające obejść uwierzytelnianie”). Podatność dotyczyła tylko serwerów korzystających z opcji publicznego dostępu sieciowego. Poprawki wdrożono 13 stycznia 2022 (izolacja między najemcami) i 25 lutego 2022 (cała infrastruktura). Microsoft stwierdził: „Our analysis revealed no customer data was accessed using this vulnerability.” (tłumaczenie własne: „Nasza analiza wykazała, że przy użyciu tej podatności nie uzyskano dostępu do danych klientów”) (MSRC, 28.04.2022; Wiz, ExtraReplica).

Wnioski dla twojego produktu są trzy. Po pierwsze, izolacja najemców to nie jedna blokada, tylko kilka warstw — w ExtraReplica pojedynczy błąd w wyrażeniu regularnym wystarczył, żeby jedna z nich przestała działać. Po drugie, w obu przypadkach granica pękła w miejscu dodatkowym: w funkcji w wersji zapoznawczej i w opcjonalnym trybie dostępu sieciowego. Każda nowa funkcja, która dotyka danych wielu klientów, zasługuje na osobny przegląd bezpieczeństwa. Po trzecie, żeby po zgłoszeniu podatności móc odpowiedzieć klientom, czy ktoś z niej skorzystał, trzeba mieć zapisy, z których da się to ustalić. W małym SaaS-ie oznacza to przynajmniej logowanie dostępu do danych razem z identyfikatorem najemcy.

RODO art. 32 a SaaS z wieloma klientami

Jeśli twój SaaS przetwarza dane osobowe w imieniu klientów, jesteś wobec nich podmiotem przetwarzającym, a art. 32 RODO obowiązuje cię wprost. W tekście skonsolidowanym (po sprostowaniu) ust. 1 brzmi: „Uwzględniając stan wiedzy technicznej, koszt wdrażania oraz charakter, zakres, kontekst i cele przetwarzania oraz ryzyko naruszenia praw lub wolności osób fizycznych o różnym prawdopodobieństwie wystąpienia i wadze, administrator i podmiot przetwarzający wdrażają odpowiednie środki techniczne i organizacyjne, aby zapewnić stopień bezpieczeństwa odpowiadający temu ryzyku, w tym między innymi w stosownym przypadku: a) pseudonimizację i szyfrowanie danych osobowych; b) zdolność do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów i usług przetwarzania; c) zdolność do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego; d) regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych mających zapewnić bezpieczeństwo przetwarzania.” (RODO, tekst skonsolidowany).

Ust. 2 każe przy ocenie ryzyka uwzględnić w szczególności ryzyko wynikające z „przypadkowego lub niezgodnego z prawem zniszczenia, utraty, modyfikacji, nieuprawnionego ujawnienia lub nieuprawnionego dostępu do danych osobowych przesyłanych, przechowywanych lub w inny sposób przetwarzanych”.

Trzeba to powiedzieć uczciwie: art. 32 nie wymaga dosłownie rozdzielania najemców ani żadnej konkretnej architektury. To, co z niego wyciągamy, jest naszą interpretacją. W SaaS-ie z wieloma klientami najbardziej prawdopodobnym scenariuszem „nieuprawnionego dostępu” z ust. 2 jest właśnie sytuacja, w której jeden klient widzi dane drugiego. Poufność z lit. b w modelu wspólnym zależy od jakości izolacji. A lit. d — regularne testowanie skuteczności środków — w praktyce oznacza testy, które sprawdzają, czy użytkownik jednego najemcy nie odczyta danych innego. Lit. c wiąże się z kolei z czasem odtworzenia po awarii, o którym piszemy w tekście o SLA.

Szerzej o podziale odpowiedzialności między dostawcą a klientem, umowie powierzenia i pytaniach do dostawcy chmury piszemy w tekście o bezpieczeństwie danych w chmurze.

Jak wybrać model na start

Nie istnieje jedna dobra odpowiedź, ale istnieją pytania, które szybko zawężają wybór. Warto odpowiedzieć na nie, zanim powstanie pierwsza tabela w bazie.

Kim są twoi klienci i czego będą wymagać? Jeśli sprzedajesz małym firmom, które płacą niewielki abonament, model wspólny jest zwykle jedynym, który się spina ekonomicznie. Jeśli celujesz w klientów korporacyjnych, spodziewaj się pytań o izolację danych, region przechowywania i audyty — a czasem wprost wymogu osobnej bazy. Wtedy warto od początku zaprojektować aplikację tak, żeby dało się ją uruchomić w obu trybach (model bridge).

Ile możesz wydać na infrastrukturę na jednego klienta? Microsoft słusznie nazywa wybór modelu decyzją handlową. Osobne środowisko dla klienta płacącego niewielki abonament miesięcznie rzadko ma sens; dla klienta z umową roczną na kilkadziesiąt tysięcy złotych — często tak.

Jakiej skali się spodziewasz? Kilkudziesięciu klientów obsłużysz w każdym modelu. Przy setkach i tysiącach klientów osobne bazy oznaczają setki i tysiące migracji przy każdej zmianie struktury danych.

Jakie przepisy i umowy cię wiążą? Dane szczególnie wrażliwe, wymagania branżowe, zapisy w umowach powierzenia z klientami — to wszystko może wymusić wyższy poziom izolacji niż ten, który wybrałbyś z powodów kosztowych.

Dla większości nowych produktów rozsądnym punktem wyjścia jest model wspólny ze wspólnymi tabelami, kolumną identyfikatora najemcy w każdej tabeli z danymi klientów i Row Level Security jako drugą linią obrony — zaprojektowany tak, żeby później dało się wydzielić dużego klienta do osobnej bazy. Taka architektura jest tania na starcie i nie zamyka drogi do modelu bridge. Najdroższe jest dopisywanie identyfikatora najemcy do istniejącej aplikacji, która go nie przewidywała — wtedy trzeba przejrzeć każde zapytanie.

Ile kosztuje zbudowanie takiej aplikacji? Nasz raport „Koszty aplikacji webowych w Polsce — edycja 2026” zalicza projekty multi-tenant SaaS do kategorii „enterprise” (razem z integracjami ERP/CRM i projektami z wymogami zgodności) i podaje dla niej medianę 200 000 zł (n=43). Dla porównania mediana MVP wynosi 30 000 zł (n=24). Obie liczby trzeba czytać z zastrzeżeniem: raport zestawia opublikowane cenniki i benchmarki firm, nie faktury z projektów, a dane zebrano w okresie marzec–maj 2026. U nas Lean MVP zaczyna się od 10 tys. zł, a MVP od 30 tys. zł — każdy projekt wyceniamy indywidualnie, a architekturę wielodzierżawczą można zaplanować od pierwszej wersji bez budowania od razu pełnego systemu enterprise.

Jeśli dopiero sprawdzasz pomysł, zacznij od tekstu o MVP. O tym, z jakich klocków składa się aplikacja SaaS poza samą izolacją najemców — kontach, płatnościach, rolach — piszemy w tekście o aplikacji SaaS, a cały model biznesowy opisuje nasz przewodnik po SaaS. Budowę produktu prowadzimy w ramach usług tworzenia aplikacji webowych i MVP dla startupów, a jeśli potrzebujesz najpierw niezależnej opinii o architekturze, możemy pomóc w ramach doradztwa technologicznego.