Comparisons / Postgres linters
RowShield vs sqlfluff: SQL style linting vs live policy verification
The short version
- sqlfluff is a dialect-aware SQL linter and formatter: it parses SQL, enforces configurable style rules and applies autofixes, across many dialects and templaters. RowShield is a scheduled monitor over a live Supabase project — policy posture, anon behaviour and drift.
- Choose sqlfluff when — you want consistent, reviewable SQL across a large codebase, with fixes applied automatically.
- Choose RowShield when — you want to know what the running database permits — and to hear about it the week a policy regresses, not the quarter someone re-reads the SQL.
RowShield rules relevant here
Head to head: sqlfluff vs RowShield
| Capability | sqlfluff | RowShield | Edge |
|---|---|---|---|
| Primary job | Text quality: layout, casing, naming and generic anti-patterns in SQL files. | System truth: what the live catalog and API permit, checked continuously. | Parity |
| Formatting and fixes | Excellent: autofix enforces house style across thousands of files. | Writes nothing and formats nothing; RowShield changes no code. | sqlfluff |
| Knowledge of your database | Parses text; unaware of the catalog the SQL will run against. | Reads pg_catalog from your project on every scan. | RowShield |
| Supabase semantics | Generic SQL rules; no notion of RLS, auth.uid() or storage policies. | Nine purpose-built rules for exactly those constructs. | RowShield |
| Runtime truth | Cannot observe what a query returns for a given role. | The probe observes anon-visible results directly, GET only. | RowShield |
| Dialect breadth | Many engines and templaters supported, including dbt. | Postgres on Supabase only, deliberately. | sqlfluff |
| Cost profile | Free and open source under the MIT license, installable anywhere Python runs. | Free probe tier; monitoring plans are listed on the pricing page. | sqlfluff |
Column claims about sqlfluff 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 sqlfluff does
sqlfluff is a dialect-aware SQL linter and formatter. It parses SQL into an AST, enforces a configurable rule set covering layout, keyword casing, naming conventions and a selection of generic anti-patterns, and can apply fixes automatically. It supports many dialects — Postgres among them — and understands templaters such as Jinja and dbt, which is why it is widely adopted for keeping large SQL codebases consistent and reviewable.
It is free, open source, and excellent at its job. Its job, however, is the text: sqlfluff reasons about characters and grammar, not about the database the SQL will run against.
Where the scopes differ
The gap is between text quality and system truth. A parser can confirm that a policy statement is well-formed SQL; it cannot know whether the predicate is always true, whether RLS is enabled on the table, whether the auth.uid() call inside the predicate is wrapped so it can use an index, or whether the bucket policy copied from a template matches the product's current shape. Generic anti-pattern rules have no vocabulary for RLS, storage or the anon/service_role key split — those are Supabase semantics, not SQL grammar.
Mapped onto RowShield's three lenses: sqlfluff holds none of the three by design. Posture, behaviour and drift all live in the running system, which a text linter never touches. What it holds instead is real and different: formatting discipline, autofix, dialect breadth — and the honest table above gives it those rows.
Runtime truth is the sharpest edge of the divide. Whether a query returns rows for the anon role is a property of the running system; no static tool can observe it. RowShield's probe asks PostgREST directly, with GET requests only, and records what comes back.
Why Supabase teams choose RowShield over sqlfluff
For the security question, generic linting is the wrong instrument not because it is weak but because it is aimed elsewhere. RowShield's nine rules — RLS_DISABLED, RLS_TAUTOLOGY, RLS_NO_POLICIES, MISSING_WITH_CHECK, UNINDEXED_RLS_PREDICATE, RLS_UNWRAPPED_AUTH_CALL, PUBLIC_BUCKET_EXPOSURE, SERVICE_ROLE_KEY_EXPOSED, ANON_TABLE_READABLE — exist precisely because those constructs are Supabase-specific and invisible to a grammar.
RowShield reads the live catalog on a schedule, probes the API as the anon caller, diffs every scan against the last, and pushes transition alerts to Slack, Discord, email or webhooks. Remediation SQL is generated from your real columns. Style gates in CI remain valuable — they are simply orthogonal to this, and the strongest pipelines run both.
Where sqlfluff is the right choice
For multi-engine shops, dbt projects and any team where SQL consistency across hundreds of files is the daily pain, sqlfluff is the right tool and this page does not dispute it. RowShield formats nothing, fixes nothing and covers one platform deliberately. If your problem is readable SQL, use sqlfluff; if your problem is what the SQL permits, that is a different instrument.
Using both
They compose without friction because they never examine the same thing: sqlfluff keeps the SQL consistent in review, RowShield keeps the posture verified in production. A beautifully formatted tautology is still a tautology — which is exactly why the two belong in the same pipeline rather than in place of each other.
Frequently asked
- Is RowShield affiliated with the sqlfluff maintainers?
- No. RowShield is an independent product by Veristria, unaffiliated with the sqlfluff project and its maintainers. sqlfluff is referenced descriptively and remains the mark of its project.
- Is RowShield a good sqlfluff alternative?
- For formatting and style, no — sqlfluff is purpose-built for that and free. For verifying what a live Supabase project permits, RowShield covers ground a text linter cannot reach; most teams with both problems run both tools.
- Can sqlfluff catch a dangerous RLS policy?
- Not as such. Its rules operate on SQL grammar and generic anti-patterns, without knowledge of RLS semantics or the catalog, so a policy can pass every sqlfluff check and still be always-true or leave a table exposed.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit