I'll be honest: I almost did multi-tenancy the wrong way.

When I started building InspectIQ "a SaaS platform for Florida home inspectors" my first instinct was to add a tenant_id column to every table and filter it in the application layer. Every query would have a WHERE tenant_id = :current_tenant clause. Simple, familiar, done.

Then I thought about what happens when you forget one.

One missing WHERE clause. One endpoint that skips the filter. One inspector sees another inspector's client data. In a home inspection business, that's not just a bug — it's a HIPAA-adjacent nightmare and a trust-destroying moment with your first customer.

So I did it properly from day one: Row Level Security at the database layer.

What is Row Level Security?

RLS is a PostgreSQL feature that lets you define policies directly on tables.
When a user queries a table, the policy runs automatically, before your application code even sees the results. You can't forget to apply it. You can't bypass it with a careless JOIN. It's enforced at the lowest possible layer.

For a multi-tenant SaaS, this is exactly what you want.

How I implemented it

Every table in InspectIQ has this pattern:

ALTER TABLE inspections ENABLE ROW LEVEL SECURITY;
ALTER TABLE inspections FORCE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON inspections
  USING (tenant_id = NULLIF(current_setting('app.current_tenant_id',true), '')::uuid);

The FORCE is important — it applies the policy even to the table owner.
No superuser backdoor.

The tenant context comes from the JWT. When an inspector logs in, theirtenant_id is embedded as a custom Cognito claim. The FastAPI middleware extracts it and sets it at the start of every request:

await session.execute(
    text(f"SET LOCAL app.current_tenant_id = '{tenant_id}'")
)

SET LOCAL scopes the setting to the current transaction. When the transaction ends, it's gone. No leakage between requests.

Aurora PostgreSQL Serverless v2

I'm running this on Aurora PostgreSQL Serverless v2 on AWS. For an early-stage SaaS, the economics are compelling: you pay for what you use, it scales to zero between requests, and you get full PostgreSQL compatibility.

The RLS policies work identically on Aurora as they do on vanilla PostgreSQL.
No Aurora-specific gotchas, no driver changes.

One thing I learned the hard way: Aurora with restricted database users (which is the right security posture) means your migration user needs DDL privileges separately from your application user. I run schema migrations via a bastion EC2 through AWS SSM — no SSH, no exposed credentials, no public IP on the database.

The moment it clicked

The first time I tested with two tenants, I logged in as Tenant A and ran a query that should only return Tenant B's data. I got an empty result set.

Not an error. Not "access denied." Just nothing — because from the database's perspective, those rows don't exist for this tenant.

That's the right behavior. That's what you want. And I didn't have to write a single WHERE clause in my application code to get it.

The tradeoff

RLS adds complexity to your migration process and your database user setup.
You need to think carefully about which user runs DDL vs. which user runs application queries. You need to test that your policies actually work, both that they block the right data AND that they return the right data for the correct tenant.

But for a B2B SaaS where tenant isolation is a hard requirement, the tradeoff is worth it. The alternative — application-level filtering — is a security debt that compounds with every new endpoint you add.

What's next

InspectIQ is live at mcag-h0.vercel.app with a confirmed first customer (REBS Property Specialist LLC, a 30-year Florida licensed inspector) starting July 2026.

If you're building multi-tenant SaaS on Aurora PostgreSQL and want to talk architecture, find me here on dev.to.

I created this content for the purposes of entering the H0: Hack the Zero Stack
Hackathon by AWS and Vercel. #H0Hackathon