RowShield vs Rails migrations: schema DSL versus policy verification

Head to head: Rails ActiveRecord migrations vs RowShield

Column claims about Rails ActiveRecord migrations 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 Rails migrations do

ActiveRecord migrations, covered in the Rails guides, let teams evolve schemas in Ruby: create_table, add_column and friends compile to SQL, db:migrate applies pending versions in order, and schema.rb is regenerated as a summary of the resulting structure. The workflow is mature and pleasant, and rollback discipline is part of its appeal.

The DSL expresses relational structure; row level security is not among its verbs. Teams secure Supabase-backed tables with raw execute() SQL inside migrations or entirely outside the framework — and both routes share a property: nothing downstream reads what the policy says, only whether it ran.

Where the scopes differ

schema.rb illustrates the boundary neatly: it summarises tables, columns and indexes, while policies and grants typically appear only when using the SQL structure dump — a hint that the primary record of the database and its authorisation layer are separate worlds. A migration can rebuild a table perfectly by DSL standards and omit the policies that made it safe; the framework will call the result complete because, within its vocabulary, it is.

Time divides the tools further. Rails migrations act at deploy moments; Supabase projects change between them through dashboards, SQL editors and AI suggestions that no migration records. RowShield samples continuously — catalog snapshots every scan, diffed against the last, each change classified created, resolved or regressed.

And the decisive property is behavioural. Whether the anon key retrieves rows is determined by PostgREST per request, downstream of every schema dump. RowShield’s probe issues GET requests exactly as a visitor would and reports which tables respond with data.

Why Supabase teams choose RowShield over Rails migrations

The searcher here usually inherited a Rails monolith talking to Supabase and wants one thing: confidence that the authorisation layer survived the last six migrations and last week’s dashboard session. RowShield supplies it mechanically — free probe from a URL, full monitoring on a paid plan, scans up to every fifteen minutes, nine Supabase-specific rules including PUBLIC_BUCKET_EXPOSURE and SERVICE_ROLE_KEY_EXPOSED.

Every finding carries remediation SQL generated from your columns with FORCE ROW LEVEL SECURITY, and alerts fire only on transitions so noise stays near zero. The CLI exposes the identical engine with CI-safe exit codes, slotting beside bin/rails db:migrate without touching it.

Where Rails migrations are the right choice

For schema evolution in a Rails application, the built-in machinery is the right answer and needs no advocacy from us. Versioned, reversible, self-summarising migrations are a genuine strength of the framework.

Teams whose database serves no third-party surface may reasonably decide that continuous authorisation monitoring solves a problem they do not have.

Using both

Keep db:migrate authoritative for structure; let RowShield certify the protection around it between deploys. The framework owns the DSL-shaped half of the database; scheduled verification owns the half written in policy text.

RowShield reads pg_catalog metadata only and is built by Veristria, unaffiliated with the Rails project; Rails is referenced descriptively as open-source software.

Frequently asked

Is RowShield affiliated with the Rails project?

No. RowShield is built by Veristria, an independent company, and is neither endorsed by nor affiliated with the Rails project or its maintainers. ActiveRecord migrations are referenced descriptively based on the official guides.

Is RowShield a good Rails migrations alternative?

For evolving schemas inside a Rails app, no — the framework’s migrations are the right tool and should remain in place. For continuous verification of Supabase policies, storage and anon behaviour, yes: RowShield monitors the layer the DSL cannot express.

Our policies live in execute() blocks inside migrations. Are we covered?

Partially, at best. Migration runs replay that SQL without interpreting it, and nothing rechecks the outcome later. A policy edited in the dashboard afterwards, or a fix reverted next month, escapes the migration record entirely — the situations scheduled scanning exists for.