Das Argument gegen Broker-Bloat
Dedizierte Message Broker wie SQS, Kafka und RabbitMQ verursachen erheblichen, oft versteckten operativen Aufwand. Sie verwalten eine separate Infrastruktur, was Kosten für die Bereitstellung, das Deployment, das Monitoring und die Skalierung unterschiedlicher Dienste verursacht. Dies erhöht die Netzwerklatenz und steigert kritisch die kognitive Belastung für Entwickler, die mehrere verteilte Systeme integrieren und debuggen müssen, wodurch unnötige Komplexität in Ihren Stack gelangt.
Ihre bestehende Postgres-Datenbank bietet eine robuste, zuverlässige Alternative und eliminiert Broker-Bloat. Basierend auf ACID-Compliance und erprobter transaktionaler Stärke bietet Postgres eine bewährte Grundlage für zuverlässiges Queuing, die Datenintegrität selbst bei Ausfällen garantiert. Sie bewältigt problemlos Millionen von Zeilen und Tausende von Anfragen pro Sekunde; ein Test mit 2 CPUs und 2 GB RAM verarbeitete beispielsweise 100.000 Nachrichten in 9 Sekunden, was einem Durchschnitt von 11.100 Nachrichten/Sekunde entspricht.
PGMQ formalisiert dieses leistungsstarke Muster als leichtgewichtige, einfache Erweiterung. Es liefert eine SQS-ähnliche API direkt innerhalb von Postgres, die das Erstellen von Queues, das Senden von Nachrichten mit optionalen Verzögerungen sowie das Konsumieren mit Visibility Timeouts (VT) für eine garantierte Exactly-once-Zustellung ermöglicht. Das bedeutet, Sie erhalten eine voll funktionsfähige Message Queue mit Client-Bibliotheken für Rust, Python und TypeScript, ohne einen einzigen neuen Dienst zu Ihrem Stack hinzuzufügen.
Von Null auf Queue in 5 Zeilen SQL
Erstellen Sie Queues mit reinem SQL. Rufen Sie pgmq.create('my_queue') auf; jede Queue wird zu ihrer eigenen Postgres-Tabelle. Senden Sie Nachrichten mit pgmq.send('my_queue', '{"job_id": 123}'). Dies bettet Nachrichten als JSON direkt in Postgres ein und vereinfacht Ihr Datenmodell.
Implementieren Sie zeitgesteuerte Zustellung mit pgmq.send(). Fügen Sie einen delay-Parameter hinzu (z. B. pgmq.send('my_queue', '{"task": "future"}', 30)). Die Nachricht gelangt in die Queue, bleibt aber für 30 Sekunden nicht konsumierbar, was eine erweiterte Job-Planung ohne externe Cron-Dienste ermöglicht.
Konsumieren Sie Nachrichten über pgmq.read('my_queue', 30, 1). Der kritische vt (Visibility Timeout)-Parameter macht gelesene Nachrichten für die angegebene Dauer (z. B. 30 Sekunden) unsichtbar. Dies stellt die Exactly-once-Zustellung sicher: Kein anderer Worker kann dieselbe Nachricht während ihres aktiven Zeitfensters verarbeiten. Wenn sie nicht innerhalb des VT verarbeitet oder gelöscht wird, erscheint sie wieder in der Queue.
Nach der Verarbeitung entfernen Sie die Nachrichten. Verwenden Sie pgmq.delete('my_queue', message_id), um eine Nachricht dauerhaft zu entfernen. Alternativ verschiebt pgmq.archive('my_queue', message_id) die Nachricht aus der aktiven Queue in eine dedizierte Archivtabelle und bietet so ein historisches Protokoll für Audits oder eine erneute Verarbeitung.
Aber skaliert es auch wirklich?
"Aber es skaliert nicht", sagen Sie. Dies ist das häufige Argument gegen Datenbanken als Queues. Postgres bewältigt jedoch problemlos Millionen von Zeilen und Tausende von Anfragen pro Sekunde. PGMQ nutzt diese inhärente Fähigkeit und verwandelt eine vermeintliche Schwäche in eine Stärke für verteilte Anwendungen.
Ein kürzlich durchgeführter Stresstest validierte die Leistung von PGMQ unter eingeschränkten Ressourcen. Forscher stellten einen Docker-Container mit nur 2 CPUs und 2 GB RAM bereit. Anschließend injizierten sie 100.000 Nachrichten in eine PGMQ-Queue. Dieses Setup spiegelt typische Live-Service-Umgebungen wider, was die Ergebnisse hochrelevant macht.
Einhundert gleichzeitige Worker verarbeiteten alle 100.000 Nachrichten in nur 9 Sekunden. Jeder Worker las, protokollierte und löschte Nachrichten in Batches. Dies entspricht einem kombinierten Durchsatz von über 11.100 Nachrichten pro Sekunde. Für eine umfassende Dokumentation und weitere Beispiele konsultieren Sie das offizielle Postgres Message Queue (PGMQ) Repository.
Eine solche Leistung entkräftet den Mythos „es skaliert nicht“ für praktisch jede reale Anwendung eindeutig. PGMQ beweist, dass Postgres als Message Queue nicht nur praktikabel, sondern auch hochperformant ist, wodurch der operative Aufwand für dedizierte Broker in den meisten Anwendungsfällen entfällt. Halten Sie Ihre Infrastruktur einfach.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Integration von PGMQ in Ihre Anwendung
Integrieren Sie PGMQ direkt in Ihren Anwendungs-Stack. Gehen Sie über reines SQL hinaus mit robusten Client-Bibliotheken für gängige Sprachen. Offizieller Support unterstützt Python- und Rust-Integrationen und bietet idiomatische Schnittstellen. Community-gesteuerte Bibliotheken erweitern PGMQ zudem auf Ruby und mehrere TypeScript-Varianten, einschließlich einer nahtlosen Erfahrung mit Prisma.
Erstellen Sie Producer mit minimalem Code. Ein Python-Producer sendet eine Nachricht mit einem einfachen send()-Aufruf, wobei der Queue-Name und das JSON-Payload angegeben werden. Dies spiegelt den pgmq.send() SQL-Befehl wider und abstrahiert die Datenbankinteraktion für Sie.
Worker konsumieren Nachrichten effizient. Verwenden Sie die read()-Funktion einer Client-Bibliothek, um einen Batch von Nachrichten abzurufen, wobei das Visibility Timeout (VT) berücksichtigt wird. Rufen Sie nach der Verarbeitung delete() oder archive() auf, um Nachrichten zu entfernen. Dies stellt exactly-once delivery sicher und verhindert eine erneute Verarbeitung. Dieses Muster bewältigt Aufgaben mit hohem Volumen.
Die Vereinheitlichung Ihrer Daten- und Messaging-Schichten innerhalb von Postgres vereinfacht Ihre Infrastruktur. Eliminieren Sie den operativen Aufwand separater Message Broker, reduzieren Sie Netzwerklatenz und kognitive Belastung. Diese Konsolidierung rationalisiert Entwicklung, Test und Deployment und führt zu einem robusteren und wartbareren System.
Häufig gestellte Fragen
Was ist PGMQ?
PGMQ (Postgres Message Queue) ist eine leichtgewichtige Erweiterung für PostgreSQL, die Message-Queue-Funktionalität direkt innerhalb der Datenbank ermöglicht und eine Alternative zu Diensten wie AWS SQS, RabbitMQ oder Kafka bietet.
Wie stellt PGMQ exactly-once delivery sicher?
PGMQ verwendet ein 'Visibility Timeout'. Wenn eine Nachricht gelesen wird, wird sie für andere Consumer für einen festgelegten Zeitraum unsichtbar. Der Consumer muss die Nachricht innerhalb dieser Zeit löschen oder archivieren. Schlägt dies fehl, erscheint die Nachricht erneut, damit ein anderer Consumer sie verarbeiten kann, was Datenverlust verhindert.
Kann PGMQ Traffic auf Produktionsebene bewältigen?
Ja. Benchmarks zeigen, dass PGMQ auf bescheidener Hardware (z. B. einem 2-CPU-Container) über 11.000 Nachrichten pro Sekunde verarbeiten kann. Dies ist für viele verteilte Anwendungen mit hohem Volumen mehr als ausreichend.
Was ist der Hauptvorteil der Verwendung von Postgres als Message Queue?
Der Hauptvorteil ist die Vereinfachung der Infrastruktur. Durch die Nutzung Ihrer bestehenden Datenbank reduzieren Sie Abhängigkeiten, senken den operativen Aufwand und vereinfachen Ihren gesamten Tech-Stack, ohne bei den meisten gängigen Anwendungsfällen Leistung einzubüßen.