Comparisons / Postgres performance
RowShield vs pgMustard: plan review versus standing posture
The short version
- pgMustard offers superb opinionated review of individual query plans: where time went, which estimates misled, what to try. It is a scalpel for latency, not a lens for exposure. RowShield covers posture, plus the seams where policy design appears as cost.
- Choose pgMustard when — a specific query misbehaves and you want the fastest route from plan to fix, explained by people who read plans professionally.
- Choose RowShield when — you want scheduled whole-database verdicts on row-level security and grants, with history and remediation SQL attached to each finding.
RowShield rules relevant here
Head to head: pgMustard vs RowShield
| Capability | pgMustard | RowShield | Edge |
|---|---|---|---|
| Unit of analysis | The individual query plan, node by node. | The whole database posture, table by table and policy by policy. | Parity |
| Plan interpretation | Expert annotated breakdowns with ranked suggestions — honestly excellent. | Deliberately out of scope; the database interior is our entire surface. | pgMustard |
| Exposure verdicts | Not attempted; plans describe cost, not permission. | Central purpose: who can reach which rows, checked continuously. | RowShield |
| Cadence | Invoked when a query deserves scrutiny — the correct shape for plan review. | Scheduled scans produce comparable posture history over months. | RowShield |
| Policy-aware hints | Depicts the slow nodes accurately while leaving policy context to you. | Names UNINDEXED_RLS_PREDICATE and bare per-row auth.uid() as causes worth fixing. | RowShield |
| Team accessibility | Accessible, with glossaries teaching plan vocabulary well. | Written for application teams owning Supabase data without database careers. | Parity |
| Remediation form | Configuration and indexing suggestions aimed at the plan under review. | Reviewable SQL restoring intended protection, plus the index the policy lacks. | RowShield |
Column claims about pgMustard 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 pgMustard does
pgMustard takes EXPLAIN (ANALYZE, BUFFERS) output and returns a guided critique: where time went, which estimates misled, which operations deserve attention, which changes usually help. The advice is opinionated in the best sense, reflecting years of plan-reading practice, and the interface teaches while it diagnoses.
Consultants and staff engineers keep it ready for the moments a plan resists casual reading. As a plan-review instrument it has little competition.
Where the scopes differ
Plan review is forensic: one query, examined closely after symptoms appear. Exposure is ambient: every table, every policy, every hour, complained about or not. A database can run beautifully while leaking, and leak nothing while running badly; the two properties are unrelated in general.
They intersect at recognisable points. Policies lacking supporting indexes impose per-row filtering costs, and comparisons written as bare auth.uid() inside per-row context multiply the tax further. pgMustard depicts the resulting plan faithfully; RowShield identifies the pattern upstream, names it, and hands over both the security implication and the index resolving it. What neither plan review nor posture scanning supplies is behavioural proof — whether the anon key truly fetches nothing — which is why RowShield pairs catalog rules with a live GET probe.
Why Supabase teams choose RowShield over pgMustard
Supabase concentrates application logic in the database, where policy edits tempt and consequences hide. RowShield answers the standing question pgMustard never poses: given the current catalog, is anything reachable that should not be? Scheduled scans turn that question from anxiety into a checklist with history.
Findings arrive with reasoning attached, mapped to rules such as RLS_DISABLED and RLS_NO_POLICIES, each with minimal corrective SQL. For teams without a database specialist on call, that is the difference between knowing a plan looks odd and knowing the data is safe.
Where pgMustard is the right choice
When a report crawls and stakeholders wait, plan review is the shortest path to relief, and pgMustard lets you buy that expertise per query rather than per salary. It doubles as a teaching aid, steadily improving how a team reads plans unaided.
Keep it close for incident response and optimisation sprints. Just never ask it about grants: plans are innocent of permissions, however beautiful their annotations.
Using both
Nothing overlaps, so running both is ordinary good sense. RowShield patrols structure; pgMustard assists episodes. Bridge findings give the pair a shared language: when RowShield reports an unindexed policy predicate, the fix lands and pgMustard confirms the plan skips per-row evaluation.
Adopters usually sequence them: posture first, because exposure outranks slowness; tuning second, because users notice latency before auditors notice anything.
Frequently asked
- Is RowShield affiliated with pgMustard?
- No. Veristria builds RowShield independently and has no relationship with pgMustard Ltd. Comments about pgMustard derive from its public site and documentation.
- Should we cancel pgMustard if we adopt RowShield?
- They solve different problems. RowShield covers posture continuously; pgMustard stays valuable whenever an individual query needs expert plan review.
- Our slow query turned out to be a policy. Whose bug is it?
- Usually a missing index on the policy predicate or a per-row auth.uid() comparison. RowShield labels both patterns; the remedy is an index and a rewritten check either way.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit