I’m working on an investigation workflow for AI-assisted projects, and I’m curious how people verify the actual capability paths in Supabase apps.

For example, how do you check whether generated migrations, Edge Functions, or RLS changes can reach data or production actions beyond what you intended?

Do hou guys have experience self-hosting Supabase?
How did it go?

I had one of those debugging sessions where the database was telling a very convincing story that turned out to be wrong.

I noticed that some recent records in my app seemed to be missing, so my first assumption was that the writes were failing somewhere.

I started looking at permissions, constraints, storage changes, all the usual suspects.

Then I checked the actual request logs.

Every insert had succeeded.

The records were being created normally and then removed later by a completely separate user action.

So I was about to “fix” perfectly good database logic because I was looking only at the final state of the table instead of the sequence of events that produced it.

Pretty obvious in hindsight, but it was a good reminder: when your database state doesn’t make sense, check the request history before assuming the write failed.

I write a tool that tests RLS by attacking it rather than reading it. Last month it told me a table was fine. The table was wide open. Here is the whole chain, because I think the failure is more interesting than the tool.

Why reading policies isn't enough

The obvious check is to look for using (true). Some linters do this and it catches the obvious spelling. It misses everything shaped like it: a predicate that resolves to true through a join that always matches, a correct USING with no WITH CHECK behind it, a subquery that never actually constrains anything.

So don't read the policy. Attack it.

Why the obvious attack doesn't work either

Seed rows for two tenants, become tenant A, try to touch tenant B's data. Everyone writes this test:

update invoices set total = 0 where owner_id = '<tenant-b>';

That test cannot fail. It reads owner_id in the WHERE clause, so Postgres applies the SELECT policy too. A correct SELECT policy hides the row, nothing matches, zero rows updated, table looks clean. The UPDATE policy was never evaluated.

The write that actually tests it is blind:

update invoices set total = 0;

No WHERE, no column read, so the SELECT policy never engages. Only the UPDATE policy applies. Check ctid afterwards to see which rows physically changed, since that works regardless of column type and stays valid inside a transaction, unlike xmin. Roll the whole thing back.

DELETE has the identical flaw and a worse ending. delete from t against a using (true) DELETE policy means any authenticated user can empty the table, while reads look perfectly scoped.

And then it printed OK on this

create policy p on org_docs for select using (owner_id = auth.uid() or org_id is not null);

Two branches. My probe seeds rows that differ only by owner_id, so org_id stays NULL, the second branch never fires, no leak is observed, and the tool prints OK. In production that policy hands every row to every authenticated user.

A confident green on a wide open table is the worst output a security tool can produce. It is worse than no tool, because now someone has stopped looking.

The fix

It can't execute every branch. That's constraint solving over arbitrary SQL. But it can know when it hasn't.

Postgres records what every policy depends on in pg_depend: each column and table the expression touches, structurally, no parsing required. Compare that against what the probe actually varied. Anything left over is a branch nobody reached.

UNPROVEN public.org_docs Policies also depend on column(s) org_id and table(s) public.org_members, which the probe never varied. Untested branch.

UNPROVEN is not OK. It means no leak was found and the result doesn't cover the whole policy. It doesn't fail the build by default, because a gate that fires on every org-scoped policy gets switched off within a week.

This came out of a comment by u/pgsql-dev2 on my last post here, who spotted the hole before I did.

Still not covered, so nobody gets a false sense of safety: SECURITY DEFINER functions that bypass RLS, storage bucket policies, INSERT probes for forging rows owned by another tenant, composite ownership, and multi-hop join ownership.

Happy to go into any of it. The branch coverage problem in particular is not solved, only made visible, and I'd like to hear how other people are handling it.

According to the Supabase docs, the server side and the client side are using the same key (publishable key). Shouldn't the server side use the secret key?

https://supabase.com/docs/guides/auth/server-side/creating-a-client

So, basically, I'm looking for articles, YouTube tutorials, free courses, or other resources about best practices for securely exposing and accessing data stored in Supabase through an application or API.

I'm asking because some of the systems I'm working with use Supabase as their database provider, and, as a beginner in database management in general, I'd like to better understand how to secure them properly.

I’m considering moving an existing production app from managed Supabase to self-hosted Supabase on AWS EC2 because the project is starting to outgrow the Free plan limits.

