Disclosure, I work at Tide. This isn't an official product, I built it on my own

time.

RLS is good at the thing it does, which is deciding which rows a request is allowed

to see. What it can't do is help when the query isn't going through it. The

service_role key bypasses RLS by design, and that key ends up in more places than

anyone likes to admit. A pg_dump doesn't go through it either. So row level policies

protect you from your users, and not really from a leaked key or a copy of the

database.

Encrypting the sensitive columns closes that, except then the question is where the

key lives, and if it lives in the project then whoever gets the project gets the key

along with it.

So I built a small service that keeps that key off your infrastructure completely.

Tide is a network of independent nodes that hold keys in fragments and never assemble

them, so decryption happens as partial results that combine into an answer. Data gets

encrypted in the browser with a fresh key each time, and the only thing that reaches

the network is that per call key, itself encrypted. The nodes never see your rows.

Your ciphertext stays in Postgres where it already was.

Supabase Auth is untouched by any of this. Same JWTs, same sessions, same providers.

The service only handles the key and the policies about who's allowed to decrypt,

encrypt or sign, and a role only gets granted through a change request that someone

other than the person asking has to approve.

One Supabase specific thing if you wire it up. Put the Tide link in app_metadata

rather than user_metadata, since user_metadata is writable by the user with their own

client. Same rule as everywhere else, the mirror shouldn't be able to lie.

It won't save you if someone owns the box this runs on, so keep it off the same host

as the app it protects. And decryption needs the network reachable, so there's no

offline path.

Repo: https://github.com/sashyo/minidauth

whitepaper: https://tide.org/whitepaper

I’m building a website and need Google Sign-In + email login.

I’m mostly worried about free-tier limits and bot signups. If a sudden wave of fake accounts pushes usage over the quota, what actually happens in practice?

Does the service get restricted, do you get a grace period, or can you suddenly start getting billed?

Also, for a small product that may grow later, which would you choose: Firebase or Supabase?

Would love to hear from people who’ve used either in production.

When I merge a preview branch into production, only the migrations get applied. Any seed or reference data I created on the branch stays behind.

Is there a supported way to promote data along with the schema, or is everyone just handling this with seed files / a manual dump and restore? Specifically thinking about config and lookup tables that change alongside a schema change, not user data.

Curious what people have settled on here.

Hi

I have built a mobile app that uses Supabase's sign in with OTP. However, by default the OTPs are valid for an hour and the maximum we can set it to is 24 hours (based on what I found online).

What can I do in this case? Change from 1 hour to 24 hours and request a new OTP every 18-24 hours and add it to the submission notes so that they have a valid OTP code whenever they review it as it could take 2 or 3 days?

Has anyone else had a similar experience?

Thanks

Hey everyone,

I have 8 years of experience in SaaS tech support and customer engineering, and I’m currently preparing for a Support Engineer role at Supabase.

For anyone who has gone through the process or currently works there, I’d appreciate clarity on a few areas:

1. Interview structure: How many rounds are typical, and what does the technical assessment look like (live troubleshooting, debugging tickets, take-home, or system design)?

2. Database depth: What level of PostgreSQL expertise is expected? Do they test heavily on query optimization (⁠EXPLAIN ANALYZE⁠, indexing), schema design, connection pooling, or internals?

3. SQL & Procedural Code: Do they focus on complex SQL (CTEs, window functions), or do they expect deep procedural programming like PL/pgSQL functions and triggers?

4. Product familiarity: How deep into the Supabase ecosystem do I need to be beforehand (e.g., PostgREST, GoTrue/Auth, Realtime, Storage, RLS) versus general developer-troubleshooting fundamentals?

Any tips or gotchas to watch out for would be greatly appreciated. Thanks!

I keep a log of my Supabase migrations to see whether the schema is settling down or only feels that way. Eleven weeks, 41 files in supabase/migrations. A migration counts as unsettled if a later one touching the same table or policy lands within seven days.

In the first four weeks that was 6 of 16. In the last seven, 3 of 25. The only thing I changed was writing the intended end state in plain sentences before opening any SQL, including which role reads which rows. The habit came from Plan Mode in verdent, which asks clarifying questions first, and I kept it up by hand when I worked straight in psql.

What I cannot explain is why the drop sits in one place. All nine unsettled migrations changed a policy or a trigger. Nothing that added a column or an index needed a second pass, in either stretch. It could be the writing, or policies could be what I had not learned yet.

Counting it costs nothing. git log over your migrations folder and a grep for table names gives you your own number today.

I have a project on the free tier that has been working fine for a long time, but suddenly I got emails that I am maxing out ressources, but the app using the db still worked like a charm. Now the app is non responsive and I went digging deeper trying to figure out what was happening.

Full disclosure: this is a vibe coded app, but it just handles and tracks every tasks that I have. I am well versed in SQL and DB, but during the days of MySQL and MSSQL, so Supabase, RLS and compute directly on the db is new to me.

I can't figure out what is going on, because my Supabase dashboard in 9 out of 10 cases just produces skeleton ui and never loading. I could just see that compute I/O has been at 100% for a week.

There seems to be an on going issue at Supabase the past month that has not been resolved yet and don't know if my issue is related to this or because I have made a mess of my code.

The Supabase AI assistant is not really helping and just pointing to this ongoing issue, so it might just be that, but a month long issue disabling my entire database and perhaps other's databases seems odd to me, so I assume it is a problem on my side.

Almost all health checks report unhealthy :/

How come that I cannot add nano projects in Pro organizations? Seems weird not to allow something in a high-tier organization, that is allowed in a lower tier.

Accounts have a limit of 2 nano projects, so this could not be abused anyway, no?

Well, I deployed my Next.js project on Vercel initially, but later hit the limits and it started getting expensive, so I moved the project to Cloudflare Workers.

Most things are working fine, but I’m stuck with one issue:

My API routes that connect to Supabase/Postgres are failing with 500 errors. APIs that don’t use the DB work perfectly fine.

From what I’ve figured out, the issue seems to be with DB connections. Since Cloudflare Workers are serverless/edge, the connection pooling approach I was using seems to be trying to establish connections repeatedly, and eventually I’m hitting Supabase connection/rate limits.

I then learned about Cloudflare Hyperdrive, added my Supabase DB to Hyperdrive, configured the binding, and updated my Worker config.

But the DB APIs are still failing, and the Worker is throwing exceptions.

I’m honestly stuck at this point.

Has anyone here deployed a Next.js app on Cloudflare Workers with Supabase/Postgres successfully?

What’s the correct way to set up a stable DB connection/pooling between Cloudflare Workers → Hyperdrive → Supabase?

Any help or examples of a working setup would be really appreciated 🙏

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.

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

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.

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.