FORCE Row-Level Security
FORCE ROW LEVEL SECURITY is a Postgres setting that makes a row-level-security policy apply even to the table's owner and other privileged roles that would otherwise bypass it by default — closing a common isolation gap.
Postgres row-level security has a default exception that surprises a lot of people: table owners, and any role with the BYPASSRLS attribute, ignore RLS policies unless told otherwise. That default exists for good operational reasons — an administrator often needs unfiltered access for maintenance — but it means a plain RLS policy alone doesn't guarantee isolation if the application happens to connect using a privileged or owning role.
FORCE ROW LEVEL SECURITY removes that exception for the table owner specifically: once set, the owner's own queries are subject to the same policy as everyone else's. Combined with connecting the application as a genuinely least-privileged, non-superuser role (rather than the table owner or a role with BYPASSRLS), it closes the gap where "we have RLS" quietly didn't mean "RLS actually applies to us."
It's a small setting with an outsized effect on how much you can trust an RLS-based isolation story: without it, "RLS is on" and "isolation is enforced" aren't the same claim, because the exact role your application connects as determines whether the policy is actually being checked.
FORCE Row-Level Security, in the product
Aanty pairs RLS with FORCE on every tenant-scoped table, and the application connects as a non-superuser, non-owner role with no BYPASSRLS attribute — so "the policy exists" and "the policy is enforced" are the same statement. Least-privilege DB roles separate what the app, the publisher, backups and redaction jobs can each touch.
Related terms and pages
See FORCE Row-Level Security in a real workspace
Bring a channel from wherever your team works today. In fifteen minutes we'll show what force row-level security looks like on a real conversation, not a slide.