Comparisons / Cloud posture (CSPM)
RowShield vs Lacework: Supabase data-layer watch vs workload behaviour analytics
The short version
- Lacework, now part of the Fortinet portfolio, is a cloud workload protection and posture platform known for behavioural anomaly detection across cloud workloads. RowShield is a continuous monitor for the Supabase backend alone: row level security posture, anonymous REST behaviour, storage exposure and policy drift between scans.
- Choose Lacework (Fortinet) when — your estate is large, your team values machine-learning baselining of workload behaviour, and Fortinet Fabric consolidation fits your architecture direction.
- Choose RowShield when — your risk concentrates in one or few Supabase projects and you want tautological policies, missing WITH CHECK clauses and regressed fixes surfaced with remediation SQL.
RowShield rules relevant here
Head to head: Lacework (Fortinet) vs RowShield
| Capability | Lacework (Fortinet) | RowShield | Edge |
|---|---|---|---|
| Subject of analysis | Cloud workloads, containers and accounts across the estate — behaviour, vulnerabilities and posture. | One Supabase project: its catalog, its storage rules, its public REST surface. | Lacework (Fortinet) |
| Reading the project catalog | Managed Supabase internals are outside collection scope; agents collect from hosts you operate. | Direct: pg_policies, RLS flags, grants and buckets read on every scheduled scan. | RowShield |
| Always-true and write-open policies | Behavioural models learn workload patterns; SQL policy expressions are not evaluated. | Detected per table and role, quoted verbatim, paired with a corrected policy statement. | RowShield |
| Probing as the anon caller | Not performed; telemetry comes from collectors and APIs, not from your public API surface. | GET-only probe through PostgREST proves which tables return rows to the internet. | RowShield |
| Baseline and regression language | Anomaly detection baselines workload behaviour, not your row level security policy set. | Catalog baselines diffed each scan; findings labelled created, resolved or regressed. | RowShield |
| Fix output | Investigation consoles for security analysts. | Paste-ready SQL aligned to your column names, one click to copy. | RowShield |
| Workload anomaly detection | A genuine differentiator: behavioural analytics over estate-scale telemetry. | Absent by design; we watch configuration and behaviour of the API surface, not hosts. | Lacework (Fortinet) |
| Cost and ceremony at startup scale | Enterprise platform economics and onboarding. | Self-serve, free first audit, plans sized for indie teams. | Lacework (Fortinet) |
Column claims about Lacework (Fortinet) 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 Lacework does
Lacework distinguished itself in the cloud workload market with behavioural anomaly detection: rather than cataloguing static weaknesses alone, it learns what normal looks like for your workloads and surfaces departures from that norm, alongside agentless posture assessment and vulnerability inventory. Since joining Fortinet’s portfolio, the technology sits within a broader fabric of network-security products, which suits buyers consolidating on that ecosystem.
Two practical notes for evaluators. First, its strengths are expressed over hosts, containers and accounts — things your organisation operates. Second, as with any acquisition-folded product line, packaging and roadmap positioning evolve, so confirm current shape with Fortinet directly. Both notes point the same way: this is estate machinery, purchased by estate owners, tuned for analysts who think in workloads rather than in row level security.
Where the scopes differ
Lacework collects from the infrastructure you run. Supabase runs its infrastructure for you: the Postgres instance, auth server and storage service behind your project live on the vendor’s side, beyond the reach of workload agents and account connectors. The platform therefore perceives your backend the way a satellite perceives a house — footprint only, no interior.
Apply the recurring lens and the split is clean. Policy posture: unread — no component evaluates pg_policies, so an always-true USING clause or an UPDATE policy lacking WITH CHECK draws no signal. Behaviour: untested at the data layer — anomaly models watch hosts, not your REST gateway; nothing issues the GET request your anon key permits. Drift: baselined for workloads, not for your policy set, so a loosened policy arrives silently.
Conversely, we offer nothing resembling behavioural workload analytics, and would not claim to. The scopes are near-disjoint; the honest question is which subject actually holds your risk tonight.
Why Supabase teams choose RowShield over Lacework
Startups searching "Lacework for Supabase" are really asking who watches the backend. The concrete answer: scheduled scans over nine rules covering RLS-disabled tables, empty policy sets, constant-true policies, missing WITH CHECK clauses, unindexed predicates, bare auth.uid() calls, public buckets, leaked service_role keys and tables the anon key demonstrably reads. Every finding carries generated SQL; every scan diffs the previous snapshot; alerts fire on transitions so a standing problem pages once, not hourly.
Set-up reflects the same philosophy: a read-only connection string from the dashboard, first audit the same day, pricing a founder approves without a meeting. Estate platforms earn their keep at estate scale; below that scale they mostly generate invoices and noise around the handful of objects that could actually leak user data.
Where Lacework is the right choice
Security teams running substantial containerised estates, who value anomaly detection over static posture alone and are consolidating vendors inside the Fortinet fabric, should evaluate Lacework on its merits — its behavioural approach is a genuine contribution and we concede it plainly. Even ideal customers, though, will find managed Supabase internals outside the collected world; adding RowShield beside it closes that gap without disturbing the estate investment.
Using both
Coexistence is unremarkable: workload telemetry flows to Lacework, catalog snapshots and probe results flow to RowShield, and both feed the same incident habits — Slack alerts, weekly triage, postmortems. Because neither touches the other’s subject, there is no deduplication problem worth solving. The one process rule worth adopting: treat backend regressions found by RowShield with the same seriousness as workload anomalies found by Lacework, even though only the latter looks like classic security telemetry.
Frequently asked
- Is RowShield affiliated with Fortinet?
- No. RowShield is developed by Veristria and stands independent of Fortinet, Inc. and of Lacework. References here are descriptive, drawn from public documentation reviewed on 2026-08-23; Lacework and Fortinet remain trademarks of Fortinet, Inc.
- Is RowShield a Lacework alternative or complement?
- A complement at estate scale, an alternative below it. Organisations running Lacework for workload behaviour should keep it and add RowShield for the Supabase layer it cannot see. Startups whose entire sensitive surface is one Supabase project will find RowShield the direct substitute for anything Lacework would nominally do there.
- Does Lacework monitor row level security on Supabase?
- No. Collection centres on workloads, containers and cloud accounts your organisation operates; a managed Supabase project’s policy catalog is not gathered. Evaluating pg_policies on schedule — including tautologies and missing WITH CHECK clauses — is RowShield’s core function.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit