DEV Community: Jestony Silvano

How I Built Multi-Tenant Data Isolation for My SaaS CRM with PostgreSQL RLS

Jestony Silvano — Thu, 10 Sep 2026 16:00:33 +0000

How I Built Multi-Tenant Data Isolation for My SaaS CRM with PostgreSQL RLS

When I started building uniThread CRM, I wanted it to be more than just a basic CRUD project. I wanted to actually understand what it takes to build a SaaS application where multiple organizations share the same system without ever seeing each other's data.

That led me to one of the harder questions I had to answer while building it:

How do I make sure users can only ever access data belonging to their own organization?

My answer ended up being a combination of PostgreSQL Row-Level Security (RLS) and authorization logic on the backend. Here's how I got there, and why I didn't just trust one layer to handle it.

The Obvious Requirement

The rule is simple to state: Organization A should never be able to access Organization B's data. Simple to say, less simple to guarantee.

The easy way to handle this is to just add an organization_id filter to every database query in the backend. And that works... until someone forgets to add it. One missed WHERE clause on one endpoint, and suddenly you've got a data leak. I didn't want tenant isolation to depend entirely on every developer (including future me) remembering to add that filter every single time.

That's what got me looking into PostgreSQL RLS.

Designing Around Organizations

For any organization-specific CRM data, I use an organization_id column to tie each record to the organization that owns it. Nothing fancy, just:

CREATE TABLE leads (
    id UUID PRIMARY KEY,
    organization_id UUID NOT NULL,
    name TEXT NOT NULL
);

That gives every lead a clear, explicit relationship to an organization. It sounds almost too simple to matter, but it's the foundation everything else builds on top of.

Bringing in Row-Level Security

PostgreSQL RLS lets the database itself decide which rows a query is allowed to see, instead of leaving that entirely up to the application code.

First, you turn it on for the table:

ALTER TABLE leads ENABLE ROW LEVEL SECURITY;

Then you write a policy that only allows access to rows belonging to the current user's organization:

CREATE POLICY "Users can access their organization leads"
ON leads
FOR SELECT
USING (
    organization_id = get_user_organization_id()
);

Once that's in place, tenant isolation stops being something only my application layer is responsible for. The database is now enforcing it too. Even if I mess something up in the app code, there's still a wall between organizations at the data layer. That extra layer of protection is really what sold me on this approach.

Why I Didn't Just Rely on RLS

Even with RLS in place, I still wanted the backend to own authorization and business logic. RLS is great at stopping cross-tenant access, but it's not really designed to handle things like "can an Agent delete a lead" or "is this user even allowed to hit this endpoint."

So the backend follows a fairly standard layered structure:

Request
   ↓
Controller
   ↓
Service
   ↓
Repository
   ↓
PostgreSQL

The backend handles authentication, role-based access control, organization context, business rules, and validation. Then PostgreSQL adds its own layer on top through RLS.

The point isn't to make one layer do everything. It's to let each layer do what it's actually good at.

Roles

Right now, uniThread has three organization-level roles:

Owner
Manager
Agent

A user's role determines what they're allowed to do inside their organization.

Working through this part is actually what made the difference between authentication and authorization click for me in a way it never had before.

Authentication asks: who are you?

Authorization asks: what are you allowed to do?

And tenant isolation asks a third, separate question: which organization's data are you even allowed to touch?

They sound like variations of the same idea when you read about them, but once you're actually implementing all three at once, the differences become a lot more obvious.

What I Learned

Before building uniThread, my mental model of auth was basically:

Login → JWT → Authenticated User

That's it. That was the whole picture in my head.

Building something multi-tenant broke that mental model pretty quickly. Getting a user authenticated is really just the starting point. After that you still have to figure out what they can access, what actions they're allowed to take, and how the database itself should be protecting that data regardless of what the app layer does.

It also made me a lot more deliberate about where security checks actually belong, and made me think harder about what happens the day a developer forgets to add one.

The Result

Between organization-scoped data, backend authorization, and PostgreSQL RLS, uniThread now has a decent foundation for keeping tenant data properly separated.

More than the technical result, though, this was one of the first parts of the project that pushed me past "just build the CRUD feature" and into actually thinking about architecture, security, data ownership, and what happens as the system grows.

What I'd Do Differently

If I were starting uniThread over, I'd think about tenant isolation a lot earlier than I did. It's way easier to bake organization ownership into your schema from day one than to retrofit it after you've already built a pile of features on top of a shaky foundation.

I'd also spend more time up front defining authorization rules, instead of discovering the edge cases one at a time while implementing individual features and going "oh... wait."

Final Thoughts

uniThread started out as just "I want to build a CRM." Somewhere along the way it turned into a much better lesson in how SaaS applications are actually put together under the hood.

Multi-tenancy was one of those topics that looked simple from the outside and turned out to be way more interesting than expected once I actually had to implement it myself.

I'm still learning as I go, but honestly, that's a big part of why I keep building projects like this. The interesting part was never just making the app work. It's figuring out how to make it work correctly as things get more complicated.

