How do you secure multi-tenant SaaS with PostgreSQL RLS?

Multi-tenant SaaS is attractive because one application and one infrastructure footprint serve many customers. Instead of maintaining a separate database for every company, you keep data in shared tables, usually with a `tenant_id` column. Infrastructure cost goes down, migrations are simpler and feature rollout is faster.

But this model has one brutal risk: cross-tenant data leakage. If customer A sees invoices, users, CRM notes or documents from customer B, the problem is not just a bug. It is a security incident, loss of trust, potential legal exposure and a conversation with your largest customer that nobody wants to have.

That is why in B2B systems it is not enough to say "our backend always adds `tenant_id`". One endpoint, report, CSV export, job, admin view or raw query without the predicate is enough. PostgreSQL Row-Level Security does not remove every risk, but it moves part of isolation from developer memory into the database engine.

The official PostgreSQL documentation describes RLS as policies that restrict which rows can be returned, inserted, updated or deleted. Once RLS is enabled, normal access to the table must be allowed by a policy. If no policy exists, default-deny applies: rows are not visible or modifiable.

For SaaS, the idea is simple: an `invoices` table can have a policy like `tenant_id = current_setting('app.current_tenant')::uuid`. After authentication, the application sets session context and the database automatically applies the filter. Even if code forgets `WHERE tenant_id = ...`, a normal user should not see another tenant rows.

This sounds like magic, but it is not. RLS works per table, per role and per command. Table owners and roles with `BYPASSRLS` can bypass policies. That is why production design must cover application roles, `FORCE ROW LEVEL SECURITY`, migration tests and a clear split between application, admin and maintenance connections.

The most common mistake is not the RLS policy itself, but setting context. After authorization, the API must know which tenant is making the request and then set that tenant in the PostgreSQL session. In practice, we use NestJS request context, guards/authorization and a database-client layer that does not allow queries without tenant context where it is required.

With connection pooling, be careful: connections are reused. Tenant context should be set for the transaction or request and reset afterwards. In PostgreSQL, teams often use `set_config('app.current_tenant', tenantId, true)` inside a transaction, where the third argument `true` limits the setting to the current transaction.

Whether you use Prisma, Drizzle, Kysely or raw `pg`, the principle is the same: the ORM is not the security boundary. The ORM helps build queries, but RLS needs deliberate connection lifecycle, tests and wrappers that prevent accidental use of a superuser or a connection string that bypasses policies.

The simplest `USING (tenant_id = current_setting(...))` policy is only the beginning. A production SaaS needs separate rules for `SELECT`, `INSERT`, `UPDATE` and `DELETE`, because row visibility and the right to create/change a row are not the same. PostgreSQL lets you use `USING` for access and `WITH CHECK` for data being written.

Example: a user may view invoices from their tenant, but must not change an invoice `tenant_id` through an API payload. `WITH CHECK` should enforce that a new or updated row still belongs to the current tenant. For shared tables, such as subscription plans, feature flags or public catalogue, the policy may differ or RLS may not be the right boundary.

Roles matter too. The production app should not connect as the table owner or superuser. Separate roles for app runtime, migrations, read-only reporting and break-glass admin reduce the risk that one library or script disables the entire isolation model.

RLS needs negative tests. It is not enough to confirm tenant A can see their invoices. You must confirm tenant A cannot see B invoices, cannot insert a row with B `tenant_id`, cannot update their row to B `tenant_id`, and cannot receive data through a relation, view, SQL function, export, search or background job.

Good tests create two tenants, two users and similarly shaped data, then run scenarios through the API and directly at the database-client layer. Test migrations too: a new table containing tenant data must not reach production without RLS and a `tenant_id` index.

Supabase reminds teams that RLS is powerful, but must be enabled. PostgreSQL reminds teams that once RLS is enabled and no policy exists, default-deny applies. That is an excellent safety property, provided the review process detects tables without policies before customers discover missing data after deployment.

The common CTO question is: will RLS slow the database down? The answer is: it can, if policies are complex, reference other tables without indexes or require functions evaluated per row. A simple `tenant_id` policy on well-indexed tables is usually far less problematic than manual filters scattered across the codebase.

Design for RLS from the beginning: `tenant_id` as a first-class column on tenant-owned tables, indexes including `tenant_id`, deliberate unique constraints, partitioning only after measurement, separate paths for global tables and no policies that run heavy subqueries per row.

Remember that RLS does not solve every data problem. Analytics, warehouses, events, search indexes and cache need their own tenant isolation. If Elasticsearch or Redis cache receives a key without a tenant prefix, PostgreSQL RLS will not save the layer outside the database.

RLS is a strong guardrail, but not a security strategy by itself. If a customer requires a separate data region, backup/restore, dedicated encryption key, maintenance window or certification boundary, pooled with RLS may not be enough. You need silo or bridge tenancy.

RLS also does not replace business authorization. The fact that a user belongs to a tenant does not mean they can view payroll, export all invoices or delete a project. Roles, subscription plan, feature flags and account status still need to be handled in the application and often reflected in policies.

Do not use RLS as an excuse to skip threat modeling. Analyze administrators, support, integrations, webhooks, background jobs, backups, BI, audit, logs and debugging tools. Leakage can come not only from an API endpoint, but also from a "helpful" export for customer support.

A multi-tenant SaaS backend with NestJS, PostgreSQL RLS, authorization, a starter console and payments usually starts around PLN 160,000-300,000 for a useful MVP. Advanced B2B SaaS with workflows, audit, billing, integrations, data imports and reporting can go higher. The RLS policy itself is not expensive. The expensive part is confidence that nobody bypasses it.

The biggest cost drivers are data model, roles and permission model, migrations, isolation tests, connection pooling, integrations, audit logs, admin/support tooling, importing existing data and monitoring. If the SaaS has AI/RAG features, tenant isolation must also cover embeddings, retrieval and cache.

GMI provides an initial estimate within 48 hours, but fixed price only after DDT. In DDT we define tenancy model, data map, threat model, MVP scope, RLS policies, tests and maintenance risks. That is more honest than promising "secure SaaS" based on stack names alone.

We start with DDT: mapping tenants, roles, data, integrations, billing, admin operations and security risks. Only then do we decide whether the system should be pooled with RLS, silo, bridge or mixed. This matters because a bad tenancy decision can force an expensive migration after the first enterprise customers arrive.

Technically, we usually use NestJS, PostgreSQL, Prisma or another typed query layer, Redis where cache/queue is needed, Next.js for the console and React Native if the product has a mobile surface. RLS is part of a larger architecture: authorization, audit log, observability, contract tests and safe support tooling.

Commercially, the client gets source-code ownership, no vendor lock-in, fixed price after DDT and a clear maintenance model. This is especially important in SaaS because security is not a one-time feature. Every new table, integration and AI feature must keep respecting the tenant boundary.