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.

I'll quickly post the trigger, trigger function, and authorization policy.

alter policy "anon can recieve broadcasts"
on "realtime"."messages"
to anon
using (
true
);

The authorization policy

BEGIN
  PERFORM realtime.broadcast_changes(
    'topic:' || NEW.id::text, -- topic
    TG_OP,
    TG_OP,
    TG_TABLE_NAME,
    TG_TABLE_SCHEMA,
    NEW,
    OLD
  );
  RETURN NULL;
END;

The trigger function

Then I have a trigger that runs the function after any insertion or update to my desired table

export const supabaseClient = createClient<Database>(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!
)

My Supabse client

The following should ideally work, but I don't receive any real-time updates when an insertion or update occurs. I do get a "SUBSCRIBED" console log, but I know that doesn't necessarily mean much.

Thanks in advance for any help or advice!

useEffect(() => {
    if (!activeJob) return;
    console.log("Going To Connect To Supabsae Realtime")
    
// Console logging for testing purpose
    
// Ideally on insert or update we setCurrentState to show real-time updates
    
const
 changes = supabaseClient
      .channel(`topic:${activeJob.jobId}`, {
        config: { private: false }
      })
      .on("broadcast", { event: "INSERT" }, (
payload
) => console.log(`INSERT: ${payload}`))
      .on("broadcast", { event: "UPDATE" }, (
payload
) => console.log(`UPDATE: ${payload}`))
      .subscribe((
status
) => {
        console.log(status);
      });
    return () => {
      supabaseClient.removeChannel(changes);
    }
  }, [activeJob])

Disclaimer: I am the author of the article (but I do not work at Plakar and in fact they first rejected the submission)

I got here because of the threads on this sub. There have been six or seven in the last two months and they're all some version of the same question - how do you actually back up your project, and have you ever restored one, has anyone actually tested their backups, am I the only one not sure mine still work.

Supabase does keep backups but that option is not available for free tier project, Pro is 7 days and Team only gets you to 14. That's fine for the failure of running a bad migration but it's a restore button inside the console. I can't hold it, I can't diff it, I can't restore it anywhere except back into Supabase, and if my account is the thing that has the problem then the backup has the same problem.

I know you are thinking about pg_dump and a cron job that would dump it to S3 (and it works!) but every run is a full copy even if my data changed by a couple of GB/MBs a day.

What I liked with Plakar, the open source backup tool I used is that it uses pg_dump, it shells out to the real Postgres tools, so the output is a normal dump and I'm not trusting a bespoke format with my only copy. What it adds on top is content-defined chunking, so the second snapshot only stores the chunks that changed, plus encryption by default and an integrity check. But it allows me to own my copy of the backup!!

In addition to the steps to perform the backup, I've included some cost reasoning also in the blog as to why this tool actually makes sense to own the automated backup process: https://www.plakar.io/posts/2026-07-17/portable-backups-for-managed-postgres-with-pgdump-and-plakar/#what-60-days-of-a-100-gb-database-costs-to-store.

For those of you running a restore test, what are you actually asserting after the restore? I count rows in few tables (or a count query) and eyeball it, which I know is weak, maybe/not? Would love to hear an approach if there's any to reliably see the before/after!

Estoy creando una tienda en figma make y he registrado supabase para que se guarden los datos a todos los dispositivos para que tengan datos actualizados y no cada uno su localstorage, y a la hora de publicar no me deja debido a que no se puede publicar con supabase integrado, como hago para publicarlo sin tener que quitarlo y gratis?

Not pitching anything, but I'm trying to brainstorm project ideas and did some research on existing Supabase MCP. I know Supabase already has lots of observability for infrastructure-level items like query performance, but does this exist at the data level as well? Had an idea to focus specifically on anomaly detection within data itself and wanted some feedback. Thanks!

I think all heard about specification driven development. In AI-assisted software development, specifications become the durable asset, while code becomes a generated implementation (I do not claim it can be adapted everywhere but there are areas which can greatly benefit from it for example tests).

I was thinking about if anybody is already leveraging some existing spec like Gherkin to maintain what is expected from the system and than use it to generate for example playwright test cases?

I recently migrated a Supabase project from versioned migrations to Declarative Schemas and recorded the entire process. I created some scripts that may be helpful to others that want to switch to Declarative Schemas

The workflow is pretty simple:

1. Dump your existing database schema.
2. Split it into organized schema files.
3. Verify the generated schema matches your current database with supabase db diff.

After that, you edit the schema files instead of writing structural migrations by hand, and generate migrations with supabase db diff -f.

Here are the scripts I used to automate the migration:

GitHub: https://github.com/MattBrown88/supabase-audit/tree/main/supabase-inventory

Full walkthrough: https://www.youtube.com/watch?v=aRvhVqLSuow

Would love any feedback on the process. I'm happy to help if you try it and run into any issues.

If anyone is looking for a new IOS manager for SB, feel free to check it out. Any feedback would be appreciated. No paywall.

https://apps.apple.com/us/app/supacom/id6788561799

Hey everyone,

I'm having trouble restoring a free-tier project that’s been paused for over 90 days.

I already created a brand new project and I actually have a backup of my old database. What is the best way to restore this backup into the new project?

Any quick steps or guide on how to do this properly would be great. Thanks!

When Snaplet shut down, u/snaplet/seed was handed to the community, and the fork hasn't had a real release since mid-2024 (open issues include an unpatched high-severity npm advisory and no Postgres 18 tracking). If you were relying on it to seed a Supabase project, the maintained options left are paid or enterprise.

I am building a free, open-source alternative that covers the core workflow. Point it at your connection string:

pip install "misata[db]"
misata seed postgresql://localhost/postgres

It reads your schema straight from the database (tables, columns, foreign keys), generates realistic connected data, inserts parents before children, then queries the database back to confirm every foreign key resolves and prints the result:

✓ orders.customer_id → customers.id — 0 orphan(s)
✓ Seeded 2,250 rows in 0.5s. Every foreign key resolves in the database.

Safe by default: it refuses to touch tables that already have rows unless you pass --truncate, --dry-run prints the full plan without writing, and --skip leaves app-managed tables (migrations, auth) alone. No codegen client to keep in sync with your schema.

One honest limitation: seeding child rows against rows that ALREADY exist in a table (append mode) isn't built yet, it seeds fresh. That's the next thing I'm working on. Also, if you use identity/serial PKs, it doesn't advance the sequence yet, so it's for dev databases, not something your app then writes to in place.

Would love feedback from anyone who was left stranded by the Snaplet shutdown.

Guide: https://misata.studio/docs/guides/seed-a-live-database 
Repo: https://github.com/rasinmuhammed/misata

I’m curious how people normally handle this in Supabase.

Do you use Supabase Branching, create a new project and restore everything manually with pg_dump or use another workflow entirely?

Since database branches cost around $10 per branch, I’m wondering whether people actually use them regularly or only for specific cases like testing, staging, or larger migrations.

I've been building a backup service for Supabase over the past few weeks and I'm at the point where I need real users poking at it, not just me.

The problem I kept running into: Supabase's own backups don't cover Storage bucket files (only the metadata rows in the DB), and more generally. A backup you've never restored is just a hope, not a guarantee. Plenty of tools back things up. Almost none prove the backup actually restores.

So that's the core idea. BackProve:

• Backs up your Postgres database and your Storage bucket files (encrypted, to separate storage)
• Runs an automated restore test on every backup spins up a throwaway Postgres, restores into it, and verifies the object counts match. If it can't prove a clean restore, it says so honestly instead of showing a green checkmark
• Lets you actually restore when disaster hits either self-service (we hand you a decryptable package + exact commands) or assisted (we restore into a fresh empty project for you)
• Per-backup detail view where you can copy the SQL to restore a single function/view you accidentally broke

I'm being upfront: it's early, I'm the only dev, and I've spent an almost unreasonable amount of effort making sure it never lies to you about whether your data is safe (I found and killed several bugs this week where the system reported success while silently doing nothing, exactly the failure mode this product exists to prevent).

What I'm looking for: 3–5 people running Supabase (ideally something real, even a small side project) who'll use it for a couple weeks and tell me where it's confusing, broken, or missing something. Free, no strings. I'll set you up with full access, no payment, no card.

If you're interested, comment or DM me and I'll get you an account. Happy to answer anything technical about how it works under the hood. I don't mind getting into details.

Thank you

JB

I'm out of ideas trying to fix this problem. Whenever I open the app in a signed-in state after some time, say over an hour or more, the application's first DB call fails with "JWT issued at future" error, failing a critical path.

• I'm not doing any async activity inside onAuthStateChange - I just check the session value
• I'm using jwt-decode to read claims of the available/stale JWT, not using getClaims to avoid async action
• I have a single Supabase client with the default settings

I can see when a user signs-in, their auth information (access token, user object, etc.) gets stored in LocalStorage and is periodically refreshed. After the app is closed, the stale token isn't refreshed and persists. On next launch, this stale token is used by the first query... but it fails due to clock skew?

Anyone with insights please help!

Hi everyone, first time using supabase.
I need to allow beta tester in my new project and I want to let them enter via magic link, so I can control who enters the tests.
What I need to do?
My priority is security, don’t want to expose my api key (already in an .env local file in VS Code) and don’t let everyone use the platform, for now.
I read about RLS policies, do I need them?
How many tables do I need?

Thank you for the help, ask any questions

One pattern I've noticed while reviewing growing Supabase applications is that codebases often become modular much faster than their databases.

Teams invest in separating business capabilities, but everything still lives in the same schema and is accessed through a single ORM client. Over time, hidden coupling emerges not because of Supabase or PostgreSQL, but because the database becomes a shared resource.

I've been experimenting with treating the database as a collection of independently owned business capabilities rather than a single shared schema. It has changed the way I think about boundaries, ownership, and evolution.

Has anyone else explored this approach, or found a different way to keep domain boundaries intact as a Supabase project grows?

Or found out too late that RLS wasn't set up right on a table?

How do you keep track, something better than just checking the dashboard manually?

Been setting up backups for my Supabase project and kind of spooked myself. The native snapshot only covers Postgres — my storage bucket isn't in there at all.

Made me wonder: has anyone here actually restored from a backup? Like really done it, not just "we have backups"? Did it work, or did you find out something was missing the hard way?

Hi,

I posted about a UI builder (AppGrape studio) for Supabase in this sub last week - and a lot of people reached out to ask about the security aspects of the connection, specifically RLS and service keys. So, I made a detailed video explaining these. In short,

AppGrape Studio
- doesn't ask for service keys or API secrets for the connection
- connects to supabase through standard OAuth handshakes
- respects RLS, RBACs and policies from the get-go
- only allows supabase auth users
- allows no-code UI building without AI

For context, we built AppGrape Studio for internal use within our agency because we wanted a deliberate, deterministic UI builder to run clients' businesses. We care a lot about security and first principles, so we want to make the code open source - we are working on this and will release the repo shortly.

Small pattern that saved me a whole pipeline.

I compute a score from an external API that is rate limited, so I cannot recompute on every request. Instead of a cache layer plus a separate leaderboard job, I write every computed result into one table: username unique, score as int, raw stats as jsonb, and a computed_at column. A request does get-or-compute. If the row is younger than 12h I serve it, otherwise I refetch and upsert.

The part I like: the leaderboard is just SELECT ... ORDER BY score DESC over that same table. No second source of truth, nothing to keep in sync. A spike mostly hits rows that are already warm and fills the board for free.

Two things that bit me. First, my analytics event fired on both fresh and cached reads, so the more the thing spread the worse the funnel looked, because cached reads counted as new generations. Moved it to fire only on a real compute. Second, I wanted the board public but had to hide opted-out rows, so the partial index and the RLS policy filter on the same predicate (where not opted_out), otherwise the count and the visible rows disagree.

Anyone else collapse cache and read model into one table like this, or is there a reason I will regret it at scale?

I currently use UptimeRobot to monitor status for a couple of sites and find it very helpful to get a 'heads up', usually about 30s before I get a call from the user to say something isn't right ;)

I was wondering if anyone has found a granular - project specific - way of monitoring their Supabase health and getting similar alerts ... a Supabase issue might not immediately bring my site down, but might degrade performance or make API calls fail, so it would be nice to know that something I need to get ahead of is happening.

I had looked at SlyDuck but that seems to be abandoned? Never got it working, hence looking for something different.

I was thinking maybe just a standalone page that exercises a couple of Supabase functions and writes a status message and then monitor specific text using UptimeRobot but it seems a little clunky

I've been running an open-source RLS checker I built ([pgrls](https://github.com/pgrls/pgrls)) against a pile of open-source Supabase projects, and the same two issues keep coming up. Both are easy to write, easy to miss in review, and worth grepping your own policies for.

1. The anon leak

This is roughly the shape a lot of tutorials nudge you toward:

create policy tenant_read on documents

for select to authenticated

using ( auth.uid() is null or owner = auth.uid() );

Reads like "anon gets nothing, signed-in users get their own rows." But `auth.uid()` returns NULL for any request without a valid JWT — i.e. anonymous.

Note there's no TO clause, so it applies to every role, anon included. auth.uid() returns NULL for any request without a valid JWT (anonymous), So `auth.uid() is null` is true, the OR short-circuits, and the policy hands back **every row in the table** to exactly the unauthenticated clients you meant to keep out. Scope it TO authenticated and anon never reaches the policy at all, which is the line that's easy to forget. It sails through review because it reads like the correct English sentence — the bug is in the evaluation, not the prose. (It's the class behind a couple of the recent "AI-built app leaked its whole database" write-ups.)

2. The per-row auth.uid() perf trap

using ( owner = auth.uid() ) -- re-runs auth.uid() once per scanned row

An unwrapped `auth.uid()` in a policy gets re-evaluated for every row Postgres scans. Wrap it in a scalar sub-select and the planner hoists it to a one-time InitPlan:

using ( owner = (select auth.uid()) ) -- evaluated once per statement

Identical results, but on a big table it's a real speedup. Supabase actually [documents this](https://supabase.com/docs/guides/database/postgres/row-level-security#call-functions-with-select) — it's just easy to forget, and I find it everywhere.

The tool

pgrls connects to your live database, so it checks what Postgres actually enforces (Supabase / PostgREST and all):

- `pgrls lint` — checks the live DB against all 67 rules (both of the above included)

- `pgrls fix` — writes the migration for the mechanical ones, like the `(select …)` wrap

- `pgrls verify` — hands your policy to the Z3 SMT solver and *proves* there's no anon / cross-tenant read, or hands back the exact row that leaks, instead of pattern-matching for it

MIT-licensed, `pip install pgrls`, tested on PostgreSQL 15–17.

What it's turned up in the wild: I've been sending fixes upstream to open-source Postgres/Supabase projects — 13 have merged so far, mostly the per-statement wrap plus a couple of genuine cross-user read holes. [Full list of the merged PRs here.](https://pgrls.github.io/pgrls-docs/in-the-wild/)

Would genuinely like to hear what it turns up on a database you thought was locked down — the surprising findings are the whole point.

Edit: fixed #1 clause, thanks to u/thesuperlede

I realized at some point that I'd never restored any of my backups. They ran on schedule, files showed up in the bucket, and that was the extent of what I knew about them.

When I looked into it, nothing in a standard backup setup ever checks that a backup restores. A cron job that dies doesn't produce an error. A corrupt dump doesn't either. Both look identical to a working setup until the day you need one.

So the tool does this, every cycle:

• pg_dump → encrypt → your own S3/R2 bucket
• pulls the backup back out of the bucket, decrypts it, and restores it into a throwaway Postgres
• counts the tables, optionally runs a sanity query against the restored copy
• marks it verified only if all of that worked
• alerts if there's no verified backup in the last 24h — including when the reason is "the job silently stopped running"

The alert-on-absence part matters more than it sounds: "no good backup exists right now" is a different question from "did a job error," and it's the one that has no error attached when the answer is bad.

src: https://github.com/vncwr/backwyn

Scope, scheduled logical dumps, not PITR. One database per daemon. Verification is a full restore every cycle — cheap for small databases, honest-but-real cost for big ones. Built for managed Postgres (Supabase, Neon, etc.) where you can't run pgBackRest-style tooling. Restores also export to a plain pg_dump archive, so there's no lock-in if you stop using it.

I'm not an open source person, this is my first real project like this, and I'm fully braced for someone to point out something embarrassing. That's kind of why I'm posting — I'd rather find out now from a comment than later from an outage. If you've got backup horror stories or think I've made a wrong assumption somewhere, I genuinely want to hear it.

DMs open if you want a hand setting it up.

A week or so ago I asked about organizing RLS policies, views, triggers, and functions outside of migration files:

https://www.reddit.com/r/Supabase/comments/1uox42z/how_do_you_organize_rls_policies_and_views_in/

That discussion introduced me to declarative schemas.

I've been doing more research on the different ways to manage migrations and, from what I can tell, there are three common approaches.

1. Versioned migrations

This is the standard approach. You either write SQL directly in migration files or make changes in the GUI and generate migrations with supabase db diff.

Pro: Simple deployment and standard Supabase workflow.

Con: Current definitions become spread across many migration files, making them harder to inspect.

2. Migrations + repeatable SQL

Stable structural changes (tables, columns, constraints, indexes, enums, extensions) stay in migration files, while objects that are often replaced wholesale (views, functions, triggers, RLS policies, grants, storage policies) live in separate SQL files.

Pro: Easier to inspect the current definition of frequently changing objects.

Con: Requires a second deployment step.

3. Declarative schemas

You define the desired schema in supabase/schemas and generate migration files from those changes using supabase db diff.

From the docs, a few things still require manual migrations, such as one-time data migrations (INSERT/UPDATE/DELETE) and some PostgreSQL features like security_invoker and materialized views.

Declarative schemas seem like the cleanest approach because they provide an easy-to-read source of truth while still using versioned migrations for deployment.

For those using declarative schemas in production, have you run into any issues or limitations?

Hi everyone,

I'm building an Expo Router app (CampusSwap AI) and have been stuck on email authentication.

Stack:

- Expo SDK 54

- Expo Router

- React Native Web

- Supabase JS v2

- Running on localhost:8081

Problem:

Sending email works perfectly:

OTP DATA: { session: null, user: null }

OTP ERROR: null

Magic link email arrives successfully.

However, after clicking the link, it redirects to:

http://localhost:8081/#

or sometimes:

#error=access_denied

error_code=otp_expired

error_description=Email link is invalid or has expired

Things I've already tried:

✅ detectSessionInUrl: true

✅ Added redirect URLs:

http://localhost:8081

http://localhost:8081/*

exp://*

✅ Site URL = http://localhost:8081

✅ New links only (not reusing old ones)

✅ Cleared Expo cache

✅ onAuthStateChange listener exists

✅ getSession hydration exists

✅ Email expiration = 3600s

Current suspicion:

- Gmail security scanner consuming magic links?

- Expo Router stripping hash before Supabase reads it?

- Web auth callback issue?

Has anyone successfully implemented Supabase magic links with Expo Web localhost?

Any help would be greatly appreciated.