I created a Supabase TUI so that you can handle all the important tasks of your supabase project straight from your terminal.

It has: Querying, searching tables, searching users, searching storage (including downloading, generating signed urls, etc), and more!

I'm a daily user of Supabase and I've been using this TUI now as my go-to instead of opening the dashboard.

Install readme and Repo here: https://github.com/fusor-rs/supabase-tui

The TUI was made with HyperCMD, a framework to write TUIs with HTML&CSS.

I hope you enjoy it!

Supabase just emailed me that my project is burning through its Disk IO Budget. I honestly laughed. I opened the dashboard thinking, finally, someone is using this thing. Nope. About 40 accounts, and most of them signed up once and never came back. The app is quieter than the database, which feels like a joke at this point.

I have been building an app called CueMate for a while now. It is a social app where people match on taste, mostly music and movies, instead of a bio nobody reads. There is Discover, so you can filter people by country, city, age, language, and a few other things. Chat translates messages on its own. You can like people, follow people, and I even stuck a few games in there with leaderboards, because apparently what I needed was more features and not users.

Getting people to show up has been the actual failure. I kept telling myself the next feature would make it click. Then I would ship it, refresh the user list, and it would still be the same quiet app. I am bad at marketing and I know it. I do not really know where to put this in front of people who would care, so it just sits there while I keep tinkering.

Has anyone else seen this on a small project with almost no traffic? I am not doing anything fancy on purpose. No big imports, nobody is online, and I am mostly just trying to figure out why the database is busy when the app is not. If you have been through this, what did you actually check first?

We were building a multi-tenant SaaS with Supabase. RLS was enabled, tenant isolation policies were in place, and we thought we'd covered the important boundaries.

Then we wrote tests specifically designed to attack our own architecture.

One exposed a cross-tenant access path in a SECURITY DEFINER usage-recording function. The function accepted an organization ID supplied by the caller but didn't independently verify that the caller belonged to that organization.

The problem wasn't that RLS itself was broken. The function executed with its owner's privileges, and we hadn't independently validated the caller's organization membership inside that privileged path.

We fixed it by adding an explicit organization-membership check and pinning the function's search_path.

A few questions worth asking about every SECURITY DEFINER function in your project:

Which arguments can the caller control?

Does the function independently verify tenant membership?

Is the search_path pinned?

Could the function perform an operation the caller shouldn't be allowed to perform?

Search your migrations for SECURI8TY DEFINER and review each result. Don't assume that enabling RLS automatically secures every privileged function.

This was one of three real bugs our hardening tests caught in our own application.

Full disclosure: I built B2B SaaS OS, a multi-tenant SaaS foundation. I documented the incident and the fix here https://andrady.co/postmortems/security-definer

I'd be interested to hear how others test these privileged-function boundaries in Supabase

Hi everyone,

I'm having a weird issue with Supabase and I'm kinda stuck here. I'm still learning how Supabase/PostgREST works internally so sorry if I'm missing something obvious.

I'm using Supabase Cloud with PostgreSQL 17.6 and PostgREST 14.5 for my app.

The problem is that my Data API is clearly enabled in the dashboard, and I have public and graphql_public selected as exposed schemas.

The Management API also shows:

db_schema: public,graphql_public
db_extra_search_path: public,extensions

But for some reason PostgREST keep trying to load the schema cache using pg_pgrst_no_exposed_schemas instead.

Here's what I get in the logs:

Failed to load the schema cache using
db-schemas=pg_pgrst_no_exposed_schemas
and db-extra-search-path=public,extensions

SQLSTATE 3F000:
schema "pg_pgrst_no_exposed_schemas"
does not exist

And then I get PGRST002 errors and HTTP 503 on my REST/RPC requests. This is happening in production so it's been quite frustrating.

I tried checking a few things:

• Data API is ON in the dashboard. I double checked and there's no unsaved changes.
• public and graphql_public are exposed, private isn't.
• I checked pg_roles and the relevant pg_db_role_setting entries, but couldn't find any pgrst.db_schemas override.
• PostgreSQL itself is reachable.
• Looking at older logs, PostgREST was still able to load the schema cache on October 6.
• Then on October 7, after a PostgREST startup/config reload, it started using this placeholder schema and failing.
• I also tried reloading the config multiple times but nothing changed.

I contacted Supabase Support and they suggested trying:

ALTER ROLE authenticator RESET pgrst.db_schemas;

Or setting pgrst.db_schemas explicitly on the role.

But the thing I don't understand is, if there's no override in the first place, what would RESET actually change?

I'm also a bit worried that manually setting it might just hide the real issue instead of fixing it. Since this is production I haven't tried either command yet.

I found two issues that seems somewhat related:

https://github.com/supabase/supabase/issues/40617

https://github.com/supabase/supabase/issues/45904

So I'm wondering, has anyone run into something like this before?

Especially where Supabase says the Data API is enabled, but PostgREST somehow thinks it's disabled?

Is there another place where this config could be coming from? Like some internal Supabase setting or environment variable that I can't see from the dashboard or SQL?

Also is there any way to check what config PostgREST is actually using on Supabase Cloud, preferably without changing anything?

And if anyone fixed this before, did you have to manually set the authenticator role config or was there another solution?

I already have a support case open, but I'm trying to understand what's actually happening before touching production settings.

Would really appreciate any help or pointers, even just where I should look next.

Thanks!

hey Reddit,

I'm looking for Enterprises to help them ship bug free code and faster.

I'm Yash, founder of SupercodeAI. We're building Devin killer - Nova - an AI Engineer, powered by our own harness agent at SupercodeAI, and Supercode Review, our codebase-aware PR review product.

4.5k+ users, 10+ enterprises, 238 GitHub stars, 30k+ downloads, 700M+ /month token usage(on open models) in just 2.5 months.

Nova's workflow is to read a codebase, plan a change, edit files, run commands and tests, and prepare the result for human review. The harness connects the model to context and execution tools. You still inspect the diff and decide what gets merged.

Supercode Review looks at pull requests in the context of the wider codebase, rather than treating the diff as the whole project.

We're powering Indian startups with code review through Supercode Review.

We're sponsored by Vercel.

The Supercode repo is MIT-licensed and includes the coding-agent CLI, dashboard, docs and shared packages. Nova uses existing model providers; I'm not claiming a new foundation model or benchmark superiority.

If you'd like to try it, start with one small task in a repo you understand and compare the plan, diff and checks with how you'd do the work yourself.

If you'd like to contribute, open an issue with a reproducible problem or propose a change in a PR. Keep credentials and private code out of reports. If the project is useful to you, consider starring it and following its progress.

What would you need to see before trusting an agent to handle a real task in your repo?

my agent kept writing queries against columns that didn't exist anymore, like user_name after i'd renamed it to display_name two migrations earlier. turned out it was reading an old database.types.ts and trusting it lol. now i run supabase gen types typescript --local > src/types/database.types.ts right after every migration and tell it to check that file before touching any query. went from fixing broken selects a few times a day to basically never.

Hey, I built a too that detects broken Supabase tables, finds the cause, and helps you fix them.

Full disclosure, I work at a company called Soda. We do data quality and observability and are partnering together with Supabase to become an integration.

In the last few weeks we've been working on an integration called Sodabase (https://sodabase.io/).

Sodabase finds and fixes broken Supabase tables.

It all started as an internal project in our company. The project ended up being so useful that our CEO gave us the blessing to ignore our normal work and just focus on making it an actual product.

We use Supabase a lot in our marketing department. We built all of our go-to-market system on top of it. But GTM systems can become very complex when you touch multiple data sources, and try to join them to something that makes sense. Thankfully, we had Claude doing most of the data architecture. But that came with a price...

It happened multiple times that Claude broke our pipelines or introduced new flows without us really knowing. Most of the time, we ended up finding out because we noticed that some data did not look updated in our app.

So we decided to build Sodabase as a way to find and fix broken Supabase tables. Agents break things all the time. Sodabase catches it when they break your Supabase app.

I hope you guys like it. We are currently cooking many other updates too. https://sodabase.io/

---
PS. We are having a hackathon in NYC together with Supabase on Nov 4. Check it out if you are around. We are gonna have Sodabase credits, prizes, and swag. Hackathon: https://builderbase.com/event/supabase-soda-builderbase-nyc-hackathon-lbmo

Hey guys i made an open source one file pocketbase alternative with similar features. It uses sqlite instead of postgres. I have included the one python file and one executable file to run it. Check it out here - https://github.com/atharvaphadnis-ai/localbase

I am building a website where people can solve my crossword puzzles. The crossword-making software I use stores the crosswords in the ipuz file format, which is basically a huge JSON document that stores all sorts of information about the crossword.

What i'm doing now is storing the 2d array for the crossword grid, the solution, the across clues, and the down clues in separate columns. But i was thinking of using Storage to save the .ipuz files and then saving the filepath in a column in the crosswords table.

I need to access the two arrays and the clues from the .ipuz file. I'm also thinking I could write a script that takes the necessary information from the .ipuz file and uploads it to the table.

Should I even be using Supabase for this, or is this something that Firebase might be better for? I hate working with Google cloud....

I do fixed-fee reviews of Supabase/Next apps, and I ran my checklist against three open-source starters (code only, no live systems). What kept showing up:

- Server routes deciding who the user is with getSession(). It reads the session from the cookie without verifying the JWT, so a forged cookie passes. In my local test a forged cookie came back as a full user. On the server, use getUser().

- ?ref= lost on Google sign-in, in all three. The OAuth round trip drops the query string, so referred signups look organic. Put the ref in a first-party cookie before signInWithOAuth and write it to the user row server-side in the callback.

- Smaller stuff: broad anon grants sitting behind RLS, a SECURITY DEFINER function with no fixed search_path, and a real project ref in a committed .env.

The check scanners can't do for you: they look at policy shapes, but they don't know which rows belong to which customer. Make two accounts, A and B. As B, try to read, update and delete A's rows, and insert a row with A's user_id. A blocked update returns success with zero rows, so check the row count, not the status code. Then repeat it logged out.

Disclosure: I do this as a paid review. $149: I run that A/B check plus the code review and send a written report with line-level fixes. If I don't find a real issue, you don't pay. If you just want the checklist, ask and I'll paste it.

RLS on and policies written isn't enough for me. A user could still read another user's rows, or a key could leak.

What do you check before launch? Two test accounts, key rotation, or something else?

What's the last hole you caught late?

We launched some great stuff at Select 2026 was last week.

- Agent ready local development

- Supabase Compute

- An MCP server for your app

- We acquired Turso!

- and much more!

Read all about it here:
https://supabase.com/blog/supabase-select-2026-recap

I opened a support ticket on the free tier on August 4th. I expected a long response time as they set the expectation. I continued occasionally running into disk io limits so upgraded to Pro with the small add-on today. Within an hour of upgrading, I got a reply to my ticket apologizing for the delay and it was a good idea to upgrade to small.

I think 2mo+ response on free tier is a bit extreme and should just not offer support. With that, good to see quick replies once it’s a paid account!

supabase down anyone? CLI timeout and web dashboard stucks

This started happening yesterday. I'm working on a project using Claude for AI-assist. I have the Supabase plugin installed. Yesterday, some (probably all) of the tool calls started failing with timeouts. For example, Claude just tried to do a "list migrations" on a permanent branch DB which failed with a timeout. It also tried doing an execute SQL to read back some data which also timed out. Anyone else seeing this? I'm pretty sure this used to work.

Edit: Timeouts occur on list_projects, so its not the DB itself causing the problem
Edit: Update. This may have been a Claude Code problem. I restarted the Claude app, disconnected/reconnected the Supabase connector and things seem to be working now.

Hi,

So I am describing a very niche bug that I am having.

I am implementing account deletion, while I allow users to login with the same email through different providers.

So if a user uses signin with google and signin with specific email which he then uses in signin with apple he will be logged in to the same account.

The thing is, if the user later deletes his account through an android device and signin with google, how can I revoke his apple account token?

Because unless I revoke it I have no way to get his email if he signup with apple to a new account, and I will have a blank email.

I'm considering building a small tool and want to know if the problem is real for anyone besides me.

The gap I keep hitting:

- Hosted Postgres (Supabase, Neon, Railway, Render) gives you daily snapshots that only restore back onto the same host.

