The RLS Field Guide

Row-Level Security in Supabase, from first principles to proven isolation

A RowShield handbook · First edition, August 2026

RowShield is an independent product and is not affiliated with, endorsed by, or sponsored by Supabase, Inc.

---

Who this book is for

You have a Supabase project. You did not necessarily design its authorization model — a generator may have produced the schema, an assistant may have written the migrations, and the row-level security policies, if any, arrived after the fact. You want to reach the point where you can say, with evidence rather than hope: no user of workspace A can read workspace B's rows, and I can prove it.

That is the whole arc of this book. It starts with what actually happens to a request between your browser and Postgres, and ends with isolation that is enforced by policies, demonstrated by tests, and protected against drift by your own maintenance loop.

What you need

• Any Supabase project you can safely experiment on. A free local project (supabase start) is ideal; a disposable hosted project also works.
• Access to the SQL Editor, or psql connected to your project.
• Nothing else. Every example runs as plain SQL. No application code is required, and no example depends on data that is not created in the same section.

Run everything on a throwaway or development project. Several chapters deliberately create insecure objects so you can watch them fail; those sections say so, and every demonstration transaction ends in rollback. Do not paste migration examples into production without reading them — that habit of reading before running is half of what this book teaches.

The example project

Every chapter advances one fabricated project: TaskHarbor, a two-tenant task app. Two workspaces — Aster Labs and Borealis Design — each own projects, and each project owns tasks. Members belong to workspaces through a membership table.

TaskHarbor is invented for this book, disclosed here as invented, and kept deliberately small. Every UUID in it is a fixed literal so that queries return identical results on your machine. It resembles no real product, and any resemblance to real data is coincidental.

The complete schema, policy set, and seed data appear in Chapter 3, and again consolidated in Appendix C so you can rebuild TaskHarbor from one file at any time.

How chapters work

Each chapter opens with the single question it answers, contains SQL you can run as written, and closes with Check on your project items — short audits you can perform on your real project today. Those checklists accumulate into Appendix A, which becomes a full audit checklist you can reuse every release.

The map

1. The authorization chain — who Postgres thinks is asking.
2. Policy anatomy — what a policy promises, clause by clause.
3. The first policy set — TaskHarbor gets complete policies, then proves them.
4. The drift taxonomy — five ways secure projects become insecure.
5. The afternoon audit — the complete manual audit method.
6. The five isolation proofs — tests that prove tenant boundaries, wired into CI.
7. Multi-tenancy patterns — tenant_id, schema-per-tenant, project-per-tenant compared.
8. Beyond the tables — storage, realtime, functions, views.
9. Performance without weakening — fast policies, so nobody reaches for the off switch.
10. Keeping it true — the maintenance loop that resists drift structurally.

Sources

Statements about Supabase and Postgres behavior in this book link to official documentation: the Supabase RLS guide, the Postgres CREATE POLICY reference, the Postgres row security chapter, Storage access control, Realtime Postgres Changes, and database testing. When this book and a doc page disagree after a future release, trust the docs and file the difference where you keep your notes.