You fixed it Monday; it was back by Friday
Fixed it Monday, verified it Tuesday, and by Friday the same finding is back: the table unreadable again, the policy gone, the flag flipped. Nobody un-fixed it — nobody touched it. That is the signature of a regression, and it is a different animal from a new mistake: somewhere, a process is restoring yesterday, and your fix keeps losing the argument.
Scope note first, in the interest of honesty: regression detection is not one of RowShield's nine named rules, and this page accordingly carries no rule backing. What the product ships is drift diffing — comparing consecutive scans and labelling each change created, regressed or resolved — and that classification is shipped behaviour rather than a named rule. The rest of the page is about the phenomenon and the process around it.
RowShield does not detect this yet. This guide gives you the catalog queries to check it yourself. The nine rules that do ship are listed on the rules index.
Regression is a process finding
A new finding says the system sprang a leak here. A regression says the system contains something that undoes repairs. The second is usually the more valuable discovery, because it names a defect in the delivery path — and defects in the delivery path manufacture every future finding too, not just this one.
The weekly rhythm in the title is diagnostic in itself. Repairs applied on Monday that die by Friday are being overwritten by something operating on a schedule — a sync, a promotion, a cron job replaying an old snapshot. Random chaos does not keep office hours; cycles do, and the calendar is telling you where to look.
Where fixes go to be undone
Four channels account for most of it. Restores resurrect the schema of the backup instant, holes included. Drop-and-recreate migrations rebuild tables without the policies the originals had accumulated. Console hotfixes repair production outside the repository, so the next promotion from an environment that missed the memo overwrites them. And multi-environment setups sync in the wrong direction, letting a stale schema win.
Each channel shares a property worth naming: the undoing is never malicious and rarely noticed. Restore jobs run to recover; recreations happen because iteration is cheap; promotions overwrite because environments drifted. Process defects wear the clothing of ordinary operations, which is exactly why they survive retrospectives intact.
Break the cycle deliberately
The durable sequence is boring and effective. Single write path: all schema changes travel through reviewed migrations, and console edits to production become an incident rather than a habit. Post-change verification: the query below re-runs after every migration batch, converting hope into measurement:
SELECT c.relname AS table_name,
c.relrowsecurity AS rls_enabled,
c.relforcerowsecurity AS rls_forced,
(SELECT count(*)
FROM pg_catalog.pg_policies p
WHERE p.schemaname = 'public'
AND p.tablename = c.relname) AS policy_count
FROM pg_catalog.pg_class c
JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'p')
AND n.nspname = 'public'
ORDER BY c.relname;Keep dated artifacts
Keep dated outputs of every verification run. A regression is proven by comparison — Tuesday's output beside Friday's — and the diff usually names the mechanism by implication: policies at zero suggest recreation, an older table shape suggests restore. Memory argues; artifacts agree. Date-stamp them mechanically rather than by recollection, because the comparison that proves a recurrence depends entirely on knowing which output is older.
What monitoring adds to the loop
Scheduled scans turn the comparison into infrastructure. Each scan snapshots posture, diffs against the previous run, and labels outcomes created, regressed or resolved — the regression label arriving as an alert precisely because it indicates a process defect rather than a fresh slip. Retried scans stay idempotent, re-reading recorded history and emitting nothing new, so signal stays reserved for genuine change.
To repeat the scope honestly: the created-regressed-resolved classification is shipped drift-diffing behaviour, not one of the nine named rules, and no rule automates detecting a regression as such. RowShield is an independent product, unaffiliated with and not endorsed by Supabase. Run a free audit — no account — at rowshield.dev/audit, and let the first snapshot become the baseline your Fridays argue against.
Frequently asked
- Is a regression worse than a new finding?
- Usually, yes. A new finding is one mistake; a regression is evidence that something in your pipeline restores broken states and will keep manufacturing findings until identified. Monitoring systems reflect that by treating returns as their own, louder event.
- How do I prove it is really recurring?
- Keep dated outputs of the verification query and compare them. Two dated artifacts beat any recollection, and the diff between them frequently identifies the undoing mechanism — recreation, restore, or overwrite — by itself.
- Does this apply beyond RLS?
- The pattern is general: any configuration state a process can rebuild, a process can regress. Databases make it observable because the catalog records current truth, which is what makes diffing possible at all.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit