RowShield vs pganalyze: performance depth versus exposure posture

Head to head: pganalyze vs RowShield

Column claims about pganalyze 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 pganalyze does

pganalyze is a monitoring service for Postgres that ingests statistics, logs and statements, then turns them into diagnosis: which queries carry the most load, which plans regressed, which indexes the advisor suggests. Its EXPLAIN analysis and trend views have earned a devoted following among database engineers.

Teams adopt it after their first serious slowdown and tend to keep it, because understanding a fleet query by query is genuinely hard and pganalyze removes much of the toil.

Where the scopes differ

Performance tooling observes behaviour: timings, plans, buffer counts. Exposure is structural. A perfectly fast endpoint can return another tenant’s rows, and a glacial policy can still be too wide; no quantity of plan captures yields a verdict on whether the anon role can read the payments table.

The scopes touch at two known seams. A row-level security predicate with no supporting index forces evaluation per row, so protection becomes the latency source; pganalyse faithfully shows the slow scan while RowShield names UNINDEXED_RLS_PREDICATE and supplies the covering index. Likewise a bare auth.uid() comparison evaluated per row is both a posture smell and a drag. One tool sees cost; the other names cause. Live behaviour — what PostgREST returns to an anonymous caller — belongs to neither performance telemetry nor plan review, and completes RowShield’s half of the lens.

Why Supabase teams choose RowShield over pganalyze

Choosing RowShield is not choosing against performance work; it admits performance work was never the gap. Supabase projects ship defaults inviting quiet widening: disable protection to test, forget to re-enable, add a generous USING clause under deadline. RowShield scans for exactly these — RLS_DISABLED, RLS_NO_POLICIES, tautological forms — and records history so widening carries a timestamp.

Its findings speak security fluently: who gains reach, which statement introduced it, the minimal SQL restoring intent. That framing is what reviews and retrospectives require, and no volume of query telemetry substitutes for it.

Where pganalyze is the right choice

For fleets where milliseconds are revenue, pganalyze earns its keep: plan-regression alerts catch the bad deploy before customers do, and the index advisor converts workload statistics into concrete suggestions. As pure Postgres craftsmanship it ranks among the best available.

It is also the right first purchase when the symptom is unmistakably slow pages, since diagnosing outranks theorising — and even then, exposure remains a separate question worth its own instrument.

Using both

Complementary by design, which is why many teams run both. pganalyze tunes what runs; RowShield attests to what is reachable. When a policy appears in both queues — slow and wide — the two reports describe one underlying mistake from complementary angles.

A tidy loop: RowShield flags UNINDEXED_RLS_PREDICATE, the suggested index lands, pganalyze confirms the plan improved. Safety first, speed confirmed, neither pretending to be the other.

Frequently asked

Is RowShield affiliated with pganalyze?

No. Veristria develops RowShield independently, with no relationship to pganalyze, Inc. This assessment relies on pganalyze public documentation.

Can pganalyze tell us if row-level security is misconfigured?

Only indirectly. Slow policies show up as slow queries, but width and exposure require reading policy definitions and grants — posture analysis rather than performance analysis.

We found a slow policy. Which tool opens first?

Open RowShield to learn whether the predicate is unindexed or the comparison runs per row, apply the fix, then let pganalyze confirm the plan improved.