RowShield vs PocketBase rules: per-collection filters vs RLS auditing

Head to head: PocketBase collection rules vs RowShield

Column claims about PocketBase collection 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 PocketBase collection rules do

PocketBase bundles a Go application, an embedded SQLite database, an admin UI and an API into a single executable. Authorisation is expressed per collection as API rules — listRule, viewRule, createRule, updateRule, deleteRule — written as filter expressions evaluated against the request context.

The design achievement is concision: one readable line guards a collection, and a developer can hold the whole authorisation surface in their head. For the class of app PocketBase targets, that is a legitimate and often sufficient posture.

Where the scopes differ

The layers differ. PocketBase evaluates filters in the application; Supabase enforces RLS in the database engine, on every path including direct connections. Both are legitimate models with different guarantees: application-layer rules are easier to read, engine-layer policies are harder to bypass.

Verification is where the scopes separate sharply. PocketBase ships no standing audit and no requester: correctness rests on your discipline, exercised by hand. Mapped onto RowShield's three lenses, PocketBase holds readable posture (reviewed manually), no automated behaviour evidence, and no time axis at all.

For migrating teams the consequence is concrete: every filter expression must become SQL policy, and the evaluation contexts differ enough — joins, per-row semantics, WITH CHECK clauses — that translation deserves verification rather than hope. A rule that read clearly in PocketBase's filter syntax can become a policy with a tautological predicate or a missing WITH CHECK clause without anyone intending it.

Why Supabase teams choose RowShield over PocketBase rules

Once your backend is Supabase, the question is not "are my rules readable?" but "what does the policy layer permit, and did it change?" RowShield answers on a schedule: nine shipped rules over RLS state, tautologies, missing WITH CHECK, unindexed predicates, unwrapped auth.uid() calls, bucket exposure, anon-readable tables and leaked service_role keys; a GET-only probe as the anon caller; and transition alerts that name every created, resolved or regressed finding.

Nothing is installed server-side — a catalog-read connection string is enough — remediation SQL is generated from your real columns, and the CLI brings CI-safe exit codes for teams that gate merges.

Where PocketBase rules are the right choice

For small self-hosted tools, internal dashboards and products that fit comfortably in one binary, PocketBase is charming and capable, and its rule concision is a feature RowShield has no answer to. RowShield monitors Supabase projects; against an embedded SQLite backend it has nothing to offer, and this page says so plainly rather than implying otherwise. The comparison matters at the platform decision and on the migration path.

Using both

During a staged migration both systems run at once: PocketBase guards the origin while the Supabase leg grows, and RowShield watches that leg from the first policy onward. After cutover, what carries over is the explicitness PocketBase taught you — authorisation written down in one obvious place — with continuous verification replacing manual confidence.

Frequently asked

Is RowShield affiliated with the PocketBase maintainers?

No. RowShield is an independent product by Veristria, unaffiliated with the PocketBase project and its maintainers. PocketBase is referenced descriptively and remains a trademark of its owner.

Is RowShield a PocketBase rules alternative?

Not directly: RowShield is not a backend and authorises nothing. For a Supabase project it fills the gap PocketBase leaves to discipline — continuous verification of policies, anon behaviour and drift.

I am migrating from PocketBase to Supabase — how do I validate my new policies?

Inventory each collection rule and its replacement policy, then verify behaviour: RowShield's probe reports what the anon caller can reach, and its rules catch tautological predicates, missing WITH CHECK clauses and RLS left disabled during the move.