Building a multi-tenant SaaS application has been on my mind since a client requested a scalable solution that could securely serve hundreds of organizations. How do we keep tenant data isolated without drowning in infrastructure costs? That’s what I’ll explore today using NestJS, Prisma, and PostgreSQL’s Row-Level Security. Stick around – I’ll share practical solutions I’ve tested in production environments.

Multi-tenancy means a single application serves multiple customers while keeping their data separate. We have three main approaches: separate databases per tenant (secure but costly), shared database with separate schemas (moderate complexity), or shared schema with row-level security (our focus). Why choose RLS? It balances security with scalability. Imagine having all tenant data in one table – how do we prevent accidental leaks? PostgreSQL’s RLS enforces data segregation at the database level, acting as a safety net for our application.

Let’s set up our project. First, initialize a NestJS app and install dependencies:

nest new saas-app
npm install prisma @prisma/client
npx prisma init

Now, design the Prisma schema with tenant context. Notice every tenant-scoped model includes tenantId:

model Tenant {
  id   String @id @default(cuid())
  name String
  users User[]
}

model User {
  id       String @id @default(cuid())
  email    String
  tenant   Tenant @relation(fields: [tenantId], references: [id])
  tenantId String
}

For RLS, we enable policies in PostgreSQL. Here’s how we restrict user access to their tenant’s data:

ALTER TABLE "User" ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation_policy ON "User"
FOR ALL
USING (tenant_id = current_setting('app.current_tenant')::UUID);

In NestJS, we inject the tenant context using middleware. This sets the PostgreSQL session variable before each query:

@Injectable()
export class TenantMiddleware implements NestMiddleware {
  constructor(private prisma: PrismaService) {}

  async use(req: Request, res: Response, next: NextFunction) {
    const tenantId = req.headers['x-tenant-id'];
    if (tenantId) {
      await this.prisma.$executeRaw`SELECT set_config('app.current_tenant', ${tenantId}, false)`;
    }
    next();
  }
}

Authentication needs tenant awareness too. During login, we verify credentials within the tenant scope:

async validateUser(email: string, password: string, tenantId: string) {
  const user = await this.prisma.user.findFirst({
    where: { 
      email, 
      tenantId,
      status: 'ACTIVE' 
    }
  });
  if (user && bcrypt.compareSync(password, user.password)) {
    return user;
  }
  return null;
}

Ever wonder how to prevent data leaks in complex joins? Prisma’s middleware automatically appends tenantId to queries:

this.prisma.$use(async (params, next) => {
  if (['User', 'Project'].includes(params.model)) {
    params.args.where = { ...params.args.where, tenantId };
  }
  return next(params);
});

Testing is critical. We validate tenant isolation with scenarios like:

it('blocks cross-tenant data access', async () => {
  const tenantAUser = await createTestUser(tenantAId);
  const tenantBUser = await createTestUser(tenantBId);
  
  // Attempt to access Tenant B's data as Tenant A
  const result = await service.getUser(tenantAUser.id, tenantBId);
  expect(result).toBeNull();
});

Performance optimizations include:

• Indexing tenantId columns
• Caching tenant-specific data with Redis
• Using connection pooling to handle RLS overhead

Common pitfalls? Forgetting to set tenantId on new records or misconfiguring RLS policies. Always audit your policies with:

EXPLAIN ANALYZE SELECT * FROM "User";

I’ve seen teams struggle with multi-tenancy until they implement RLS at the database layer. It’s not just about convenience – it’s about creating an unbreakable data isolation foundation. What edge cases have you encountered in your projects?

If this approach resonates with you, share your thoughts in the comments. Pass this along to anyone building SaaS applications – proper tenant isolation saves countless security headaches down the road.