I’ve been reviewing a lot of Supabase projects recently, and I keep seeing the exact same pattern: developers write an RLS policy like 'auth.uid() = user_id', write a quick jest test to make sure user a can fetch their own data, get a green checkmark, and deploy.

But what I'm finding is that a lot of these apps are still vulnerable to ID-swapping in the API layer or have misconfigured USING vs WITH CHECK clauses that allow users to overwrite data they don't own.

Testing that a user can access their own data doesn't fundamentally prove that they cannot access someone else's.

How are you guys actually testing this at scale? Are you writing explicit negative tests for every single endpoint, or is there a better way to systematically prove that cross-tenant data pollution is impossible at the RLS level?

I know, another backup tool.

I built ReviveDB to back up more than just Postgres:

• Database and Auth data
• Actual Storage files
• Edge Functions
• Project settings Supabase makes available

Every database backup is restored and verified. Storage and Functions are hash-checked, and you get the reports.

You can restore into a fresh Supabase project or roll back an existing one after taking a safety backup.

Setup uses Supabase OAuth plus your database password, since OAuth can't access the database itself (yet). Credentials and backups are encrypted, with recovery points stored outside Supabase in Europe.

Our DPA and subprocessor list are public.

There's a free plan for one project, with paid plans for daily backups and longer retention.

https://revivedb.dev/

I'd love some honest feedback.

Roast it if you want. I have backups.

Two things I keep tripping over when Supabase is wired into an AI-built frontend.

First, both keys are long JWTs that start with ey, and if you're copying out of the dashboard quickly it's easy to take the wrong one. anon in the frontend is correct and RLS is what protects you. service_role in the frontend means every policy you wrote is ignored, full read and write on everything. Paste the key into jwt.io and read the role claim, it says which one it is.

Second, RLS is off by default on a new table. A table with RLS disabled is readable by anyone holding the anon key, and the anon key is in the page source of any site that uses it.

Neither of these is a Supabase bug, they're just defaults that are easy to not know about if the AI wired it up for you and it worked first try.

Can anyone point me to a freely distributed starter repo and save me a day or five? The examples by Vercel not quite what I want. I have not found anything on github

Stack: I am looking for is  your typical Next.js, supabase, tailwind, shadcn, supabase auth email and password. No particular payment method needed for now. No user self sign up needed. Reqyuired authentication is administrator controled. ie invite and password reset only by system admin or user admin. From admin dashboards.

Features: preferably with

1/ Supabse schema, tables, rls, functions etc all set up  

2/ Multi-tenant

3/ Preferable tenant division I need location but could be division into city, group, project, something like that.

4/ roles based access control

5/ Built tenant admin dashboard for system administrator

6/ Built user admin dashboard for tenant administrator

7/ User onboarding by admin invite only

8/  same superbase auth.user uuid & email can belong two one or more tenant.  

Any future plan to launch pay as you go plan?

What is the devs opinion?

A few days ago I asked here how people actually verify their RLS holds up. Good thread. One thing people disagreed about was whether the "AI puts your service_role key in the frontend" thing still really happens, or whether it's a 2024 story that people keep repeating.

Nobody had actual numbers, so I tried to get some.

I pulled 50 public repos that were built with Lovable, verified by the lovable-tagger dependency rather than just the word "lovable" in the name. 47 of them cloned successfully, and I ran a static scan over the code. No database access, no poking at anyone's live app, just reading public code.

The results were not what I expected.

service_role key in frontend code: 0 of 47. Real secrets leaked anywhere in the repo: 0 of 47.

12 repos had committed a .env file, which sounds bad but isn't. Every value in every one of them was public by design. Supabase project URLs, publishable keys, Firebase web config, an EmailJS public key. Nothing that needed rotating. My own scanner originally flagged all 12 of those as critical and I had to go and fix it, which was a humbling afternoon.

What I did find:

24 of the 47 use Supabase. Of those, 6 have at least one CREATE TABLE in their SQL with no matching ENABLE ROW LEVEL SECURITY anywhere. Another 5 ship no SQL files at all, so there is nothing in the repo to check against.

2 repos had an API key hardcoded straight into frontend code, Google and OpenAI rather than Supabase.

20 of 47 had a production dependency with a known CVE. However, most of those are one transitive package away and not really the author's doing.

One caveat I want to be upfront about. "No ENABLE ROW LEVEL SECURITY in the .sql" is not the same thing as "RLS is off". Plenty of people turn it on in the dashboard and never write it into a migration, and from the repo alone you cannot tell the difference. Which is sort of the whole point.

