Postgres row-level security does nothing for the role your Symfony app connects with

The column that decides everything is the last one in the diagnostic. The status query in the dev.to post prints current_user, is_superuser, has_bypassrls, table_owner, rls_enabled and rls_forced, and on the throwaway database it reads app, f, f, app, t, f ^[4]. Five of those six values are what a reviewer wants to see. The sixth is the one that governs whether the policy on that table runs at all ^[1].

The arithmetic is short. Two invoices, one per organization, and a count of 2 from a connection that set no tenant at all ^[5]. That is every row in the table, 100 percent of it, through a policy that was enabled and correctly written ^[14]. After FORCE ROW LEVEL SECURITY, the same connection running the same query against the same policy returns 0, and returns 1 once the tenant setting is present ^[6]. Nothing about the predicate changed between those two results ^[16].

What makes this a deployment problem rather than a documentation footnote is ownership. A Symfony app has one DATABASE_URL, so the role that ran doctrine:migrations:migrate is the role that serves the request, and the role that created the table owns it ^[7]. Deploy guides arrive there honestly: creating the database owned by the app role is what lets migrations run without a hand-written privilege grant ^[8]. Postgres does not treat the arrangement as unusual, and the manual says table owners "normally" bypass row security, in a sentence most people read once while looking for CREATE POLICY syntax ^[1].

The thread that produced this started with a commenter, @to21as, reporting two RLS bugs that were both invisible in tests because the test connection was a superuser ^[12]. The obvious lesson from that is to stop testing as superuser, and it is not enough. A plain non-superuser role that happens to own the tables behaves the same way, because ownership is a separate bypass from the superuser one ^[1]. The fixtures conceal it in either case: seeding one organization and asserting that its user sees its own row passes identically whether the policy applies or is inert ^[10]. The assertion that fails is the negative one, and a suite without it stays green on the day enforcement stops ^[10].

The failure direction is what carries this through code review. Too many rows, not too few ^[9]. A filter that returns nothing is found in seconds; a filter that returns everything renders a page that looks correct ^[9]. What ships is not weakened isolation, it is the state the database was in before any policy was written.

The remedy in the article is one statement per table, added to the migration that already enables RLS ^[13]. The check is that same six-column query, run in production as the application role: rls_enabled true, rls_forced false, table_owner equal to current_user, and the policy is decoration ^[4][1].