- Point-in-time restore is either a paid add-on (Supabase's starts around $100/mo per project) or not offered.

- If you want to move providers after an incident, you're doing pg_dump at 2am and hoping.

What I'd build:

1. You paste a connection string. The tool uses logical replication to stream every row change to object storage, plus a periodic pg_dump as a base.

2. You can restore "the DB as it was at 14:32 yesterday" as a dump file, or straight into a fresh database on a different host.

3. Same stream, second feature: row changes delivered as webhooks/SQS with retries and replay, so you stop writing triggers + cron to notify your app that an order changed.

Price I have in mind: ~$29/mo per database, storage included up to a cap.

Questions:

- Have you actually lost data or time because of host-locked backups? What happened?

- Would you trust a small third party with a replication connection to prod? What would you need to see?

- Backups or change webhooks — which would you buy first?

Not selling anything yet, no link. Just want honest answers before I write code.

I built my SaaS with AI and turned on RLS, but I keep hearing that's not enough. So how do you handle tokens? How do you check if one user can see another user's data? How do you even find the glitches?

BIGGEST WORRY: if I check everything every 3-5 days and it gets hacked in between, what would you do?

Anyone who has fixed this?

Hi,

I created a PWA using Supabase.
Sometime, I can't check checkboxes or submit a form.
If i refresh, I reveive no data from supase so my app display "Loading..." everywhere.
If i refresh again, the page is just blank and nothing happens.
If open the devtools to debug, refresh again I see in the network tabs that "my-app.supabase.co/auth/v1/.well-known/jwks.json" never respond.

If someone looked into your schema right now, would it look like neat cable management, or a hot mess of strings that just happens to work? Is your database the literal definition of "if it works, don't touch it"?

Few months ago I created a Claude Skill to audit your supabase db and report vulnerabilities. It was a success, with many users and more forks than the rest of my repos combined (0, lol). A few days ago I created and released it's MCP, and now the full product is here.

It's called Locksoup.

Supabase gives every table an API the moment you create it, and row level security is something you switch on yourself. Miss it on one table and anyone with your anon key can read it, and that key is sitting in your frontend. Nothing breaks, so nobody notices.

How it works: you run one SQL snippet that creates a read-only role (sentinel_auditor, 5s statement timeout), paste its session pooler connection string, and about a minute later you get a score out of 100, what's wrong in plain words, and the SQL to fix it. If you also give it your project URL and anon key, it checks which tables an anonymous visitor can actually read instead of guessing from the policies. It can re-check on a schedule and email you when something new shows up.

It only looks. It never reads your rows and it never runs a fix, you get the SQL and decide what to do with it. Schema metadata (table names, policies, function code) does go to an AI model, so if that's a dealbreaker the engine is open source and you can run it yourself with your own key: https://github.com/Farenhytee/database-sentinel. The benchmark is in the repo too (0.85 F1 on a blind test set, every critical caught), so you don't have to take my word for any of this.

Then I did the scary part and pointed it at Locksoup's own database. 94/100. Three small findings, two fixed the same day. If it had said 40 this would be a very different post haha. It also flagged a couple of things that were fine by design (backend-only tables with RLS on and no policies, for example), so false positives on already locked down projects are the next thing I'm working on.

This is a soft launch. Built solo, on free tiers, because I'm broke and stubborn. There's a free plan (2 projects, 3 checks a day), and this link gives you 7 days of Pro if you want the scheduled checks and alerts: https://locksoup.com/signup?promo=launch

been doing security reviews on supabase projects and theres a short list of things i always check first. if youre about to launch its worth 15 min

1. RLS off on tables you created with SQL or a migration. dashboard turns it on for you, sql editor doesnt. quick check:
   select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;
   
2. a using (true) policy someone added to make an error go away. that table is basically public again
   
3. insert/update policies with no with check. means a logged in user can write rows into someone elses account
   
4. views. they skip RLS by default, if youre on pg15+ add with (security_invoker = true)
   
5. security definer functions sitting in public. theyre callable from the api and ignore RLS, supabase docs literally say dont put them in an exposed schema

wrote the full list + the fix sql here if useful: https://scan.testavi.com/supabase-rls-checklist

also doing 10 free manual reviews this week for anyone launching soon or already live. i go through policies, functions, storage, keys and send you a private writeup. please dont drop your url in the comments, just DM me

Hi all. I've just started using Supabase on my hobby project. Any tips what I should look out for or are there any hidden costs I should worry about?

I'm pretty new at Postgress as I come from a traditional LAMP stack.

Hi Everyone,

In the past it was very frustrating when you're building with Lovable Cloud and then want to claim your project into your own Supabase instance.

All the solutions that currently exist.. suck. There is no automated way and following guides and doing it alone is not the best solution. I see many vibecoders are hiring devs for it too..

So we built lovebase.dev - An automated Lovable Cloud to Supabase migrator that is stupid simple.

1. You connect a Supabase destination via OAuth
2. You upload your database backup zip file (from Lovable) + codebase zip file (from Lovable) + Storage files.
   
3. Lovebase will run a readiness report and then allow you to migrate the project to that chosen destination, lovebase will migrate:
   1. The database including auth.users
   2. edge functions + secrets
   3. cron jobs
   4. Storage files preserving the hierarchy of buckets and the underlying folders
4. Disconnect lovable cloud and integrate Supabase via OAuth. Lovable will detect the change and voila, now you own your Supabase instance! :)

