RowShield vs Supabase Log Explorer: request logs versus live posture

Head to head: Supabase Log Explorer vs RowShield

Column claims about Supabase Log Explorer 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 the Log Explorer does

The Log Explorer is the query surface for Supabase's platform logs: API gateway traffic, Postgres logs, auth events, storage activity and edge runs, filterable and chartable from the dashboard. It is first-party telemetry with sensible retention, and it is the right instrument for answering the question "what happened".

As a security instrument it is raw material rather than a programme: detection depends on somebody authoring the query, knowing the failure signature to look for, and looking again after the next change lands.

Where the scopes differ

Direction. Logs look backwards; RowShield scans forward. A log query can show that an anonymous read succeeded yesterday; it cannot tell you, today, what the anon key would be allowed to fetch after the migration that shipped this morning. RowShield re-reads the catalog on every scan and re-probes the API surface, so the answer to "what is reachable right now" is current by construction.

Evidence. Production logs capture real traffic — the odd paths, statuses and rhythms that no synthetic request would predict. That is a genuine advantage and this page does not pretend otherwise: for observing how a system is actually being used, the Log Explorer wins. RowShield's probe is deliberately narrow — GET requests only, exactly the access a visitor already has — and produces evidence about possibility rather than occurrence.

Rules and memory. The Explorer ships queries, not a rule engine: there is no built-in library that knows what a tautological policy or a flipped bucket looks like, and no memory between investigations. RowShield carries nine shipped rules, snapshots the catalog on every scan, and classifies each change as created, resolved or regressed so a reverted fix is reported as a regression.

Delivery. Log findings wait on the dashboard; RowShield pushes transition alerts to Slack, Discord, email or webhooks with per-destination severity thresholds.

Why Supabase teams choose RowShield over the Log Explorer

Nobody opens a chart to discover a tautology. The failure mode of DIY detection from request logs is not bad queries; it is the absence of queries in the weeks when nothing seems wrong. RowShield converts the recurring question — what can the anon key actually reach right now? — into a scheduled check with rule-backed coverage (RLS_DISABLED, RLS_TAUTOLOGY, MISSING_WITH_CHECK, PUBLIC_BUCKET_EXPOSURE, ANON_TABLE_READABLE, SERVICE_ROLE_KEY_EXPOSED and the rest), a GET-only probe, and alerts that fire on transitions only.

Remediation SQL is generated from your actual column names, the CLI wraps the same engine with CI-safe exit codes, and plans never withhold findings or fixes — limits buy projects and frequency, not truth.

Where the Log Explorer is the right choice

For incident response, latency hunts, debugging authentication flows and any observability-minded workflow, the Log Explorer is excellent, and this page argues for nothing that replaces it. RowShield ingests no request logs at all; when you need to know what happened, the logs are the source of truth and the probe is simply not that kind of instrument. Teams doing serious operational work should keep both habits: logs for occurrence, verification for possibility.

Using both

They corroborate each other cleanly. When the probe flags a table the anon key can read, the Log Explorer tells you whether anyone actually asked; when a log query shows an unexpected 200 on a protected path, a scan tells you which policy change made it possible. Possibility and occurrence are different axes, and mature teams watch both.

Frequently asked

Is RowShield affiliated with Supabase?

No. RowShield is an independent product by Veristria, unaffiliated with Supabase, Inc. The Log Explorer is referenced descriptively and remains a trademark of its owner.

Can I use RowShield and the Log Explorer together?

Yes, and they answer different questions. The Explorer shows what requests already did; RowShield shows what the current configuration and API surface permit, on a schedule, with drift alerts between your visits.

Can the Log Explorer tell me what the anon key can read?

Only for requests already made. It cannot enumerate permissions that no traffic has exercised. RowShield's probe asks PostgREST directly — GET requests only, as the anon caller — and reports the result per table.