Supabase doesn't send push notifications automatically when something happens in your database. There's no supabase.notifications.send() to call. If you want to send one, you have to build the pipeline: a Postgres trigger, an Edge Function, FCM and APNs credentials, device tokens to manage, and code to figure out who should receive the message.
This guide covers what it actually involves, then a managed alternative, including the parts it doesn't save you. If you're on a specific platform, jump straight to the guide: Flutter, React Native, Expo, Capacitor, iOS, or Android. Each builds the same three real notifications for a group chat app, so you can compare the setup across stacks.
What You Need to Send Push Notifications
Every push, on every platform, needs the same four pieces: a device token, a place to store it, a trigger that decides when to send, and a delivery service (FCM for Android, APNs for iOS) that actually reaches the device. See How Push Notifications Work for the token-level detail. This post is about wiring those pieces to Supabase.
The DIY Path
Without a tool, adding a single notification type to a Supabase app means:
- Store device tokens. Add a column or table for the token, and register/unregister it from the app on sign-in and sign-out.
-
Write a Postgres trigger on the table you care about (
AFTER INSERT,AFTER UPDATE, whatever fires the notification). -
Call an Edge Function from the trigger, usually with
pg_netor a database webhook, since Postgres can't call FCM or APNs directly. - Resolve the recipient inside the Edge Function. Who gets this notification? A single user, a table full of users through a join, or everyone? That logic is hand-written SQL or JS, and it's different for every notification type.
- Call FCM and APNs with the right credentials, format the payload for each platform, and handle failures (expired tokens, retries).
- Repeat steps 2 through 5 for every new notification type you add, and again for every platform you ship to.
None of this is hard in isolation. It's the accumulation, a new Edge Function and a new recipient query for every notification type, that turns into the maintenance burden. The upside is that it stays entirely yours: no third party in the delivery path, and the recipient logic lives in your own migrations.
The Managed Path
Entrig replaces steps 2 through 5 with configuration. A notification is defined by three things:
-
Trigger: the table and event (
INSERT,UPDATE,DELETE) that fires it, with an optional condition. - Users: how to find the recipient, using one of three built-in patterns: Direct (follow foreign keys to one user), Indirect via Join Table (fan out through a join table to many users), or Broadcast (everyone in your users table, optionally filtered).
-
Message: the title, body, and payload fields, written with
{{placeholders}}pulled from the row that fired the trigger.
Save it, and Entrig generates and installs the Postgres trigger and function in your Supabase project, so there's no Edge Function of your own to write or deploy. On the client, the SDK initialises with an API key and registers the device against a user ID on sign-in (and unregisters on sign-out). Delivery to FCM and APNs happens on Entrig's side.
What You Do Either Way
A managed service doesn't remove the platform requirements. Whichever path you pick, you still:
- Create a Firebase project and generate a service account JSON for Android (and for iOS too, if you route iOS through FCM).
- Get an APNs authentication key from an Apple Developer account for native iOS delivery.
- Enable the push capability and background modes in your iOS project.
- Ask the user for notification permission, and handle taps and deeplinks in your app.
- Keep a user ID in your database that matches the ID you register devices with.
DIY vs Entrig
| DIY | Entrig | |
|---|---|---|
| Adding a new notification type | New SQL, new recipient query, new Edge Function logic, a deploy | Configured in the dashboard, live on save |
| Trigger installation | Written and migrated by you | Generated and installed when you save |
| Backend to run | An Edge Function (or server) you write, deploy, and maintain | None of your own, Entrig runs the delivery path |
| Device tokens | You store them, re-register on refresh, and prune the dead ones | The SDK registers and re-registers on token refresh; Entrig marks a token invalid once FCM or APNs rejects it |
| Delivery retries | You write the retry logic against FCM/APNs | Transient push failures are retried automatically. Invalid-token errors aren't retried, the token is marked invalid instead |
| Delivery visibility | You log and query it yourself | Per-send delivery records in the dashboard |
Guides by platform
Each guide below builds the same group chat app and the same three notifications (member joins, new message, new group), so the recipient patterns transfer even if you're not on that specific stack.
Or read the full comparison at entrig.com/blog/push-notifications-supabase.
Top comments (0)