Security & accessadvancedPro runbook

Your RLS policy does not apply to the table owner

Row level security was enabled and a policy was in place, yet the table owner still read every row: 2 of 2. FORCE ROW LEVEL SECURITY dropped the owner to 0, and a role holding BYPASSRLS still read all 2.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

Row level security is usually adopted for tenant isolation, then verified by connecting as an ordinary user and watching the rows disappear. That test passes while the application, which typically connects as the table's owner, is exempt. The behaviour is documented rather than a bug, which is precisely why it survives code review: nothing errors, nothing warns, and the policy is genuinely there.

Meridian added RLS to isolate tenants, tested it as a read-only reporting role, and shipped. The application connects as the role that owns the tables, so every request still returns every tenant's rows.

Simple terms

Row level security is a filter PostgreSQL adds to queries so each user only sees their own rows. There is a catch that catches almost everyone: the user who owns the table is exempt from that filter by default. So you can enable RLS, write a correct policy, test it with some other login, see it work, and still have your application read everything, because your application logs in as the owner. Making the owner obey the filter is a second, separate command. And two kinds of account ignore the filter no matter what you do.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify your rls policy does not apply to the table owner, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist, the exact signals that tell you it's this incident
  • Every diagnostic query; lab output is attached only to the steps we actually captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

Card required. Cancel before day 7 and you are not charged.

Compare plans

Connected

How this connects to the rest of the library

A live view of this page's real cross-references, what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.

Open in the interactive map →
ShareLinkedInX

Need the full procedure?

Pro runbooks finish the incident path

Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.

FollowSubstackLinkedInnew errors · lab notes · hiring loops