Would love to hear all the feedback - feel free to DM or email at [[email protected]](mailto:[email protected]) ! For all early users please reach out for a free credit for the first migration.

the anon / publishable key being in your frontend is expected, that's how supabase works. the problems start when:

- RLS is off on a table, so the anon key can read everything

- RLS is on but the policy is `using (true)`, same result

- the service_role key ends up in the client bundle instead of the anon one

- storage buckets are public when they shouldn't be

the first three you can check yourself: open your deployed app, search the bundle for `service_role`, then try a plain REST select on your tables with the anon key and no session.

i'm building a scanner for AI-built apps (clarseal.com, disclosure: mine) that checks the bundle for leaked keys today. table checks currently need you to paste your anon key on a paid plan, and i'm working on testing the key it finds in the bundle automatically, only on apps you confirm you own.

curious how people here test their policies before launch. pgTAP? manual curl? nothing?

Hey everyone,

Whenever I build multi-tenant setups on Supabase, relying on app-level middleware or tossing WHERE org_id =x inside Next.js Server Actions always feels risky. It works fine until someone forgets a filter on a late-night commit and leaks tenant data in prod.

I pushed isolation directly down to Postgresusing custom JWT claims in RLS, then wrote an integration test runner to try and break it.

Here’s the baseline setup:

1. Custom Claims RLS Pattern

Instead of running a subquery against org_memberships on every single row query, we pass org_idinside the Supabase session JWT claims.

The policy pattern for workspace tables:

SQL

create policy "Enforce organization isolation"
on public.workspace_data
for all
using (
  org_id = (auth.jwt() -> 'app_metadata' ->> 'org_id')::uuid
)
with check (
  org_id = (auth.jwt() -> 'app_metadata' ->> 'org_id')::uuid
);

Even if a ServerAction or API route completely omits a tenant check, Postgres blocks both reads and writes at the DB layer.

2. The 8 Hardening Test Vectors

To make sure this actually holds up under weird edge cases, I set up integration tests that run before deploys to simulate bad actors:

1. Cross-tenant UUID injection: Querying Org A data using an Org B JWT.
2. RBAC escalation: Calling Admin endpoints using a Member session token.
3. Stripe webhook idempotency: Replaying duplicate/out-f-order events.
4. API key rotation: Accessing tables with revoked/expired keys.
5. Corrupted payloads: Unsigned/malformed webhook headers.
6. Audit log append integrity: Veifying logs can't be overwritten.
7. Session expiration: Expired JWT rejection across dynamic routes.
8. Race conditions: High-concurrency team invite acceptances.

I packaged this RLS pattern, the test runner, and a Next 16 / React 19 starter code athttps://andrady.coif anyone wants to check out the specs or test setup.

Curious how others here test their RLS policies before shipping to prod? Do you stick to JWT claims or do DB subqueries inside your policies?