Comparisons / Platform-native
RowShield vs Amplify auth rules: schema rules vs live RLS checks
The short version
- Amplify Data lets you declare authorisation on the schema with auth() directives, which the framework compiles into AppSync resolvers backed by AWS services. RowShield is a scheduled monitor that verifies Supabase PostgreSQL RLS: policy posture, live anon behaviour and drift.
- Choose AWS Amplify auth rules when — your backend is committed to AWS — Cognito identity, AppSync, DynamoDB — and schema-declared authorisation fits your pipeline.
- Choose RowShield when — your backend is Supabase, or you are migrating to it, and you want the resulting policy layer verified continuously instead of trusted once at generation time.
RowShield rules relevant here
Head to head: AWS Amplify auth rules vs RowShield
| Capability | AWS Amplify auth rules | RowShield | Edge |
|---|---|---|---|
| Authorisation model | Declared on the schema with auth() directives and compiled into AppSync resolvers. | PostgreSQL RLS policies declared in SQL and enforced by the database engine itself. | Parity |
| Generation safety | Schema-to-resolver generation removes a whole class of hand-written resolution gaps. | Nothing is generated; existing policy SQL is read exactly as it stands in the catalog. | AWS Amplify auth rules |
| Continuous verification | Enforcement happens per request; no standing audit of the accumulated rule set. | Scheduled scans re-read posture and diff it against the previous snapshot. | RowShield |
| Live behaviour | Local sandbox mocking supports development-time checks you run yourself. | A GET-only probe tests the deployed PostgREST surface as the anon caller. | RowShield |
| Drift and regression | Console and pipeline changes surface through your own review process. | Changes are classified created, resolved or regressed and pushed to your alert channels. | RowShield |
| Ecosystem depth | Deep AWS integration: Cognito identity, IAM, AppSync features. | Deliberately narrow: Supabase Postgres, storage and deployed client bundles. | AWS Amplify auth rules |
| Cost profile | Charged through AWS component usage. | Free probe tier; monitoring plans are listed on the pricing page. | AWS Amplify auth rules |
Column claims about AWS Amplify auth rules 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 Amplify auth rules do
In Amplify Data, authorisation lives on the schema: auth() directives on models and fields state who may read, create, update or delete, and the framework compiles those declarations into AppSync resolvers running against AWS services, with Amazon Cognito supplying identity. The schema is the single source of truth, and generation removes the hand-written resolution layer where gaps classically hide.
It is a well-engineered approach for AWS-committed teams, and credit where due: generating enforcement from a reviewed schema eliminates a category of omission that hand-written API layers produce routinely. This page concerns the other side of the trade — what happens after generation, on a platform whose authorisation model is SQL.
Where the scopes differ
The models differ structurally. Amplify's authorisation is compiled: the schema you reviewed becomes resolvers you do not read. Supabase's is declarative SQL enforced by the database engine for every path, including direct connections — which is stronger in one direction (nothing bypasses RLS) and more error-prone in another (policy SQL is hand-written and easy to get subtly wrong).
Mapped onto RowShield's three lenses: posture on Amplify is the schema itself, reviewable in one place; behaviour is checked in development through sandbox mocking that you run; and drift over time is surfaced by your own pipeline discipline. RowShield holds the Supabase side of all three: catalog posture on every scan, a GET-only probe against the deployed API, and snapshot diffs that name out-of-band changes as transitions.
For migrating teams the practical consequence is concrete: every auth() rule must be re-expressed as policy SQL, and the translation is where tautological predicates, missing WITH CHECK clauses and unwrapped auth.uid() calls appear. Generation trust does not transfer across that boundary; verification has to.
Why Supabase teams choose RowShield over Amplify auth rules
For teams landing on Supabase, the question is no longer "did the generator compile my schema?" but "what does the policy layer actually permit, and did it change since Tuesday?" RowShield answers that on a schedule: nine shipped rules over RLS state, tautologies, missing WITH CHECK, unindexed predicates, unwrapped auth calls, bucket exposure, anon-readable tables and leaked service_role keys; a GET-only probe as the anon caller; transition alerts to Slack, Discord, email or webhooks; remediation SQL generated from your columns; and a CLI with CI-safe exit codes.
Nothing needs regenerating for RowShield to see the truth — the database is the source of truth, and RowShield reads it directly.
Where Amplify auth rules are the right choice
For an organisation already invested in AWS — Cognito for identity, IAM for infrastructure, AppSync for the API layer — Amplify is the coherent choice, and its schema-declared authorisation is a real strength worth keeping. RowShield monitors Supabase projects; it does nothing for AppSync resolvers or DynamoDB, and this page does not pretend otherwise. The comparison is decisive at the platform decision and on the migration path.
Using both
During a staged migration both stacks run at once: Amplify keeps serving the origin while the Supabase leg grows under RowShield's watch. After cutover, the discipline worth carrying over is the one generation gave you — authorisation that is explicit and reviewed — with continuous verification standing in for compiler trust.
Frequently asked
- Is RowShield affiliated with Amazon Web Services?
- No. RowShield is built by Veristria, an independent company, and is unaffiliated with Amazon Web Services, Inc. Amplify and AppSync are referenced descriptively and remain trademarks of their owner.
- Is RowShield a good Amplify auth rules alternative?
- On Supabase, yes in the sense that matters: it verifies the RLS layer that replaces auth() rules, continuously and against live behaviour. It does not generate or enforce anything on AWS, where Amplify remains the right tool.
- What happens to my auth() rules when I move Amplify Data to Supabase?
- Each rule is translated into table policies in SQL, with attention to per-row evaluation and WITH CHECK semantics. RowShield's probe verifies the outcome as the anon caller, and its rules catch the common mistranslations — tautological predicates, missing WITH CHECK, unwrapped auth.uid() calls.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit