Comparisons / Postgres linters
RowShield vs Squawk: migration linting vs outcome verification
The short version
- Squawk is a linter for Postgres migrations: it flags dangerous or expensive DDL patterns before they merge, as a CLI and GitHub Action. RowShield is a scheduled monitor over the running Supabase project — policy posture, anon behaviour and drift after deploy.
- Choose Squawk when — your risk is the migration itself: locking hazards and unsafe DDL reaching production through an unreviewed PR.
- Choose RowShield when — your risk is what migrations ship: a clean diff can still disable RLS, add an always-true policy, or leave a bucket public — and nobody re-checks afterwards.
RowShield rules relevant here
Head to head: Squawk vs RowShield
| Capability | Squawk | RowShield | Edge |
|---|---|---|---|
| Pipeline stage | Pre-merge: migrations are linted as files before they touch any database. | Post-deploy: the running project is scanned on a schedule, indefinitely. | RowShield |
| Pattern focus | Dangerous DDL: locking hazards, unsafe column and constraint operations, trigger pitfalls. | Security semantics: policy shapes, exposure, key handling and observed anon access. | Parity |
| Policy-semantics regressions | Migration linting judges statement shapes; policy predicate semantics are outside its rule set. | RLS_TAUTOLOGY and MISSING_WITH_CHECK evaluate the resulting policy text in the catalog itself. | RowShield |
| Behaviour evidence | No requester: the analysis is static, over files. | A GET-only probe exercises the deployed API as the anon caller. | RowShield |
| CI ergonomics | A GitHub Action with annotations on the diff — a mature review-loop fit. | A CLI with CI-safe exit codes; no hosted annotation equivalent yet. | Squawk |
| Drift memory | Stateless by design: every run starts fresh. | Snapshot diffing labels every change created, resolved or regressed. | RowShield |
| Cost profile | Free and open source under its license, with a paid hosted GitHub Action available. | Free probe tier; monitoring plans are listed on the pricing page. | Squawk |
Column claims about Squawk are sourced below. Where the edge is theirs, the page says so — and the sections that follow explain why Supabase teams still pick RowShield.
What Squawk does
Squawk is a linter for Postgres migrations. It reads migration files and flags patterns the Postgres community has learned to fear: operations that take aggressive locks, column and constraint changes that can stall production, and trigger-related pitfalls. It ships as a CLI and a GitHub Action that annotates the pull request, and it began in the Supabase ecosystem before moving to independent open-source stewardship.
Its premise is sound and well-executed: the cheapest place to catch a dangerous migration is the pull request, before any database runs it. Nothing on this page argues with that premise.
Where the scopes differ
The stages differ first, and honestly: Squawk works pre-merge on files, RowShield works post-deploy on the running system. Those are complementary axes, not competing ones — a migration that lints clean can still ship a policy rewritten into an always-true predicate, RLS left disabled on a new table, or a bucket flipped public for one feature and forgotten. Squawk judges statement shapes; it does not evaluate what the statements mean for the policy landscape, and it has no view of the database after they run.
Mapped onto RowShield's three lenses: Squawk holds a slice of posture — the DDL patterns it knows — at a point in time; it holds no behaviour evidence (nothing is executed as a caller); and it holds no time axis (every run is stateless). RowShield holds catalog posture on every scan, the GET-only probe against the deployed API, and snapshot diffing that labels every change created, resolved or regressed.
The asymmetry runs the other way too, and the table says so: Squawk's GitHub Action with diff annotations is a better review-loop fit than anything RowShield ships today, and its DDL-hazard rules cover ground RowShield deliberately does not.
Why Supabase teams choose RowShield over Squawk
Because the question "did the migration break the policy layer?" has a second half: "and did anything change since?" RowShield answers both on a schedule. Nine shipped rules cover RLS_DISABLED tables, RLS_TAUTOLOGY predicates, MISSING_WITH_CHECK clauses, UNINDEXED_RLS_PREDICATE cases, unwrapped auth.uid() calls, PUBLIC_BUCKET_EXPOSURE, ANON_TABLE_READABLE tables and SERVICE_ROLE_KEY_EXPOSED bundles — checked daily to every fifteen minutes by plan, with alerts on transitions only.
A regression — last month's fix reverted by this month's migration — is named as a regression, which is the finding a stateless pre-merge linter structurally cannot produce. Remediation SQL is generated from your real columns, and the CLI keeps a gate in CI.
Where Squawk is the right choice
For teams whose dominant risk is the migration itself — large tables, locking hazards, constraint rebuilds — Squawk earns its place in every pull request, and it is free. Its DDL-hazard focus is deeper than RowShield's, which does not lint migration files at all. Keep it for the merge gate; the two tools watch different halves of the same pipeline.
Using both
The strongest setup is both: Squawk gates the merge, RowShield watches reality afterwards. When the combination disagrees — a lint-clean migration followed by a scan reporting a regressed policy — that is not a contradiction; it is the two tools telling the truth about different layers, and the discrepancy itself is the signal worth investigating.
Frequently asked
- Is RowShield affiliated with the Squawk maintainers?
- No. RowShield is an independent product by Veristria, unaffiliated with the Squawk project and its maintainers. Squawk is referenced descriptively and remains the mark of its project.
- Can I use RowShield and Squawk together?
- Yes, and that is the recommended setup: Squawk lints migrations before they merge; RowShield verifies the running project afterwards and alerts on drift and regressions between deploys.
- We lint every migration with Squawk — can a broken policy still reach production?
- Yes. Squawk's rule set addresses DDL patterns, not the semantics of the policies migrations create or the behaviour of the API afterwards. A migration can pass every Squawk rule and still ship an always-true policy or leave RLS disabled, which is what post-deploy verification catches.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit