pgTAP-style test harnesses versus managed RLS monitoring
pgTAP-style harnesses are among the best tools in the Postgres world for asserting behaviour: write tests as code, run them against a database you point them at, fail the build when reality disagrees with intent. For row-level security they are excellent — a suite can sign in as a role, request rows, and assert exactly what should and should not come back.
Managed continuous testing answers a different question. Rather than asking will the next deploy behave, it asks is production behaving now — on a schedule, without test authoring, across changes nobody wrote a test for. This page draws the boundary at category level, because the honest conclusion is complement, not replacement.
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.
What harness tests give you
A harness expresses intent with precision. Tests like tenant A must not read tenant B's invoices, even as tenant B, become executable artifacts reviewed in pull requests and run on every merge. When one fails, it fails at a specific assertion with a specific fixture, which makes the diagnosis short.
The suite doubles as documentation of the access model. New engineers read the tests to learn who may see what, and contested edge cases get settled by adding an assertion rather than winning an argument — a property few other artifacts offer.
Where the ceiling sits
Harnesses run when run. Between runs — evenings, weekends, the week everyone is heads-down shipping — nothing asserts anything about the database, and the database keeps changing anyway: console hotfixes applied under pressure, manual restores, migrations whose policy lines were thinner than the tests assumed they were.
Fixtures age, too. A suite written against last quarter's schema silently loses coverage as columns rename and tables multiply, and environments diverge: the CI database differs from production in data volume, extensions and accumulated state. Tests pass against a neighbour of the system users actually depend on.
What continuous monitoring adds
Monitoring inverts the model: no authoring, no fixtures, a fixed set of checks applied to the live project on a schedule — daily on Free, hourly on Indie, every fifteen minutes on Team. Catalog rules evaluate disabled, absent and tautological policies, missing WITH CHECK clauses, public buckets, unindexed predicates, unwrapped auth calls and key exposure; a probe asks the deployed API what an anonymous caller receives.
Results arrive as transitions — created, regressed, resolved — delivered to destinations such as Slack Block Kit, Discord embeds, HTML email or a generic webhook, each with its own severity threshold. The value is coverage of the unauthored: changes nobody thought to test are still compared against the previous scan.
Running both, deliberately
The combination is stronger than either half: the harness gates merges with intent-specific assertions; monitoring watches runtime for everything the suite never encoded, and catches the moment a tested guarantee stops holding in production. Neither needs to pretend to be the other.
RowShield occupies the monitoring side of that split and stays out of your test suite entirely — no assertions to author, no fixtures to maintain. If you want the outside view of your project today, the free audit at rowshield.dev/audit takes nothing but a URL and returns findings with their reproducible queries.
Frequently asked
- Should we replace our pgTAP suite with monitoring?
- No — they answer different questions. Harness assertions encode intended behaviour and gate merges; scheduled monitoring watches production for changes nobody authored a test for. Teams generally keep both and let each do its own job.
- Does RowShield generate or maintain test suites?
- No. RowShield applies its own fixed rule set to your live project on a schedule and reports transitions. Writing intent-specific assertions about your domain remains exactly what test harnesses are good at.
- What does monitoring catch that a CI suite structurally cannot?
- Anything that reaches production without passing through CI: console edits, direct sessions, restores rolling schema backwards, and drift between what tests assume and what migrations shipped. Scheduled scans compare live state against the previous scan, whatever path produced it.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit