Supabase sendet nicht automatisch Push-Benachrichtigungen, wenn etwas in deiner Datenbank passiert. Es gibt kein supabase.notifications.send(). Dafür brauchst du eine Pipeline aus Postgres-Trigger, Edge Function, FCM- und APNs-Zugangsdaten, Geräte-Tokens und Logik für die Empfänger.
Dieser Weg funktioniert und ist gut dokumentiert. Hier erfährst du, was er beinhaltet, und welche verwaltete Alternative es gibt. Für Flutter gibt es die Flutter-Anleitung; englische Anleitungen sind außerdem für React Native, Expo, Capacitor, iOS und Android verfügbar.
Was für Push erforderlich ist
Jeder Push benötigt vier Teile: einen Geräte-Token, einen Speicherort dafür, einen Trigger für den Versandzeitpunkt und einen Zustelldienst, der das Gerät erreicht — FCM auf Android und APNs auf iOS. Dieser Beitrag verbindet diese Teile mit Supabase.
Der Eigenbau-Weg
Ohne Tool bedeutet schon ein Benachrichtigungstyp in einer Supabase-App:
- Geräte-Tokens speichern und sie beim An- und Abmelden registrieren bzw. entfernen.
- Einen Postgres-Trigger schreiben — etwa
AFTER INSERToderAFTER UPDATE— auf der betreffenden Tabelle. - Aus dem Trigger eine Edge Function aufrufen, meist über
pg_netoder einen Datenbank-Webhook, da Postgres FCM und APNs nicht direkt aufrufen kann. - Empfänger in der Edge Function bestimmen: ein Nutzer, viele Nutzer über einen Join oder alle Nutzer. SQL- oder JS-Logik ist pro Benachrichtigung verschieden.
- FCM und APNs aufrufen, Payloads formatieren sowie Fehler, abgelaufene Tokens und Wiederholungen behandeln.
- Schritte 2 bis 5 wiederholen — für jeden neuen Typ und jede Plattform.
Die einzelnen Aufgaben sind nicht kompliziert. Der Wartungsaufwand entsteht durch die Summe aus neuer Edge Function und neuer Empfängerabfrage für jede Benachrichtigung. Dafür liegt alles in deiner eigenen Infrastruktur und deinen Migrationen.
Der verwaltete Weg
Entrig ersetzt die Schritte 2 bis 5 durch Konfiguration. Eine Benachrichtigung hat drei Bestandteile:
- Trigger: Tabelle und Ereignis (
INSERT,UPDATE,DELETE) mit optionaler Bedingung. - Users: Empfänger über Direct (Fremdschlüssel zu einem Nutzer), Indirect via Join Table (Verteilung durch Join-Tabelle) oder Broadcast (alle Nutzer, optional gefiltert).
- Message: Titel, Text und Payload-Felder mit
{{placeholders}}aus der auslösenden Zeile.
Beim Speichern erzeugt und installiert Entrig den Postgres-Trigger und die Funktion im Supabase-Projekt. Eine eigene Edge Function musst du weder schreiben noch deployen. Der Client-SDK wird mit einem API-Schlüssel initialisiert und registriert Geräte zur Nutzer-ID; die Zustellung an FCM und APNs übernimmt Entrig.
Was trotzdem nötig bleibt
Ein verwalteter Dienst ersetzt keine Plattform-Anforderungen. In beiden Varianten musst du:
- ein Firebase-Projekt und das Service-Account-JSON für Android erstellen,
- einen APNs-Authentifizierungsschlüssel für natives iOS beziehen,
- Push-Capability und Background Modes im iOS-Projekt aktivieren,
- die Berechtigung anfordern und Taps sowie Deeplinks behandeln,
- eine Datenbank-Nutzer-ID führen, die der registrierten Geräte-ID entspricht.
Eigenbau vs. Entrig
| Eigenbau | Entrig | |
|---|---|---|
| Neuer Benachrichtigungstyp | Neues SQL, Empfängerabfrage, Edge-Function-Logik, Deployment | Im Dashboard konfiguriert und beim Speichern aktiv |
| Trigger-Installation | Von dir geschrieben und migriert | Beim Speichern generiert und installiert |
| Backend | Eigene Function bzw. Server | Keines von dir; Entrig betreibt die Zustellung |
| Geräte-Tokens | Speichern, erneuern und bereinigen | SDK registriert sie; abgelehnte Tokens werden ungültig |
| Wiederholungen | FCM/APNs-Logik selbst schreiben | Temporäre Fehler werden automatisch wiederholt |
Anleitungen nach Plattform
Alle Anleitungen bauen denselben Gruppenchat und dieselben drei Benachrichtigungen: neuer Teilnehmer, neue Nachricht und neue Gruppe.