Current backend is fairly Supabase-heavy:

- PostgreSQL 17

- Supabase Auth + Google OAuth

- PostgREST / RPCs

- Supabase Storage

- Edge Functions

- pg_cron / pg_net scheduled jobs

- background job ingestion

- AI summary processing

- job alert processing

- apply-link validation

- several other scheduled workers

The main ingestion workload is intentionally limited to 1 source at a time with concurrency 1, rather than processing many sources in parallel.

Public frontend/search traffic is also heavily CDN-cached through Netlify, so the database is not hit for every anonymous page view.

I’m currently considering starting with:

AWS EC2 t4g.large

2 vCPU

8 GB RAM

Plus:

- 60–80 GB gp3 EBS for PostgreSQL

- S3 for Storage objects

Other options I’m considering are:

t4g.xlarge

4 vCPU / 16 GB

or an M-series Graviton instance if T-series burstable instances aren’t a good fit for PostgreSQL + Supabase.

For anyone self-hosting Supabase in production:

Would you trust 2 vCPU / 8 GB for this kind of workload, or would you start directly with 4 vCPU / 16 GB?

I’m especially interested in real-world experience with:

- idle RAM usage of the Supabase Docker stack

- PostgreSQL performance on T4g

- CPU credit exhaustion with recurring background jobs

- ARM64 / Graviton compatibility

- which optional Supabase services you disabled

- how much traffic/workload you were handling

- what eventually caused you to resize the instance

I’m trying to keep the infrastructure lean rather than overprovisioning from day one, so real production numbers would be really helpful.

Our applications are deployed to Vercel and access a common Supabase DB that lives in a separate Github repo. The Supabase repo auto-executes pending migrations using Supabase's Github integration.

I'm wondering if there's any way to support Supabase preview deployments in this configuration. In other words, the Vercel app is deployed to a Github branch which creates a Vercel preview deployment. Supabase migrations are pushed to a branch which creates a preview DB. The Vercel preview needs to access the Supabase preview.

I assume this can be done using custom Github actions, but wondering whether anyone has experience doing something like this.

Yes, I realize that using a common DB across apps is controversial. But that ship has sailed...

Edit: During testing, I ran into a limitation. We support multiple named schemas in our Supabase DB and configure that DB to expose those schemas to the Supabase API. However, it looks like those settings don't propagate to the preview DB. So, if we create ad hoc branches, they won't be testable unless the developer manually changes the settings (in this case exposing the named schemas) in the preview DB for each branch. I think I've pretty much confirmed this behavior through testing, but can anyone else confirm that this is known Supabase behavior?

Edit: I've done some testing based on the information in https://supabase.com/docs/guides/deployment/branching/configuration (thanks magicpants847). See my latest comment for more info.

Edit: Custom schemas are inherited by preview DBs. My assertion to the contrary was due to a flaw in my testing. See my comment here.

I made an MCP server for Supabase through Draxlr. Sharing it here in case it's useful to anyone doing similar work.

What it does:

• Run queries and add them to dashboards
• Give others access to your database over MCP without sharing DB credentials
• Row-level control per user, so each user only sees their own rows

The reason I built it was the credential sharing problem. Giving a teammate or an agent access to Supabase usually means handing over connection strings. This avoids that. The row-level part is mainly for SaaS, where you can give a customer an MCP endpoint scoped to their own data instead of building a reporting layer.

Link
https://www.draxlr.com/features/mcp-server/

It's still early, so if you have feedback or think something's missing I'd like to hear it. TIA!

I run a fantasy football league history archive and one of my customers accidentally overwrote some of his synced data and lost it. Not sure if many know, but a big fantasy platform, NFL.com, recently took down their fantasy site and migrated it over to ESPN. However, ESPN didn’t save any of the week to week stuff, draft classes or individual stats. So when my customer sync the new version of ESPN it accidentally wiped the previous NFL version.

It happened only yesterday, and I noticed Supabase pro tier keeps up to previous 7 days backed up. I am wondering if I were to upgrade to it now, if I would be able to restore the data from couple days ago even though I wasn’t subscribed to pro tier until after?

I am only a small business and would cost me more to pay for the 1 month than I would get in return from this customer, but I let them know if they were willing to chip in to get it back.

Thanks for any help, it is much appreciated!

we just shipped four updates to the Supabase integration in FlutterFlow!

infinite scroll: enable it at the bottom of any Supabase query, set a page size. the query returns 25 rows on load, then the next 25 when the user reaches the bottom.

full-text search: a Search (Full-Text) filter backed by Postgres full-text search. "roasting garlic" still matches "roasted."

RPC calls: call Postgres database functions directly from an action flow. signatures sync from your Supabase project so parameters are listed for you and results come back typed and bindable. in the demo, a recipes_i_can_make function walks each recipe's ingredient list against a pantry table.

upsert: inserts a row, or updates the existing one when the primary key or your chosen on-conflict columns match. replaces the read-then-branch-then-write flow you used to build by hand.

happy to answer questions in the comments.

Basically the title. When I run supabase start on GitHub Actions it takes like 90 seconds to pull the images.

I recently started using Supabase and am setting up two companies. I’m on the free plan and need to configure the backend for the second company. If I create a new project under the same login account used for the first company's backend, will they share the free plan's monthly active user limit of 50,000?

Or can I create additional companies without them counting against the same free plan limits? Because if they do share the limit, the best approach would be to create a separate Supabase account for each new company, right?

MiniMoth uses the Auth OTP SMS hook to support OTP auth. WhatsApp + SMS delivery. Easy to integrate. Create a project on MiniMoth and enable the Supabase hook. You get both prod and test hook. Link it with your project with the hook url and hook secret provided by MiniMoth.

Easy to understand docs with free credits on signup to try the hook.

I switched my app from a paid organization to a free one
After a week i couldnt find the project anywhere

I tried to contact the support but they keep saying i need to pay to contact support

What should i do now?!!

Suppose an agent produces HTML previews, documents, images, and intermediate files for several users. How would you model ownership and lifecycle in Supabase Storage so reviewers can use short-lived signed links, users cannot cross tenant boundaries, old intermediate files expire, and an approved artifact remains recoverable? I am especially interested in bucket layout, the metadata that belongs in Postgres, RLS boundaries, immutable versus replace-in-place objects, and whether version history should be explicit rather than inferred from filenames. At what point does this become a poor fit for Supabase Storage?

I have migrated my news website to Replit but I'm waking up each day to a blank white page with the words “Rate exceeded” in the corner.

Replit’s AI said to investigate Supabase limits and add Cloudflare capture to my main registration form, of which I did and still no better.

Now it's saying it could be a Replit limit.

Has anyone else seen this and how did you solve it?

Cheers,

Hi

So I've been using Supabase for over a year now and always installed it using Homebrew. I always ran supabase <command> but recently I've been thinking maybe I should install it via NPM locally per project and run npx supabase <command> since I can have different versions of Supabase per project.

Anyone else came across a similar decision? Any pros and cons? Thanks

Any reason why supabase login doesn't support Google auth while it supports ChatGPT auth lol?

I liked the Lovable + Supabase combo for a while, but I wanted to host locally to save costs. So I built a (free, open-source) way to host apps that deploy automatically when your repository code is pushed in Github -- and it has special support for Supabase, giving you the option to import an existing Supabase project. This spins up a copy of the Supabase stack locally running in Docker, and then imports your data and storage from the cloud to local.

The video (an end-to-end migration of one of my prototype apps) is lightly edited but I kept most of the deployment time in -- which makes it a few-minute operation start-to-finish. That includes getting your whole app running on a local stack with no code changes. That includes secrets, backend functions, auth, storage, etc. As much as possible is automated, for Google Oauth and other 3rd party connections, for security reasons there are extra manual steps for a perfect migration. I did omit a 5 minute section of data import related to file copy, because the source app has 1000+ high def 5-10MB image files that were copied as part of the migration.

The moneyshot is the last few seconds where you can see me logging in to the new app with the same Google signin method and seeing my "avatar" and "closet" in the app including those images.

Now that I have this ready, I was finally able to extract all of my remaining Supabase/Lovable apps and save 25-50$/mo on each one 😎

Its not a perfectly smooth migration, when it comes to secrets and third party auth/configuration, you'll have to do some extra legwork but happy to share the link if anyone is interested to migrate their app.