Comparisons / Migration frameworks
RowShield vs Prisma Migrate: model sync versus policy verification
The short version
- Prisma Migrate generates SQL migrations from your schema.prisma and keeps the database aligned with it; db pull introspects a database back into the schema file. RowShield is a continuous Supabase monitor covering everything that model-first workflow cannot express: row level security, storage exposure, key leakage and observed anon behaviour.
- Choose Prisma Migrate when — your TypeScript stack treats schema.prisma as the single source of truth and you want migrations derived mechanically from model changes.
- Choose RowShield when — your database is Supabase and you need proof the authorisation layer survived the migration — checked on a schedule, with regressions named as such.
RowShield rules relevant here
Head to head: Prisma Migrate vs RowShield
| Capability | Prisma Migrate | RowShield | Edge |
|---|---|---|---|
| Source of truth | schema.prisma: models define tables, columns and relations; SQL follows the models. | The live catalog: scanned directly, so dashboards and manual SQL count equally with generated files. | RowShield |
| Expressive boundary | Documents note features beyond the schema language require customisation or raw SQL handling. | Purpose-built for what sits outside ORM schemas: policies, grants, buckets, platform keys. | RowShield |
| Drift story | Divergence appears as database state disagreeing with schema.prisma, found via introspection. | Any posture movement between scans — including policy edits Prisma never models — diffed and classified. | RowShield |
| Policy semantics | Row level security is not part of the modelling vocabulary, so its correctness is unchecked. | RLS_TAUTOLOGY, RLS_NO_POLICIES and MISSING_WITH_CHECK evaluated per table and role, every scan. | RowShield |
| Runtime behaviour | Build-time tooling; nothing queries the running API surface. | GET-only probe requests PostgREST as the anon role and records readable tables. | RowShield |
| Developer experience in TS stacks | First-class: typed clients, studio tooling and migration workflow feel like one product. | Independent dashboard and CLI; complements rather than integrates. | Prisma Migrate |
| Storage and key exposure | Outside the schema file’s scope entirely. | PUBLIC_BUCKET_EXPOSURE and SERVICE_ROLE_KEY_EXPOSED ship among the nine rules. | RowShield |
Column claims about Prisma Migrate 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 Prisma Migrate does
Prisma Migrate, documented at prisma.io, derives SQL migrations from the declarative schema.prisma file: edit models, generate a migration, apply it, and the database follows the file. db pull reverses the direction, introspecting an existing database into schema form so brownfield projects join the workflow. The docs, reviewed 2026-08-23, position this as the route to keeping database and models synchronised in TypeScript codebases.
Within its boundary it is polished, and the boundary is the point: the schema language describes relational structure. Authorisation primitives such as row level security policies, storage bucket rules, and the Supabase key split are not modelling concepts, so the workflow neither manages nor evaluates them.
Where the scopes differ
Model-first development concentrates attention on the mapped surface: fields, relations, indexes. Security on Supabase lives almost entirely off that map. Policies attach to tables the ORM sees as bare relations; a migration generated from a clean model diff can happily recreate a table without policies, or a hand-patched policy can carry USING (true) that no model linter will ever read, because the model layer has no opinion on policy text at all.
Introspection narrows nothing here: db pull reflects structure back into schema.prisma, and structure is exactly the part that was fine. The dangerous drift is behavioural — what the anon role can fetch — and it is decided by PostgREST at request time, downstream of every schema file.
RowShield completes the picture from the other side: scheduled catalog scans evaluate the authorisation objects themselves, the probe exercises the public surface as a visitor would (GET only), and every change since the last scan is labelled created, resolved or regressed so a reverted fix cannot masquerade as news.
Why Supabase teams choose RowShield over Prisma Migrate
Not instead — alongside, and here is why the addition earns its place. Prisma Migrate optimises for developer velocity on structure; RowShield assumes velocity wins and asks the follow-up question automatically: did this week’s four generated migrations change who can read what? Nine rules answer it — RLS_DISABLED, RLS_TAUTOLOGY, MISSING_WITH_CHECK, PUBLIC_BUCKET_EXPOSURE, SERVICE_ROLE_KEY_EXPOSED among them — and the probe confirms behaviour end to end.
Integration cost is a URL for the free probe and a read-only connection string for full monitoring on a paid plan. Alerts reach Slack, Discord, email or webhooks on transitions only; remediation SQL arrives generated from your columns with FORCE ROW LEVEL SECURITY included; and the same engine runs in CI through the CLI with proper exit codes beside your prisma migrate step.
Where Prisma Migrate is the right choice
For keeping a TypeScript codebase and its database in mechanical agreement, Prisma’s workflow is genuinely good and we recommend it for that job without qualification. Typed clients generated from schema.prisma remain a strong reason to stay in the ecosystem.
Greenfield teams who want migrations to be a build artifact of models — and whose platform is not Supabase — lose little by skipping this page’s subject matter entirely.
Using both
The division is clean: Prisma Migrate produces the structure; RowShield continuously verifies the protection around it. Keep the migration workflow; add scheduled policy, storage and behaviour checks so the unmapped layer stops relying on memory.
RowShield reads pg_catalog metadata only and is built by Veristria, independent of Prisma Data Inc.; Prisma is referenced descriptively and remains a trademark of its owner.
Frequently asked
- Is RowShield affiliated with Prisma?
- No. RowShield is built by Veristria, an independent company, and is neither endorsed by nor affiliated with Prisma Data Inc. Prisma Migrate is referenced descriptively based on public documentation.
- Is RowShield a good Prisma Migrate alternative?
- For generating migrations from schema.prisma, no — that workflow is Prisma’s strength and we advise keeping it. For continuous verification of RLS policies, storage exposure and anon behaviour on Supabase, yes: RowShield monitors precisely the layer the schema file cannot express.
- Can Prisma Migrate manage my RLS policies so I don’t need monitoring?
- Policies fall outside the schema language, so teams typically handle them in custom SQL within migrations or separately. Even when scripted, nothing evaluates their meaning — a tautological condition migrates as faithfully as a correct one. Monitoring checks the outcome either way.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit