Stell dir vor, du sitzt in einem grossen Büro und wartest auf eine wichtige Nachricht. Du könntest alle fünf Minuten bei der Zentrale anrufen und fragen: „Ist was Neues da?“ Das wäre ineffizient und würde nerven. Besser wäre ein System, bei dem die Zentrale dich sofort benachrichtigt. Das leistet Postgres mit LISTEN und NOTIFY – direkt in der Datenbank.
Seit Jahren kursiert das Gerücht, dass Postgres LISTEN/NOTIFY nicht für grössere Systeme tauge. Zu viele Verbindungen, zu viel Overhead, zu langsam. Moderne PostgreSQL-Versionen haben die interne Mechanik verbessert. Mit der richtigen Architektur kannst du Tausende von gleichzeitigen Listenern betreiben, ohne dass die Datenbank überlastet wird.
LISTEN und NOTIFY sind ein eingebautes Pub/Sub-System. Ein Client abonniert mit LISTEN einen Kanal. Ein anderer Client – oder ein Trigger, eine Funktion – sendet mit NOTIFY eine Nachricht. PostgreSQL leitet diese asynchron an alle lauschenden Verbindungen weiter. Kein Polling, keine zusätzliche Middleware, nur die Datenbank.
Der Vorteil gegenüber Polling: sofortige Reaktion und geringere Datenbanklast. Statt alle paar Sekunden eine SELECT-Abfrage auszuführen, wartest du auf ein Ereignis. Das schont CPU, Netzwerk und Speicher. Besonders bei vielen Nutzern spart das Ressourcen.
Warum zweifeln viele an der Skalierbarkeit? Der Grund liegt in der Vergangenheit. Ältere Postgres-Versionen hatten Probleme mit vielen LISTEN-Verbindungen. Jede lauschende Verbindung erzeugte Overhead im Shared Memory und im WAL. NOTIFY-Nachrichten konnten nur innerhalb einer Transaktion gesendet werden und kamen erst nach Commit an. Das führte zu Verzögerungen.
Seit PostgreSQL 9.4 hat sich die Situation verbessert. Asynchrone Notifications und optimierte Queue-Strukturen steigern die Leistung. Heute lassen sich zehntausend gleichzeitige LISTEN-Verbindungen betreiben, ohne dass die Datenbank aus dem Takt gerät. Es gibt Grenzen – Shared Memory oder CPU – aber sie liegen höher als oft angenommen.
Ein oft übersehener Faktor ist die Art der Verbindungen. Bei einem Connection Pool wie PgBouncer musst du aufpassen: Viele Pooler leiten LISTEN/NOTIFY nicht korrekt weiter, weil sie Verbindungen mischen. Die Lösung: ein dedizierter Pool-Modus (z. B. Session-Pooling) oder direkte Verbindungen für Listener. Auch kannst du Notifications in einer zentralen Worker-Webanwendung bündeln und per WebSocket verteilen. Das entlastet die Datenbank und skaliert horizontal.
Die Nachrichten ersetzen keinen vollwertigen Message Broker. Sie sind maximal 8000 Bytes gross und nicht persistent. Bei einem Datenbank-Crash gehen nicht zugestellte Nachrichten verloren. Für viele Anwendungsfälle ist das akzeptabel: Cache-Invalidierung, Echtzeit-Updates für Dashboards, einfache Job-Benachrichtigungen oder das Triggern von Hintergrundarbeitern.
Ein Beispiel: Eine KI-gestützte Empfehlungsplattform. Wenn ein Benutzer neue Daten eingibt, soll sofort ein Modell neu trainiert werden. Statt jede Minute einen Cron-Job laufen zu lassen, löst du beim Einfügen einen NOTIFY aus. Der Worker, der das Modell trainiert, lauscht auf diesem Kanal und startet die Berechnung. Das spart Zeit und Rechenleistung.
Postgres ist das Rückgrat vieler KI-Systeme. Datenänderungen sofort zu kommunizieren, ist ein wichtiger Baustein für reaktive Architekturen. Machine-Learning-Pipelines, Echtzeit-Analysen und personalisierte Empfehlungen nutzen diese schlanke, datenbankintegrierte Kommunikation.
Die PostgreSQL-Dokumentation listet LISTEN/NOTIFY als produktionsreif. Viele Unternehmen setzen es erfolgreich ein. Wichtig ist, die Erwartungen richtig zu setzen: Es ist kein Ersatz für Kafka oder RabbitMQ, wenn du hohen Durchsatz, Persistenz und komplexe Routing-Logik brauchst. Für den typischen Anwendungsfall einer einzelnen Datenbank als Single Source of Truth ist es oft die einfachste und performanteste Lösung.
Ein konkretes Beispiel: Ein SaaS-Anbieter für Projektmanagement benachrichtigt mit LISTEN/NOTIFY alle Clients, wenn ein Teammitglied eine Aufgabe aktualisiert. Früher kam eine teure Polling-Lösung zum Einsatz – zehn Abfragen pro Sekunde pro Benutzer. Nach der Umstellung sank die Datenbanklast um 90 %. Die Benutzer erleben keine Verzögerung, der Betrieb läuft stabil mit mehreren tausend gleichzeitigen Verbindungen.
Beachte einige Best Practices: Verwende aussagekräftige Kanalnamen, die die Applikationslogik widerspiegeln. Halte die Nutzlast klein – besser eine ID versenden und die Daten separat laden. NOTIFY wird nur innerhalb einer Transaktion gesendet; erst nach Commit werden Benachrichtigungen ausgeliefert. Das verhindert falsche Benachrichtigungen über Rollbacks hinweg.
Ein weiterer Punkt: LISTEN und NOTIFY sind flüchtig. Verliert ein Client die Verbindung, bevor die Nachricht ankommt, ist sie weg. Für kritische Daten solltest du einen separaten, persistenten Mechanismus vorsehen. Für die meisten Echtzeit-Features ist das akzeptabel – ähnlich wie UDP: schnell, aber nicht garantiert.
PostgreSQL 17 bringt weitere Optimierungen für den Async-Notify-Pfad. Wer bisher gezögert hat, kann es jetzt ausprobieren. Es skaliert gut und vereinfacht die Architektur.
Letztlich geht es darum, die richtigen Werkzeuge zu wählen. Postgres LISTEN/NOTIFY ist eines dieser Werkzeuge, das in vielen Situationen eine elegante Lösung bietet. Es ist solide Technik, die seit Jahrzehnten gereift ist.
Quelle: dbos.dev
