r/Supabase

Row-level security is the thing everyone knows they should have and it's the thing that quietly gets forgotten on one table, or shipped as USING (true), or bypassed by a service-role client. You don't find out until someone reads another tenant's data.

I built a small MIT-licensed tool for exactly this footgun, and I wanted to share it here since it's Supabase-shaped:

npx tenant-guard

Two parts:

1. Static guards (zero-dependency, run in CI) that flag the classic leak shapes: an authenticated route that loads a row by bare id with no organization_id filter, and new SECURITY DEFINER functions left callable by anon over PostgREST (revoking from anon alone is a no-op, it catches that).
2. A runtime RLS proof, point it at a seeded test/branch database and it drops to the authenticated role, assumes one tenant's identity via your JWT claims, and asserts that session can't see another tenant's rows, table by table. If a policy is missing or wrong, the build fails.

There's a demo you can run in 10 seconds with no infra (it uses an embedded Postgres): it passes a correct policy and fails a leaky one.

Honest disclosure: I built it, it's free, no signup/telemetry, and I'm posting because I think it's genuinely useful for this community, not selling anything. It's sharp for Supabase/Postgres specifically. Feedback on the becomeTenant config (how it assumes a tenant's identity for your policies) would be especially useful, that's the part that varies most between apps.

It might not work on any project but it did work on the projects I tested it on

Repo: https://github.com/FedericoTs/tenant-guard

If you’re using Clerk with Supabase, you may have asked:

• Why does auth.uid() return NULL when I send a Clerk token?
• Should I use the service-role key to make RLS errors disappear?
• How should Clerk Organizations map to tenants in Postgres?
• How to handle a Clerk profile without an Organization?
• How do I test RLS policies directly in SQL?
• Why can RLS make a query over a tiny table take several seconds?
• Can I use Supabase RLS without using Supabase Auth?

I kept finding variations of these questions while working with Clerk and Supabase.

The confusing part is that many answers mix three different integration paths:

• Supabase Auth examples built around auth.uid()
• The older Clerk JWT-template integration
• Clerk and Supabase’s current native third-party authentication

For the current native integration, passing the token is surprisingly simple:

const supabase = createClient(url, publishableKey, {
  accessToken: async () => session?.getToken() ?? null,
})

But building a secure multi-tenant authorization model around that token requires more care.

Some mistakes are particularly easy to make:

1. Using auth.uid() even though Clerk user IDs are strings such as user_....
2. Trusting an organization ID supplied by the browser.
3. Reaching for the service-role key, which bypasses RLS instead of fixing it.
4. Querying a membership table recursively from its own RLS policies.
5. Checking reads but forgetting WITH CHECK protections for inserts and updates.
6. Running JWT and membership functions once per row instead of hoisting them.
7. Testing only successful requests and never proving that another tenant is rejected.

With Clerk, the verified user and active organization context are available through the JWT:

(select auth.jwt()->>'sub')
(select auth.jwt()->'o'->>'id')
(select auth.jwt()->'o'->>'rol')

Postgres should derive the user and tenant from these verified claims.

The browser can send a Clerk session token and filter a query for performance, but it should never be the authority that decides which tenant owns a row.

I put together a step-by-step tutorial for anyone starting with Clerk and wanting to build a multi-tenant application using Supabase RLS:

Clerk and Supabase RLS Tenant Isolation

There is also a complete runnable repository:

Clerk + Supabase RLS demo

It includes:

• Native Clerk session tokens without JWT templates
• Personal and organization tenants
• Clerk organization-role handling
• Non-recursive authorization closures
• Explicit SELECT, INSERT, UPDATE, and DELETE policies
• Database-derived audit fields
• Cross-tenant foreign-key protection
• SQL contract and behavioral tests
• A manual browser security matrix
• Request-flow and data-model diagrams

My goal was to provide more than another isolated RLS snippet. The tutorial connects token delivery, claim extraction, tenant modeling, policy design, performance, and adversarial testing in one working example.

HTH fellow users just starting out on their Supabase & Clerk Journey

Something I kept running into with AI-assisted code: you ask the agent to fix a query, it can't work out the policy, so it just disables RLS. Or a paywall check gets set to false so a demo works. Or email confirmation goes off during testing and never goes back on. The code looks fine afterwards. Nothing errors.

So I wrote a CLI that fails the build on that specific kind of change. MIT, no dependencies:

npx prodguard check --demo
npx prodguard check

The demo runs everything against a fake broken app, so you can see the output without pointing it at anything real.

12 checks. The ones that matter here:

• ALTER TABLE ... DISABLE ROW LEVEL SECURITY, or a table that never had it turned on
• service_role key in client code, or sitting behind VITE_ or NEXT_PUBLIC_
• email_confirm: true / auto-confirm in real auth paths
• Stripe webhook handler with no signature check
• JWT decoded but never verified
• Firebase rules left on allow read, write: if true, including the console's 30 day test mode
• live keys committed, recovery code files committed, DELETE FROM with no WHERE

Before publishing I spent a day trying to break it, mostly by throwing agents at it to red team the thing. It went badly.

The big one: it was printing the secrets it found. I'd written a redact() function and only wired it into one of the twelve rules. The other ten printed the whole matching line. So when it found a service_role JWT, it printed the JWT. To your terminal and into your CI logs. Bit of a problem for a tool whose whole pitch is protecting that key.

A 512KB file could lock CI up for 159 seconds from regex backtracking. The same broken pattern meant TRUNCATE TABLE never matched anything in the first place.

If you typo'd the path it printed "Nothing dangerous found" and exited 0. So prodguard check ./scr passes. For a build gate that's about the worst failure available.

24 false positives. The worst hit every Supabase project going: run supabase init in an empty folder, scan it, two HIGH findings straight off the stock config. One of those was my email rule firing on enable_confirmations under [auth.sms], which is the phone setting.

Then a red team pass wrote 29 deliberately vulnerable files and ran it. Zero findings, exit 0. Every rule was matching literal strings, so const [locked, setLocked] = useState(false) went straight through, and that's how an agent actually writes it.

All fixed in 0.5.0 with tests for each. Redaction happens in the rule runner now, so no individual rule can skip it.

https://github.com/Felix0731/prodguard

There's a walkthrough on the site too, if you've not run something like this before: https://prodguard.vercel.app

What it doesn't do: it reads text, it doesn't parse your code. Write the same bug a different way and it'll miss it. It gets things wrong sometimes too, there's an ignore list for that. A pass means those 12 checks didn't fire, nothing more. And anything you set in the dashboard instead of your repo it can't see, same as any repo scanner.

If an agent has broken something in your project that this doesn't catch, tell me what the diff looked like and I'll write a rule for it. That's genuinely the most useful thing I could get right now.

Supabase already gives you API Gateway and Edge Function logs, and Log Drains to forward them wherever you already watch your telemetry. What was missing → a way to tie a request in your client trace to the matching entry in those logs. You'd end up guessing which log line belonged to which slow request, based on timestamps alone.

That's fixed now. supabase-js, Swift, Flutter, and Python can all propagate W3C Trace Context to Supabase, so the request's trace_id shows up on the Supabase side too. It's opt-in, nothing changes until you turn it on. In supabase-js that's two lines: import '@supabase/supabase-js/tracing' at your entry point, then tracePropagation: true in createClient. Python goes through opentelemetry-instrumentation-httpx instead of a client flag, since that's already the Python ecosystem's way of instrumenting httpx.

Whatever tracer you already run, this should just work. OpenTelemetry, Sentry, Datadog, Honeycomb, Grafana are all W3C-compliant, though Sentry's setup differs a little from strict OTel so it's worth checking their docs. And if your sampler drops most traces, tracePropagation: { enabled: true, respectSamplingDecision: false } carries Supabase requests through regardless.

None of this costs anything extra either, it's just more value out of Log Drains you're probably already paying for.

Happy to answer questions. Full writeup: https://supabase.com/blog/connect-client-traces-to-your-logs

A few days ago there was a discussion here about backing up Supabase properly.

I originally replied with the usual approach supabase db dump, copy Storage somewhere else, run it from cron/GitHub Actions, etc.

People pointed out the parts that make this a lot less simple once you actually care about disaster recovery. Encryption, Storage consistency, restore testing, auth, roles, checksums, knowing what Supabase does and doesn't expose, and making sure a backup is actually usable before the day you need it.

So I said:

>Give me a couple of days. I've decided to build exactly this now.

Well... I built it.

It's called pgDumpster.

https://www.pgdumpster.com/
https://github.com/Ciroc0/pgdumpster
https://www.npmjs.com/package/pgdumpster

It's a CLI for backing up, inspecting, verifying and restoring hosted Supabase projects.

At the moment it handles the PostgreSQL side, Storage objects/metadata, Auth and API-related state where Supabase exposes it, Edge Functions/config where recoverable, and the relevant control-plane configuration that can actually be read/restored.

Backups are bundled with a manifest and integrity information, can be encrypted with age, and can optionally be stored on S3-compatible storage like R2.

The restore side is deliberately paranoid. There's a dry-run/planning stage, target validation, conflict handling and explicit reporting of things that cannot safely or automatically be restored.

I learned while building this that there really isn't such a thing as a completely atomic “Supabase backup”. PostgreSQL, Storage and the Supabase control plane are different systems. pgDumpster doesn't pretend otherwise. It records the consistency boundaries and tells you when something depends on platform limitations or manual recovery instead of calling everything “success”.

You can install it with:

npm install -g pgdumpster

This is v0.1.2, so very much an early release and something I'm going to keep improving. I'm mainly posting it here because this community is literally the reason I built it in the first place.

If anyone here actually uses Supabase in production, I'd especially like people to try to break it, find weird project configurations I haven't accounted for, or run backup + restore tests and tell me where the workflow sucks.

It's free to use for normal/self-hosted use. The source is public, but I used a source-available license rather than an OSI open-source license because I don't particularly want someone taking it tomorrow and wrapping it in a competing hosted backup service.

u/Optimal_External1434 u/sandspiegel - there you go 🤷‍♂️

Been building an agent + BI platform where Supabase is the entire backend (auth, Postgres, RLS, storage, realtime). A few things that cost me time:

RLS on a nullable owner column. execution_traces.user_id is nullable by design — headless runs (API keys, schedules) have no user. My analytics page crashed on user_id.slice() for exactly those rows. If a column is nullable for a legitimate reason, something in the UI will eventually assume it isn't.

The service role vs anon key decision is a spend-control decision. Traces were written through the anon key with the caller's JWT. Headless runs have no JWT, so auth.uid() was null, inserts were refused, and spend that never lands in the table is spend the monthly cap can't see. Four runs cost real money while the cap reported $0.00.

Don't put large blobs in a jsonb document. I keep dashboard definitions in jsonb but row snapshots in a separate table, stripped at a single write chokepoint so no future caller can reintroduce the bloat. Learned that one the slow way.

Trigger-written version snapshots turned out to be the best thing I added — I corrupted a dashboard during testing this week and restored from history in about a minute.

Whole thing is self-hostable against your own Supabase project (hosted or self-hosted Supabase both work). Happy to share the migration structure if useful — there are ~90 of them now and the ordering discipline matters more than I expected.

For over two decades, agency hosting economics were beautifully predictable. You bought a reseller web server or dedicated cPanel account for $50 a month, crammed 30 client WordPress sites onto it, and charged each client a flat $25 monthly maintenance fee. Your margins were clear, your server bills were static, and billing surprises were virtually non-existent. Read the comple te article here > Serverless Bill Shock: Track Vercel & Supabase Client Costs | InstaRenewal

Then came the modern web stack.

Driven by the demand for lightning-fast digital experiences, agencies aggressively migrated to decoupled architectures: Next.js, Nuxt, Vercel, Supabase, Cloudflare Workers, and serverless databases like Neon. While the performance gains of this modern paradigm are undeniable, it introduced a chaotic operational reality: micro-subscription fragmentation and variable utility billing.

hey! i'm looking for an open-source, self-hosted way to back up a Supabase project: Postgres AND Storage bucket files, not just DB metadata

requirements:

• backs up Postgres and actual Storage files, not just storage.objects metadata
• can push to my own S3/R2 bucket
• automatable (cron / GitHub Actions / etc.)
• Open source, not a paid SaaS

anyone running something like this in production? what are you using?

i've found https://github.com/Yashdafade/Supabase-Backup-Manager and https://github.com/backupdrill/cli
but the very few stars doesnt make me super confident to try them, so looking to see if anyone knows about a reliable, free/DIY, option

How can I connect a static website to a database?

I have a static website built with HTML, CSS & JavaScript. I want to store posts/data permanently using a database.

Should I use Supabase, Firebase, or another BaaS?

What’s the best and most secure way to connect:

"Static Website → Database"

Any advice would be appreciated! 🚀

YSOP is a Open Source Project that brings multiple storage providers like Cloudflare R2, AWS S3 & Supabase into one place - to manage your storage, files, limits and links.

Even u can use multiple free tier Account of cloudflare r2 or other storage and limit the quota to prevent from billing exceeds.

https://www.producthunt.com/products/ysop-your -storages-at-one-place

Give an Star or contribution at:

https://github.com/Relaxkartikey/ysop

Please Upvote & Thanks. Open to your suggestions/ contributions.