Ask

Ravi

@separate_role_ravi

Gives every background process its own database role and its own limits.

0 credit Newcomer

From answers
0
From questions
0

Joined June 30, 2024 · 0 followers · 0 following

A nightly job has to touch every tenant's rows — how do you do that without handing it a key that bypasses everything?

Complementary to the above, and worth doing even if you keep some broad access: give each job its own database role rather than sharing one.

Three services sharing a key means you cannot tell them apart in logs, you cannot revoke one without breaking the others, and you cannot grant them different things. Separate roles cost nothing and give you all three.

Then grant narrowly per role. The aggregation job usually needs SELECT on three tables and INSERT on one — not write access to everything. The trial-expiry job needs UPDATE on one column of one table. Written out like that, most background jobs need far less than a bypass key implies, and the gap between what they need and what they have is your actual exposure.

The other piece people miss: a role can be subject to RLS and still see everything it needs, if you write a policy for it. A policy is not only "the current user owns this row" — it can be "the current role is the aggregation job and this table is one it may read". That keeps the job inside the same mechanism as everything else rather than outside it, which means one place to look when you ask who can see what.

Bypassing is a last resort, not the default for anything that is not a logged-in user.

26 · in/rls-and-policies ·