Juniors! Overengineer Your Projects

Jestony Silvano — Wed, 09 Sep 2026 11:15:17 +0000

title: "Juniors! Overengineer Your Projects"
published: true
description: "Stop optimizing for the number of projects you can finish. Build fewer things, go deeper, use AI intelligently, break your own code, and learn how real software systems work."
tags: "ai, beginners, webdev, programming, softwareengineering"

Juniors! Overengineer Your Projects

If you're a junior developer trying to land your first software job, you've probably heard some version of this advice:

"Build more projects."

So you build another one.

Then another.

A portfolio website.
A weather app.
A todo app.
A Netflix clone.
A CRUD application.

And eventually, you have a GitHub full of repositories. But how much did you actually learn? I think we should approach this differently.

Stop Optimizing for the Number of Projects

You don't need to prove that you can start 20 projects. You need to prove that you can understand, build, debug, and improve software.

Instead of asking:

"How quickly can I finish this?"

Try asking:

"How far can I take this?"

That's where things get interesting.

1. Don't Be Afraid to Overengineer

Obviously, don't build a distributed microservice architecture for a todo app just because you can. That's not the point. The point is that complexity can create opportunities to learn. Take a project further than you initially planned. Add authentication. Design a proper database. Think about authorization. Add role-based access control. Handle errors properly. Think about concurrency. Add caching. Write tests. Build background jobs. Think about how the system behaves when something fails. Deploy it. Monitor it. Then break it. Then fix it. You might spend weeks building something that could have been hacked together in three days. And that's okay. If those extra weeks made you understand something you didn't understand before, you didn't waste them. You learned.

2. Read Your Own Code

This one sounds obvious, but I think it's seriously underrated.

Read the code you wrote.

Not just while you're writing it.

Come back to it later.

Look at an old function and ask:

Why did I build it this way?
Do I still understand this?
Would I design this differently now?
Is this actually maintainable?
What happens when this fails?
Why does this abstraction exist?
Did I solve the actual problem, or did I just make the code more complicated?

Then change it.

Refactor it.

Delete it.

Rewrite it.

Your old code is one of the best teachers you'll ever have because it shows you exactly what you used to think you understood.

3. We're Still Early in the AI Era

This is probably one of the most interesting times to be learning software development.

AI can write code incredibly quickly.

So use it.

Seriously.

Don't pretend AI doesn't exist just because you want to "learn properly."

Leverage it.

Ask it to explain concepts you don't understand.

Ask it to explain unfamiliar code.

Ask it to compare architectural approaches.

Ask it to review your database design.

Ask it to find edge cases.

Ask it to challenge your assumptions.

Ask it questions you would normally spend hours trying to formulate yourself.

But there's a catch.

Don't Let AI Become Your Brain

The quality of the answer you get is heavily influenced by the quality of the question you ask.

And the quality of your question depends on the context you can provide.

Build context.

Learn the problem first.

Understand your system.

Understand the constraints.

Understand what you're trying to solve.

Then ask AI.

If you give it vague questions and no context, you'll often get vague solutions.

If you understand the problem and provide meaningful context, AI becomes a much more powerful learning tool.

And don't be afraid to use smaller models or solve something yourself before reaching for the biggest model available.

Sometimes struggling with a problem for an hour teaches you more than getting the answer in ten seconds.

4. Build Systems, Not Just Projects

There's a difference between building a project and building a system.

A project can be:

"I built a CRUD application."

A system makes you ask:

"What happens when 10,000 users use this?"

Then you start thinking differently.

You start thinking about:

Architecture
Data modeling
Security
Performance
Caching
Authentication
Authorization
Observability
Deployment
Failure recovery
Scalability
Maintainability

You don't necessarily need to implement all of these.

But even thinking about them changes the way you understand software.

5. Build Something That Is Actually Yours

Please, build another tutorial project if you want to. There's nothing wrong with that. But eventually, build something original. Build something because you had an idea, because you noticed a problem.

"I have no idea how I'm going to build this."

That's where the fun starts. You might fail. Good. You might rewrite half of it. Even better. You might discover that your original architecture was terrible. Perfect. Now you have something to learn from.

Don't Maximize Output. Maximize Learning.

There's a strange pressure among junior developers to constantly produce.

More GitHub repositories.
More projects.
More technologies.
More certificates.
More tutorials.
More AI-generated code.
More, more, more.

But software development isn't a race to produce the most code. You can build 30 projects and barely understand any of them. Or you can build one project that forces you to learn databases, APIs, authentication, security, deployment, architecture, testing, debugging, and system design.

Which developer do you think learned more?

So if you're a junior developer trying to get your first job:

Don't be afraid to take your project too far.
Don't be afraid to spend too much time learning.
Don't be afraid to read your own code.
Don't be afraid to break things.
Don't be afraid to rewrite things.
Don't be afraid to ask AI questions.
Don't be afraid to work without AI sometimes.

And most importantly:

Don't Be Afraid to Build Something Bigger Than You Know How to Build

Because that's how you learn how to build it.