Comparisons / Schema diff & drift
RowShield vs Flyway: versioned SQL versus continuous assurance
The short version
- Flyway applies numbered, versioned SQL migrations and records which versions ran; its Teams editions document drift detection comparing resolved migrations against the database. RowShield is a scheduled Supabase monitor whose checks target authorisation posture and live behaviour, independent of how migrations were applied.
- Choose Flyway when — your team wants battle-tested, version-controlled SQL migrations wired into application startup or CI.
- Choose RowShield when — you want the security outcome watched continuously — policies, buckets, keys, anon readability — with alerts when anything regresses, whichever tool moved the schema.
RowShield rules relevant here
Head to head: Flyway vs RowShield
| Capability | Flyway | RowShield | Edge |
|---|---|---|---|
| Migration execution | Applies pending versioned scripts in order and records them in a schema history table. | Does not apply migrations; audits the resulting state whatever applied it. | Flyway |
| Drift detection | Documented in Teams editions: compares the resolved migration history against the live database. | Built into every scan on every plan: full-posture snapshots diffed against the previous scan. | RowShield |
| What drift means here | History mismatch — something changed relative to what the recorded versions imply. | Security-state movement: policy rewrites, disabled RLS, bucket flips, newly readable anon tables. | RowShield |
| Policy evaluation | Scripts are applied verbatim; their authorisation consequences are not analysed. | Conditions and coverage are machine-checked: RLS_TAUTOLOGY, RLS_NO_POLICIES, MISSING_WITH_CHECK. | RowShield |
| Application-surface testing | Database-side only; the HTTP/API layer a Supabase client actually uses is untouched. | GET-only probe exercises PostgREST as the anon role and reports per-table readability. | RowShield |
| Alert routing | Reports through its command runs and your surrounding tooling. | Slack Block Kit, Discord embeds, HTML email and webhooks with per-destination severity thresholds. | RowShield |
| Ecosystem maturity | Long-established migration standard with broad framework integrations. | Focused, younger product scoped to Supabase. | Flyway |
Column claims about Flyway 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 Flyway does
Flyway popularised versioned SQL migration: scripts named V1__, V2__ and onward are applied in order, tracked in a history table, and reversible steps can be supplied. Redgate maintains community and commercial editions; the Teams-tier documentation describes drift detection that checks the database against the resolved migration history, and we link rather than price it here.
The design assumption is pipeline-shaped: the database’s truth is the sum of applied versions, and anomalies are deviations from that sum. For applications owning their schema end to end, that is a sound mental model with a long operational record.
Where the scopes differ
Supabase breaks the assumption politely but completely. Projects change through the dashboard, the SQL editor, storage settings and increasingly AI assistants — none of which produce a Flyway version. History-based drift detection therefore reports the happy path accurately and the real path not at all: the Tuesday-night dashboard edit leaves no version behind to disagree with.
Even on-path, drift detection compares structure to history, not safety to intent. A committed V17 that rewrites a policy to USING (true) is, by Flyway’s model, perfect convergence: the database now matches its versions. Only a semantic reader objects — which is precisely what RowShield’s rules are. RLS_TAUTOLOGY reads the condition; MISSING_WITH_CHECK inspects write coverage; RLS_DISABLED checks the flag itself.
Last, the client surface. Supabase apps meet the database through PostgREST, and whether the anon key can read a table is observable only by requesting it. Flyway operates below that layer by design; RowShield’s probe operates exactly there.
Why Supabase teams choose RowShield over Flyway
Flyway answers "did my scripts apply"; the anxious 2 a.m. question is "can strangers read my rows right now". RowShield answers the latter on a schedule — up to every fifteen minutes — with nine Supabase-specific rules and a GET-only probe, alerting on transitions so a fixed-then-reverted problem announces itself as a regression.
Setup is a URL for the free probe and a connection string for full monitoring on a paid plan; no agent joins your build, and nothing about your migration tooling must change. Every finding carries generated remediation SQL with FORCE ROW LEVEL SECURITY, and the CLI exposes identical checks with CI exit codes for teams who want them beside their Flyway step.
Where Flyway is the right choice
If your service owns its schema and you want mature, boring-in-the-best-way versioned migrations embedded in startup or CI, Flyway remains an excellent default and its ecosystem integrations are real. We use words like excellent deliberately: execution and versioning are jobs we do not do.
Mixed-database shops standardising on one migration tool across engines should also stay put.
Using both
Keep Flyway as the engine of change; add RowShield as the auditor of outcomes. Versions prove order and reproducibility; continuous scans prove that what shipped still protects, including everything that arrived outside version control.
RowShield reads pg_catalog metadata only and is built by Veristria, independent of Redgate Software Ltd.; Flyway is referenced descriptively and remains a trademark of its owner.
Frequently asked
- Is RowShield affiliated with Redgate or Flyway?
- No. RowShield is built by Veristria, an independent company, and is neither endorsed by nor affiliated with Redgate Software Ltd. Flyway is referenced descriptively; edition capabilities are described conservatively and linked, not priced, here.
- Is RowShield a good Flyway alternative?
- For executing versioned migrations, no — Flyway is the established tool and we recommend keeping it. For continuous verification that the migrated database remains private on Supabase, yes: drift detection over policies and behaviour is RowShield’s core job, on every plan.
- Do we need to migrate our scripts to use RowShield?
- No. RowShield changes nothing about how you apply migrations. It reads catalog metadata and probes the public surface on a schedule, so it works alongside Flyway, golang-migrate, raw SQL or no formal tooling at all.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit