PostgreSQL i RLS: izolacja tenantów w SaaS e-commerce
RLS (Row Level Security) to mechanizm PostgreSQL, który automatycznie filtruje wiersze według tenant_id, nawet jeśli aplikacja popełni błąd w zapytaniu.
Wspólna baza vs osobne schematy
RLS sprawdza się przy wielu małych tenantach i wspólnej ekonomii infrastruktury. Osobne schematy lub klastry wchodzą w grę przy twardych wymogach compliance.
Decyzja zależy od modelu ryzyka, a nie od mody na „multi-tenant”.
Polityki i rola aplikacji
Ustawiamy `SET app.tenant_id` per request w warstwie NestJS i testujemy, że zapytanie bez kontekstu zwraca zero wierszy.
Migracje SQL muszą tworzyć polityki idempotentnie, inaczej produkcja i staging rozjadą się po tygodniu.
Testy i odzyskiwanie
Scenariusze „tenant A nie widzi danych B” są w suite integracyjnej. Backupy segregujemy według polityki retencji klienta.
Ćwiczymy restore do izolowanego środowiska zanim pierwszy incydent produkcyjny.
Najczęstsze pytania
- Czy RLS zastępuje testy aplikacji?
- Nie. to ostatnia linia obrony. Nadal walidujemy autoryzację w kodzie i audytujemy endpointy.
- Wpływ na wydajność?
- Indeks pod tenant_id i świadome zapytania są obowiązkowe; profilujemy plany zapytań przy szczytach.
- A GDPR?
- RLS pomaga technicznie; procedury usuwania danych i DPIA wymagają procesów prawnych i logów.
Treść zaktualizowano: 14 marca 2026