What a RowShield health score actually measures

What pushes the score up

Resolution moves it. When open findings are fixed — a table gains working policies, a bucket goes private, an exposed privileged key is rotated and removed — the score responds, with higher-severity findings weighing more heavily than lower ones. Sustained cleanliness holds it steady rather than inflating it forever: the score measures posture, not seniority.

Direction deserves emphasis over magnitude. A score is at its most useful answering whether this project is getting safer or less safe — the trend a team can act on — and least useful argued over digit by digit, which is a large part of why the exact weights behind it stay internal rather than published.

What pulls it down

New findings pull it down in proportion to their severity, and regressions — fixes that came back — pull hardest, because a returned problem indicates a delivery-process defect rather than a one-off slip. Volume matters alongside severity: many medium findings describe a systemic habit such as policies consistently written without indexes, and the score reflects that breadth rather than treating each as isolated noise.

Equally honest is what the score ignores. It is not influenced by project age, plan tier or scan frequency: plans limit projects and cadence, never truth, and the inputs feeding the score are the same on Free as anywhere else. Nor does the score replace reading findings — it is a summary, and summaries compress.

Roll your own count

If you would rather see raw inputs, the catalog provides them. This query counts structural failure classes directly — tables without RLS in the public schema, policies present for review, public buckets — which is the shape of evidence a score aggregates, minus the severity weighting:

SELECT
  (SELECT count(*) FROM pg_catalog.pg_class c
     JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
    WHERE c.relkind IN ('r','p') AND n.nspname = 'public'
      AND c.relrowsecurity = false)                AS rls_disabled,
  (SELECT count(*) FROM pg_catalog.pg_policies
     WHERE schemaname = 'public')                  AS policies_to_review,
  (SELECT count(*) FROM storage.buckets
     WHERE public)                                 AS public_buckets;

Interpret direction, not absolutes

Interpret direction rather than absolutes: falling counts mean posture improving, rising counts mean drift worth investigating, and zero on the first and third is a defensible baseline for most projects. The policy figure requires reading rather than counting — a number there says nothing about whether the conditions themselves are sound.

None of these counts require RowShield or any tool: they run against metadata your database already maintains. Running the query monthly, dated, gives you a private trend line that agrees or disagrees with any dashboard summary — ours included — and disagreement between independent measurements is always worth investigating.

Using it without worshipping it

The score earns its place as a triage signal and a trend line: glanceable, comparable across your own projects over time, and honest about movement. Decisions still belong to the findings underneath it — a single critical exposure outranks any aggregate, and remediating beats optimising a number. Treat the score as the headline; treat the findings as the story.

RowShield is an independent product, unaffiliated with and not endorsed by Supabase; it reads pg_catalog and bucket metadata only — never table rows — and references to Supabase and Postgres are descriptive. Run a free audit — no account — at rowshield.dev/audit, and the findings behind any summary of your project are yours to read in full, on every tier.

Frequently asked

Does the score replace reading findings?

No. It summarises them, and compression loses the detail decisions need. A single critical finding matters more than the aggregate, and the finding list — never withheld on any plan — remains the source of truth.

What raises the score fastest?

Resolving open findings, highest severity first, and keeping them resolved. Regressions undo progress, so a fix that sticks moves the number further than a fix that returns the following week.

Do paid plans score differently?

No. Plans differ in projects monitored and scan frequency — daily on Free, hourly on Indie, fifteen minutes on Team — while findings and remediation are never withheld, so the inputs behind the score are identical across tiers.