Why is GRANT to PUBLIC dangerous?
Write privileges granted to PUBLIC
Warning: this works, but blocks traffic or rewrites data at scale.
What happens
GRANT ... TO PUBLIC applies to every role the cluster has now, and every role created later, forever. Granting write privileges (or ALL) on a table to PUBLIC turns one migration line into a standing policy that no future account can be excluded from.
Why it is dangerous on a populated table
It completes, but the time it holds its lock or rewrites rows scales with the table, and on a busy one that is long enough for traffic to queue.
Fires on
GRANT ALL ON orders TO PUBLIC;The safe pattern
Grant to the specific role that needs the access, service roles for writes, a read-only role for reporting. PUBLIC is every current and future role; a named role is a decision you can see and revoke.
GRANT SELECT ON orders TO reporting;
GRANT INSERT, UPDATE ON orders TO orders_service;Fixtures
The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.
Fires (1)
GRANT ALL ON orders TO PUBLIC;Stays silent (2)
GRANT INSERT, UPDATE ON orders TO orders_service;-- Read-only PUBLIC grant: visible, but not the write-widening trap.
GRANT SELECT ON orders TO PUBLIC;How to check locally
This rule runs in the hosted service on Startup and above: add --remote with a team token, or use the GitHub Action. No install, nothing leaves your machine:
npx bolvrk check migration.sql --remote