Comparisons / Migration frameworks
RowShield vs Alembic: autogenerated revisions versus live policy watch
The short version
- Alembic is the Python migration framework for SQLAlchemy: revisions are versioned scripts, and autogenerate compares your models’ metadata against the live database to propose a diff. RowShield is a continuous Supabase monitor covering what metadata does not describe — row level security, storage exposure, key leakage — and alerting when that layer changes.
- Choose Alembic when — a Python team wants deterministic, reviewable migrations derived from SQLAlchemy models.
- Choose RowShield when — your Supabase backend serves a public API and you want scheduled proof that policies held, with a behaviour probe and regression-labelled alerts.
RowShield rules relevant here
Head to head: Alembic vs RowShield
| Capability | Alembic | RowShield | Edge |
|---|---|---|---|
| Diff basis | SQLAlchemy Table metadata compared against the reflected database state. | Live catalog snapshots compared against each other, independent of any model file. | RowShield |
| Coverage boundary | Their documentation notes autogenerate renders what metadata represents and misses types it cannot compare. | Scoped to the unmapped majority of Supabase risk: policies, grants, buckets, keys. | RowShield |
| Policy awareness | Policies are not metadata concepts; they pass through as raw execute() lines at best. | Evaluated semantically each scan: constant-true conditions, absent WITH CHECK, missing coverage. | RowShield |
| Runtime verification | Offline generation and application; no requests touch the serving layer. | GET-only probe against PostgREST as the anon role, reporting per-table readability. | RowShield |
| Temporal coverage | Acts when a revision is generated or upgraded. | Scheduled scans from every fifteen minutes to daily, diffing every interval including non-Python ones. | RowShield |
| Alerting | Output lands in your terminal and revision files. | Slack, Discord, email and webhook notifications on created/resolved/regressed transitions. | RowShield |
| Python ecosystem fit | The default choice alongside SQLAlchemy, deeply integrated. | Language-neutral external monitor. | Alembic |
Column claims about Alembic 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 Alembic does
Alembic provides versioned database migrations for SQLAlchemy applications: each revision is a script with upgrade and downgrade paths, chained into a history. Its autogenerate feature, documented at alembic.sqlalchemy.org, compares the metadata declared in your models against the actual database and drafts a revision capturing the difference, for developer review before commit.
The documentation is candid about the mechanism: autogenerate reasons over metadata, so server defaults, certain type changes and anything outside the metadata model need manual handling. That honesty matters here — the set of things metadata cannot represent includes essentially the entire Supabase authorisation surface.
Where the scopes differ
Alembic’s world is the mapped schema; Supabase’s risk lives mostly in the unmapped remainder. A policy attached to a table is invisible to metadata, so autogenerate neither preserves nor evaluates it: dropping and recreating a table in a revision can discard its policies, and the generated script will look complete because, structurally, it is. Hand-written execute() lines carrying USING (true) migrate just as faithfully as correct ones.
Intervals matter too. Alembic acts at generation and upgrade time — moments. Between them, dashboards, SQL editors and AI assistants reshape the authorisation layer with no revision to show for it. RowShield samples continuously instead: catalog snapshots every scan, each diffed against the last, changes classified created, resolved or regressed.
Finally behaviour. Whether the anon key reads rows is settled by PostgREST per request. RowShield’s probe issues those GET requests as a visitor would and reports readable tables, converting an inference about policy text into an observation about served reality.
Why Supabase teams choose RowShield over Alembic
Python teams pick Alembic for disciplined structure and then discover nobody is watching the discipline’s blind spot. RowShield covers it without touching the workflow: the free probe takes a project URL; scheduled monitoring on a paid plan adds nine rule-backed checks — RLS_DISABLED, RLS_TAUTOLOGY, MISSING_WITH_CHECK, PUBLIC_BUCKET_EXPOSURE, SERVICE_ROLE_KEY_EXPOSED — evaluated against live catalog snapshots.
Alerts fire only on transitions, so a quiet week pages no one, and a reverted fix pages someone immediately with the word regression attached. Remediation SQL is generated from your columns with FORCE ROW LEVEL SECURITY, and the CLI brings identical checks into pytest-or-CI pipelines with meaningful exit codes.
Where Alembic is the right choice
For Python-and-SQLAlchemy codebases wanting deterministic, reviewable, reversible migrations, Alembic is the standard and deserves the position. Nothing on this page suggests replacing it; RowShield generates no migrations whatsoever.
Teams whose entire threat model is structural correctness at deploy time are adequately served by autogenerate plus careful review.
Using both
Keep autogenerate drafting your revisions; let RowShield watch what those revisions and everything besides them did to authorisation. Model-driven structure, continuously verified protection — the two responsibilities never compete.
RowShield reads pg_catalog metadata only and is built by Veristria, unaffiliated with the SQLAlchemy project; Alembic is referenced descriptively as open-source software.
Frequently asked
- Is RowShield affiliated with the SQLAlchemy or Alembic projects?
- No. RowShield is built by Veristria, an independent company, and is neither endorsed by nor affiliated with the SQLAlchemy project or its maintainers. Alembic is referenced descriptively based on its public documentation.
- Is RowShield a good Alembic alternative?
- For managing Python migration revisions, no — Alembic is the right tool and we recommend keeping it. For continuous monitoring of the policies, storage and keys that SQLAlchemy metadata cannot express on Supabase, yes: that is the gap RowShield fills.
- Can autogenerate capture my RLS policies into revisions?
- Policies are outside SQLAlchemy metadata, so autogenerate does not render them; teams typically add raw SQL by hand. Even then nothing evaluates the policy text, which is how tautological conditions travel unnoticed — the case automated monitoring exists for.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit