Does Supabase Have Push Notifications?

No. Supabase has no built-in push notification service.

There is no supabase.notifications.send(), no push section in the dashboard, and no managed delivery to iOS or Android devices.

But plenty of Supabase apps send push notifications, and that is the more useful question. There are three ways to do it: write the pipeline yourself, bolt on a general-purpose push service, or use a notification layer built for Supabase like Entrig that sends them automatically when your data changes. They are nowhere near equivalent, and picking the wrong one is how a weekend feature turns into something you maintain forever. Skip to the three options if that is all you came for.

Two things are worth getting straight first, because they are what people get wrong. The first is what Supabase gives you instead of push. The second is why Supabase Realtime is not a substitute, which is the most expensive wrong turn in this space and an easy one to take, because Realtime looks like it works right up until the moment your app is closed.

What Supabase Actually Provides

Supabase is a Postgres platform with a set of services built around the database:

• Postgres database with row level security
• Auth for user management and sessions
• Storage for files
• Realtime for live database changes over a websocket
• Edge Functions for server-side code
• Cron, Queues, and Vector for scheduling, background jobs, and embeddings

Push notifications are not on that list, and the omission is structural rather than an oversight. Sending a push means holding credentials with Apple’s APNs and Google’s FCM, tracking a device token per install, reacting when those tokens rotate or expire, and retrying failed sends. That is a delivery business, and it sits outside what Supabase runs.

What Supabase does give you is the two ingredients push needs: a database that can detect the event, and Edge Functions that can call an external service. The wiring between them is yours.

Why Realtime Is Not Push Notifications

This is the single most common confusion, so it is worth being precise.

Supabase Realtime streams database changes to a connected client over a websocket. Postgres Changes, Broadcast, and Presence all work this way. It is excellent for live UI: a chat message appearing instantly, a cursor moving, an order status updating on screen.

A push notification is delivered by the operating system, through APNs on iOS or FCM on Android. It arrives on the lock screen. It works when your app is backgrounded, closed, or the phone has been in a pocket for six hours.

The distinction that matters:

If your user needs to know something while they are not looking at your app, Realtime cannot do it. That is the entire point of push, and it is why “just use Realtime” is not an answer.

What the Official Supabase Docs Say

Supabase does publish guides on push notifications, which is why searches for “supabase push notifications official docs” turn up results. They are worth reading, and it is worth being clear about what they are.

Those guides show you how to build push yourself. The recipe is roughly:

1. Create a table to store device tokens, and register tokens from your app.
2. Add a Postgres trigger on the table whose changes should notify someone.
3. Have the trigger call an Edge Function, usually through pg_net or a database webhook.
4. In the Edge Function, work out who should receive the notification.
5. Call FCM (or Expo’s push service) with your own credentials and handle failures.

The documentation is accurate and the approach works. But it is a tutorial for assembling a pipeline, not a feature you switch on. You own every piece of it afterwards, including step 4 and step 5 for every new notification type you add.

The Three Ways to Add Push to a Supabase App

1. Build it yourself

Follow the official recipe. An Edge Function, a trigger, your FCM and APNs credentials, and your own recipient logic.

Good when: you want no third party in the delivery path, you have one or two notification types, and the recipient logic belongs in your own migrations.

The cost: it is not the first notification that hurts, it is the tenth. Each new type means new SQL, a new recipient query, new Edge Function logic, and a deploy. Token cleanup, retries, and per-platform payload differences are yours to maintain.

2. A general-purpose push service

OneSignal, Firebase Cloud Messaging directly, Airship and similar. These are mature products with strong tooling for marketing and campaign sends.

The gap with Supabase: they do not know about your database. You still sync your users into their system and keep that sync correct, and firing a notification from a database event still means writing the Edge Function that calls their API. You have replaced the delivery layer, not the wiring.

3. A notification layer built for Supabase

A service that connects to your Supabase project directly, sends notifications when your data changes, and works out who should receive them from the tables you already have. Entrig is one of these, and there is a fuller explanation of how it works below.

Good when: you are on Supabase, you add notification types regularly, and you would rather configure recipients than hand-write a recipient query per notification.

The trade-off: a third party sits in your delivery path, and your notification logic lives in their dashboard rather than in your own migrations.

Quick Comparison

Narrowed to the question at hand: sending a push notification from a Supabase app when something happens in the database.

Two things this table is not hiding. FCM is the Android delivery service underneath all four columns, so that column means using it directly with nothing on top, rather than a separate universe. And every option needs you to create your own Firebase service account and APNs key. Nobody removes that step.

How to choose. If you want no third party touching delivery, build it. If your main need is marketing campaigns, segments, and A/B testing, OneSignal is genuinely better at that than anything here, including us. If what you want is for your database to notify the right people when something happens, and you would rather not maintain that plumbing, that is the case for a layer built for Supabase.

What Is Entrig?

Entrig is a notification layer for Supabase. You connect your Supabase project once, and from then on, when something happens in your database, the right people get notified.

A notification is three answers, filled in on a dashboard rather than written as code:

• When it sends: which of your tables to watch, and whether to send when something is added, changed, or removed
• Who it goes to: worked out from the tables you already have, whether that is one particular person, everyone in a group, or all of your users
• What it says: a title and a message, with {{placeholders}} filled in from whatever changed

Save it and it is live. There is no backend code of your own to write, deploy, or maintain. In your app, a few lines from the SDK connect each device to a user when they sign in.

Why it matters

The problem with the do-it-yourself path is not the first notification. It is the tenth. Each new type means new SQL, a new recipient query, new Edge Function logic, and a deploy. Recipient resolution in particular gets rewritten every time, because “notify the person this task was assigned to” and “notify everyone in this group chat” are different queries with nothing shared between them.

Entrig turns that recurring engineering work into configuration. The recipient patterns are built in, so adding your tenth notification costs about as much as adding your first.

Channels

The same setup covers more than push:

• Push notifications to iOS and Android, through APNs and FCM
• Transactional email triggered by the same database events, if you would rather send a receipt or a digest than a push
• Auth emails, taking over the signup confirmations, magic links, and password recovery messages so they come from your domain with your branding

Connect a project and you can have a real notification working end to end before you decide anything.

What You Still Do, Whichever Path You Pick

No option removes the platform requirements. On all three you still:

• Create a Firebase project and generate a service account JSON for Android
• Get an APNs authentication key from an Apple Developer account for native iOS delivery
• Enable push capability and background modes in your iOS project
• Request notification permission from the user and handle taps and deeplinks
• Keep a user ID in your database that matches the ID you register devices against

Anyone telling you push is “zero setup” is skipping these. They take an afternoon the first time.

The Short Version

• Supabase has no built-in push notification service, and none is available in the dashboard.
• Realtime is not push. It needs your app open and connected.
• The official docs show you how to build push yourself with a trigger and an Edge Function. That is a recipe, not a feature.
• Your options are to build it, use a general-purpose service and wire it up, or use a layer built for Supabase that sends notifications from your database changes for you.
• Whichever you choose, the FCM and APNs credentials are still yours to create.

For the full build-it-yourself walkthrough and the managed alternative side by side, see Push Notifications for Supabase without Edge Functions. For a specific stack, jump to the guide for Flutter, React Native, Expo, Capacitor, iOS, or Android.