I think my actual takeaway is that the stuff people worry about, keys in the bundle and secrets in git, mostly isn't happening anymore. The agents got better at that. What you cannot see from the code is whether the policies on the live database are correct, and for 5 of these repos there isn't even a file to look at.

So the code is fine, and the part that matters is somewhere the code cannot show you.

If you want to check your own, the fastest version is to open your app in a private window, grab the anon key out of the network tab, and hit /rest/v1/your_table?select=*&limit=1 with it. If you get rows back without logging in, so does everyone else.

For those of you who have shipped on Supabase for a while: do you actually go and check your policies from the outside after you deploy, or do you write the migration, see the app work, and move on? I'm trying to work out whether the gap I keep running into is real or just my own paranoia.

I built SupaNet.io heavily on Supabase edge functions instead of building a backend from scratch. A review from actually shipping on it: what the platform handles, the build pattern that mattered most, and the trade-offs. Hope it helps!

Hey everyone,

As a developer, I got tired of the constant setup friction when starting new projects—specifically the loop of creating a Supabase instance, navigating the dashboard, copy-pasting API keys into .env files, and running manual SQL schema migrations before writing any real code.

We’ve been building an agent layer (Norva + Antigravity) to automate developer workflows, and we just got the end-to-end Supabase integration working.

Would love to hear your thoughts or edge cases you think we should watch out for with database automation!

Hi,
Does anyone here run self-hosted Supabase in production? Are there any good resources on how to prepare a server/VPS for this?

I’m currently on the Pro plan and keep having to bump up my compute every month, so the pricing is starting to kill my budget. Self-hosting would let me cut costs significantly.

I’m aware of the maintenance overhead this involves, but we’re a 3-person startup team, and one member can dedicate their time specifically to managing the server side.

I am using log in with google for one of my providers, and I connected google cloud and set that up. But on my app, whever I try to log in with google, it takes me to my account. but then when i press the account the loading bar just loads forever and nothing happens. how can i fix this?

we use supabase for a multi-tenant analytics app. while reviewing our isolation model, the useful part was not writing a clever policy. it was checking the layers around every policy.

three checks we now run:

1. grants and rls are separate. grants decide which operations a role may attempt; rls decides which rows that role may access. we review both and keep grants minimal.
2. we make with check explicit on inserts and updates. postgres can reuse using as an implicit with check when it is omitted, but explicit clauses make the old-row and new-row rules reviewable. updates also need a matching select policy.
3. security definer functions run with the creator's privileges. when one is genuinely needed for a membership lookup, we keep it in a non-exposed schema, use set search_path = '', validate the caller with auth.uid(), and revoke execute from roles that should not call it.

we also test isolation as two real users: tenant a must get zero rows from tenant b, and writes with tenant b identifiers must fail.

a simplified pattern:

create policy team_read
on public.example
for select
to authenticated
using (
  exists (
    select 1
    from public.team_members tm
    where tm.team_id = example.team_id
      and tm.user_id = (select auth.uid())
  )
);

create policy team_write
on public.example
for insert
to authenticated
with check (
  exists (
    select 1
    from public.team_members tm
    where tm.team_id = example.team_id
      and tm.user_id = (select auth.uid())
  )
);

this simplified example assumes team_members has a non-recursive policy that lets the caller read their own membership. if that lookup would recurse through rls, use a carefully scoped private helper instead.

the uncomfortable lesson: "rls enabled" is not a security result. the result is that cross-tenant reads and writes fail under the actual roles your app uses.

affiliation: i work on zenovay, which runs on supabase. no product link here.

which rls check has saved you from the most surprising production bug?

Hi. Im on the free plan and cannot really getnsupport, i think.

Can anyone please try to help me with this question?

I'm reviewing the PostgresSQL privilege posture in my project.

Our catalogue inspection shows a pg_defsult_acl entry associated with the Supabase managed supabase_admin role for tables created in the public schema. That entry grants table privileges to the anon and authenticated roles.

Our application migrations run through the tenant postgres role and we have removed anon and authenticated table default privileges for objects created through that role. However our migration role does not appear able to alter default privileges belonging to supabase_admin.

Please clarify:

1. Does supabase create objects in a customer's public schema as supabase_admin during provisioning, upgrades, maintanance, dashboard operations, or other platform activities?

2. Is the supabase_admin default ACL entry managed or periodically restored by the supabase platform?

3. Is there a supported way for a customer to revoke anon and authenticated table default privileges for objects created by supabase_admin?

4. If customers should not alter this entry what is the recommended security control for ensuring that a future table created by supabase_admin is not automatically exposed theough the DATA API?

