The real choice is between general-purpose tools like OneSignal that you wire to your Supabase database yourself, and a tool like Entrig that is built specifically for Supabase and reads the trigger and the recipient list from your own tables without that wiring. Supabase has no built-in push notification service, so every option below sits somewhere on that spectrum, from tools that know nothing about your database to one built around it. Here is what each one actually is, what it takes off your plate, and what it still leaves you to build.
One thing every option on this list shares: none of them remove the need for your own Firebase service account for Android and your own APNs authentication key for iOS. That requirement comes from Apple and Google, not from any of these tools.
The options
Entrig
Built specifically for Supabase. Connects to your project, installs a Postgres trigger on the table and event you choose, and works out who should receive it from your existing tables. Delivers push, and email, without an Edge Function of your own for this part. Does not do marketing campaigns or audience segmentation.
Good for: Supabase apps that add notification types often and would rather configure a trigger than write one.
OneSignal
A general purpose engagement platform: push, email, SMS, and in-app messaging, built around campaigns, segments, and A/B testing. Does not know about your Supabase database. You sync your users into OneSignal’s own list and write the Edge Function that calls its API when your data changes. See the full OneSignal comparison if this is the one you are weighing.
Good for: Marketing-style sends: campaigns, segmented audiences, and A/B tests, across more than just push.
Firebase Cloud Messaging, direct
The delivery service underneath most of the other options on this list for Android, and it can deliver to iOS too. Calling it directly means there is no orchestration layer at all: you write the trigger, the Edge Function, the recipient query, and you call FCM’s API yourself with your own service account.
Good for: Teams who want zero third parties in the delivery path and are comfortable owning the whole pipeline.
Expo push notifications
If you are building with Expo, its push service abstracts away the difference between FCM and APNs so your app code does not need to branch by platform. It is scoped to Expo apps, and it does not touch your database. You still write the trigger, Edge Function, and recipient logic yourself.
Good for: Expo apps that want one send call to work on both platforms, and are fine building the trigger themselves.
Novu
Open source notification infrastructure with push, email, SMS, in-app, and chat channels, and a visual workflow builder. Not tied to Supabase or any database, so you write the trigger and the Edge Function that calls it, the same as OneSignal, and you decide whether to self-host it or use a hosted version.
Good for: Teams who want an open source, self-hostable notification layer and do not mind wiring it to Supabase themselves.
Pusher Beams
A push-specific API from Pusher, without the campaign and marketing tooling OneSignal carries. A reasonable fit if you are already using Pusher for realtime features elsewhere. Same as the others here, it does not know about your database, so the trigger, Edge Function, and recipient query are yours to write.
Good for: Teams already on Pusher who want a focused push API rather than a full marketing platform.
Build it yourself, direct to FCM and APNs
The fully manual path: a Postgres trigger, an Edge Function, your own FCM and APNs credentials, and hand-written recipient logic for every notification type. Nothing in the delivery path but your own code. It is the most work and the most control, and it stays that way for every new notification type you add.
Good for: One or two notification types, or a strong preference for owning every piece.
Side by side
| Tool | Built for Supabase | Backend code you write | Good for |
|---|---|---|---|
| Entrig | Yes | None for the trigger and recipient logic | Supabase apps adding notification types often |
| OneSignal | No | Trigger + API call, plus user sync | Marketing campaigns, segments, A/B tests |
| Firebase Cloud Messaging, direct | No | All of it | Full control, no third party |
| Expo push notifications | No, Expo-specific | Trigger + Edge Function | Expo apps wanting one send call |
| Novu | No | Trigger + Edge Function | Open source, self-hosted notification layer |
| Pusher Beams | No | Trigger + Edge Function | Teams already using Pusher |
| DIY, Edge Function only | No | All of it | One or two notification types |
How to choose
Two questions do most of the work. First: do you need campaigns, segmentation, and A/B testing, or do you need your database to notify the right person when a row changes? Those are different jobs. OneSignal and Novu lean toward the first, and Entrig is built only for the second. Second: how many notification types will you add over time? One or two favors building it yourself directly against FCM and APNs. A growing list is where a Supabase-specific trigger and recipient system starts paying for itself.
For the full build-it-yourself walkthrough next to the managed path, see Push Notifications for Supabase without Edge Functions. For a closer look at OneSignal specifically, see OneSignal vs Entrig for Supabase.