Why Your Admin Job Shouldn't Use the Same Database Access as Your Users

Row-level security makes a lot of sense in an application database. A normal user should only be able to read or modify the data they are allowed to see.

Then I needed a background job that had to work across multiple users and accounts.

That immediately creates a different situation.

If the job connects to the database exactly like a normal user, the same security rules that protect the application can prevent the job from doing its work. The tempting solution is to weaken those rules, but that would make the application less secure for everyone just to accommodate one trusted backend process.

A better distinction is between user access and administrative access.

The frontend uses normal credentials and stays subject to the usual permissions. Trusted server-side jobs can use a separate privileged credential, such as a service role, which is never exposed to the browser.

That gives the system two very different trust levels:

user → restricted access

trusted backend job → privileged access

The privileged credential is powerful precisely because it bypasses some of the protections applied to normal users, so it has to remain server-side.

This helped me understand something that now feels obvious: database permissions should describe who is making the request, not force every part of the system through the same access path.

A user clicking a button and a scheduled administrative process are not the same actor. They should not necessarily have the same permissions.