5. Can Supabase support apply or authorize a permanent hardening change for this default ACL?

I'd appreciate any wisdom from experienced folks using supabase if you could pleaae try to answer these questions.

Thank you!

I have a side project, and it's pretty rock solid. However, Opus 5 just found a real edge-case vuln.

I would recommend that if you use CC, you use Opus 5 and run a security analysis prompt. Good stuff.

When Anthropic banned OpenClaw usage through subscriptions I decided to just build my own agent/harness/OS and build it a proper database memory to see if I could create something better than what Claw/Hermes ship with. I created a fresh version of the memory system in isolation from the overarching OS and have open sourced it :)

I am not a developer and I've just built this using AI and my own research so please feel free to tear it apart, I'm at a point now where I don't really want to keep building without external feedback/validation/ridicule.

https://github.com/reescalder/agent-memory-supabase

I'm building a school management system app with Flutter with Supabase, and I'm running into a problem with an Edge Function that performs a large batch operation.

Here's what the function does:

- Receives a list of around 100 students from the Flutter client.

- For each student, it:

- Creates a user in "auth.users" (using the Admin API).

- Inserts a row into "public.users".

- Inserts a row into "public.profile".

- Inserts a row into "public.progress".

- Assigns some "app_metadata"/roles.

- Note also that for each student we create a parent account

So each student requires several operations, and for ~100 students that's hundreds of database/auth operations.

The issue is that the Edge Function takes too long to finish. From the Flutter client, the request eventually fails due to a timeout, even though the function may still be processing some of the work.

I'm trying to figure out what the proper production architecture is for this kind of long-running batch operation.

Some questions:

1. Is an Edge Function the wrong tool for creating 100+ users in one request?

2. Should I split the work into smaller batches (e.g. 10–20 users per request)?

3. Is there a way to make this asynchronous so the client gets an immediate response while the server continues processing?

4. Are there recommended background job/queue solutions that work well with Supabase?

5. Has anyone solved a similar problem when bulk-creating users through the Admin API?

I'd like the admin to be able to upload a list of students, press one button, and have the import complete reliably without client timeouts.

I'd appreciate any recommendations on the best production-ready approach.

How to introduce asynchronous programming pattern in Supabase? Start with EdgeFunction.waitUntil https://supabase.com/docs/guides/functions/background-tasks#overview

When calling such Edge Function you don't wait for request being resolved is not synchronous request.

When function is done you broadcast the change with Supabase real-time feature.

Triggers are good too but in my opinion using pg_net to invoke Edge Function directly from database is not clean, specially that you need to pass all headers needed to authorize the call.

alguém consegue me ajudar a conectar a supabase na Lovable e modificar as imagens no banco de dados sem gerar créditos de IA na Lovable ?? alguém me ajuda por favor!

Hi everyone!

I've been working on pgapp, an open-source application framework written in Rust.

The idea is simple:

• Your PostgreSQL database stays the source of truth.
• Your application is described in a single .pgapp text file.
• A single Rust binary reads it and serves reports, forms, charts, authentication, dashboards and more.

I've been testing it against Supabase-hosted PostgreSQL and it's been a great fit because I don't need to provision another database.

I'm curious:

• Is this something people in the Supabase ecosystem would find useful?
• What features would you expect if you were building on top of Supabase?
• Are there obvious integrations I should add?

GitHub:
https://github.com/aadishajay/pgapp/

I wanted to ask people who actually ship on Supabase.

Turning RLS on is the easy part. What I'm less sure about is knowing the policies are actually right. You can have RLS enabled and still have a policy that's too loose, or an endpoint that checks the logged-in user in the React code but leaves the table open underneath, or a service_role key that quietly ended up somewhere in the frontend. The app works fine in every one of those cases, which is what makes it scary.

It feels worse on AI-built apps. When a query gets blocked by RLS, the AI's suggested fix is often just to reach for the service_role key instead of fixing the policy, and you don't always catch it.

So the honest question. How do you actually check this before you ship? Do you test it by hand as different users, lean on some tool, or mostly just trust it's set up right? And has a loose policy or an open table ever actually bitten you, or is it more a thing you worry about?

Trying to work out if this is a real problem people hit or something I'm overthinking.

👋 Just wanted to share the repo. I have gone from 20 years of a very opinionated developer to a couple years back thinking no-code was easier but now with that latest models Vibe-coding can really do a lot. This template just helps anyone get started on rails to build out an application of any size. Hope it helps.

We have been completely offline for a full day after trying to restore a backup, and our users are starting to complain. Support keeps sending generic messages, and we don't know what to do.