Kafka ist schnell — ich werde Postgres verwenden

• Benchmarks zur Publish/Subscribe-(Pub/Sub-)- und Queue-Leistung von Postgres zeigen, dass ein einzelnes Datenbanksystem möglicherweise auch ein Messaging-System ersetzen kann
• Auf einem einzelnen 4-vCPU-Knoten wurden 5.036 Schreibvorgänge/s und 25.183 Lesevorgänge/s erreicht; auch in einer replizierten 3-Knoten-Umgebung blieb der Durchsatz ähnlich, bei einer Ende-zu-Ende-Latenz von 186 ms (p99)
• Auf einem großen 96-vCPU-Knoten wurden 238 MiB/s Schreiben und 1,16 GiB/s Lesen erreicht; die CPU-Auslastung blieb unter 10 %, was auf deutliche Leistungsreserven hinweist
• Auch im Queue-Test waren auf einem einzelnen Knoten 2.885 Vorgänge/s möglich, in der replizierten Umgebung 2.397 Vorgänge/s — genug Leistung für die meisten Unternehmen
• Statt eines komplexen verteilten Systems wird gezeigt, dass eine einzelne Postgres-Infrastruktur Workloads im Bereich mehrerer MB/s verarbeiten kann; betont wird der pragmatische Ansatz: „Verwende einfache Technik, bis sie nicht mehr ausreicht“

---

Zwei Lager bei der Technologiewahl

• Die Tech-Branche teilt sich in ein Buzzword-orientiertes Lager und ein vom gesunden Menschenverstand geleitetes Lager
  • Ersteres fühlt sich von Marketingbegriffen wie „Echtzeit“, „unendliche Skalierung“ oder „AI-basiert“ angezogen
  • Letzteres legt Wert auf Einfachheit und Pragmatismus und vermeidet unnötige Komplexität
• Zwei aktuelle Strömungen stärken zuletzt die zweite Sichtweise: Small Data und die Postgres-Renaissance
  • Datenmengen werden kleiner, Hardware wird leistungsfähiger
  • Postgres kann als einzelnes System viele spezialisierte Lösungen ersetzen (jsonb, pgvector, tsvector usw.)

Überblick über die Benchmarks

• Ziel: messen, wie weit sich Postgres bei Pub/Sub-Messaging und Queue-Verarbeitung skalieren lässt
• Testumgebung: AWS EC2 c7i.xlarge (4 vCPU) und c7i.24xlarge (96 vCPU)
• Vergleich von drei Konfigurationen
  • Einzelner Knoten
  • Replizierter 3-Knoten-Cluster
  • Großer Einzelknoten

Ergebnisse der Pub/Sub-Benchmarks

• 4-vCPU-Einzelknoten
  • Schreiben 4,8 MiB/s (5.036 msg/s), Lesen 24,6 MiB/s (25.183 msg/s), Latenz 60 ms (p99)
  • CPU-Auslastung 60 %, Festplattenschreiben 46 MiB/s
• 4-vCPU-Replikation mit 3 Knoten
  • Schreiben 4,9 MiB/s, Lesen 24,5 MiB/s, Latenz 186 ms (p99)
  • Durchsatz bleibt erhalten, jährliche Kosten etwa 11.514 US-Dollar
• 96-vCPU-Einzelknoten
  • Schreiben 238 MiB/s (243k msg/s), Lesen 1,16 GiB/s (1,2M msg/s), Latenz 853 ms (p99)
  • CPU-Auslastung unter 10 %, Flaschenhals ist die Schreibgeschwindigkeit pro Partition
• Fazit: Bei kleinen bis mittleren Workloads auf einem Niveau, das mit Kafka konkurrieren kann; selbst mit einfacher Struktur sind mehrere zehn MB/s möglich

Ergebnisse der Queue-Benchmarks

• Einfache Queue-Implementierung auf Basis von SELECT FOR UPDATE SKIP LOCKED
• 4-vCPU-Einzelknoten
  • 2,81 MiB/s (2.885 msg/s), Latenz 17,7 ms (p99), CPU 60 %
• 4-vCPU-Replikation mit 3 Knoten
  • 2,34 MiB/s (2.397 msg/s), Latenz 920 ms (p99), CPU 60 %
• 96-vCPU-Einzelknoten
  • 19,7 MiB/s (20.144 msg/s), Latenz 930 ms (p99), CPU 40–60 %
• Selbst ein einzelner Knoten kann die Anforderungen an den Queue-Durchsatz der meisten Unternehmen erfüllen

Wann Postgres sinnvoll ist

• In den meisten Fällen ist Postgres als Standardwahl vernünftig
  • Nachrichten lassen sich per SQL debuggen, ändern und verknüpfen
  • Im Vergleich zu Kafka ist der Betrieb einfacher und die Wartung leichter
• Kafka ist für Höchstleistung optimiert, für kleinere Workloads aber oft überdimensioniert
• Zitiert wird Donald Knuths Warnung: „Vorzeitige Optimierung ist die Wurzel allen Übels“
  • Bis in den Bereich mehrerer MB/s reicht Postgres völlig aus

Ansatz der minimal lauffähigen Infrastruktur (MVI)

• Minimum Viable Infrastructure: Aufbau eines minimalen Systems mit Technologien, die der Organisation bereits vertraut sind
  • Postgres ist weit verbreitet und entsprechendes Personal leicht zu finden
  • Je weniger Komponenten, desto geringer die Last durch Ausfälle und Betrieb
• Die Einführung unnötiger Technologien erzeugt organisatorischen Overhead
  • Lernen, Monitoring, Deployment und Betrieb werden teurer

Diskussion über Skalierbarkeit

• Postgres lässt sich in der Praxis tatsächlich skalieren
  • OpenAI verwendet weiterhin Postgres auf Basis einer einzelnen Schreibinstanz
  • Stabiler Betrieb auch im Maßstab von Hunderten Millionen Nutzern
• Die meisten Unternehmen wachsen moderat und haben mehrere Jahre Zeit, bevor ein Technologiewechsel nötig wird
• „Für den Fall eines viralen Erfolgs entwerfen“ ist übertriebenes Overengineering
  • Es sei, „als würde man einen Marshall-Verstärker kaufen, um als Vorband von Coldplay aufzutreten“

Fazit

• „Verwende Postgres, bis es wirklich an seine Grenzen stößt“
  • Auch einfache Technik kann ausreichend hohe Leistung liefern
  • Die Einführung unnötig komplexer verteilter Systeme ist ineffizient
  • Zusammen mit moderner Hardware ist Postgres eine pragmatische Wahl, die die meisten Workloads bewältigen kann

[GN⁺]

Hacker-News-Kommentare

• Das Pareto-Prinzip auf jede Situation anzuwenden, ist eine Fehlinterpretation
  Zu behaupten, Postgres decke 80 % der Use Cases mit 20 % des Aufwands im Vergleich zu Kafka ab, ist eine unbelegte Behauptung
  Das Pareto-Prinzip ist nur dort sinnvoll, wo eine Potenzgesetzverteilung auftritt
  Man kann einfach sagen, dass Postgres ausreichend viele Use Cases abdeckt und ein stabiles, bewährtes Tool ist

  • Es gibt aber auch die Meinung, dass schon die Abbildung von Use Cases auf Features selbst einer Potenzgesetzverteilung folgen könnte

• Aus meiner Erfahrung, von kleinen Größenordnungen (ein paar hundert Events pro Stunde) bis hin zu großen Maßstäben (Billionen Events pro Stunde), sollte man zuerst prüfen, ob man überhaupt wirklich eine Queue braucht

  1. Vielleicht reicht simples DB-Polling schon aus
  2. Wenn ein einzelner Node es tragen kann, lässt sich das mit Serverless oder einem einzelnen Prozess abwickeln
  3. Wenn man nicht zwingend eine verteilte Queue braucht, reichen oft auch Load Balancing + REST API + asynchrone Retries
  4. Wenn man wirklich eine verteilte Queue braucht, ist meiner Meinung nach eine dedizierte Lösung wie Kafka die bessere Wahl
  • Es sollte klar gesagt werden, dass Kafka eigentlich keine Queue, sondern ein verteiltes Log-System ist. Es wird oft fälschlich als MQ-Ersatz verstanden
  • In Startups neigen Engineers oft dazu, komplexe Technologien nicht für das aktuelle Projekt, sondern mit Blick auf den nächsten Karriereschritt zu wählen
  • Wenn man die Code-Struktur so entwirft, dass sowohl PostgreSQL-basierte als auch Kafka-basierte Queues unterstützt werden, wird ein späterer Wechsel leichter
  • PostgreSQL wird bei hoher Schreiblast leicht zum Bottleneck. UPDATE-Streams sind besonders schmerzhaft
  • Als Java-Entwickler brauchte ich immer eine Queue. DB-Polling war in Umgebungen mit mehreren Consumern/Produzenten ein ständiger Kopfschmerz. Kafkas Consumer Groups und Partitions haben beim Zustandsmanagement sehr geholfen

• Der Ansatz, Postgres für alles zu benutzen, ist riskant
  Locks und Serialisierungslevel sind nicht intuitiv und können zu Performance-Bottlenecks führen
  Ich nutze Postgres seit Jahrzehnten, aber man sollte Systeme nicht auf blindem Glauben aufbauen

  • Bei Traffic-Spitzen ist die Grenze der vertikalen Skalierung das Problem. Kafka fängt Traffic-Bursts ab, während Postgres leicht überlastet wird
  • Es wäre gut, wenn Postgres eine nachhaltige Queue-Struktur bekäme, aber Skalierung über Redis-Niveau hinaus ist schwierig, und LISTEN/NOTIFY skaliert nicht (relevanter Link)
  • Eigentlich muss man bei jedem Datenspeicher das Nebenläufigkeitsmodell verstehen. Selbst zwischen relationalen DBs gibt es große Unterschiede
  • Postgres skaliert zwar nicht unbegrenzt, kann aber mit Batch-Verarbeitung und Operationen auf Ebene einzelner Zeilen ziemlich viele Daten verarbeiten
  • Ich persönlich starte zuerst mit Postgres und wechsle erst auf ein anderes System, wenn tatsächlich ein Bottleneck entsteht

• Ich halte einen SQL-basierten Ansatz mit einer Event-Log-Tabelle für effektiv
  Ein Nachteil ist allerdings der Mangel an Client-seitigen Tools. Kafka hat dort durch sein reiches Bibliotheks-Ökosystem einen Vorteil
  Unser Unternehmen hat die Event-Übertragung zwischen Services auf SQL-Basis standardisiert (feedapi-spec)
  Zwar nicht so ausgereift wie Kafka, aber mit einem gemeinsamen Library-Stack, der mehrere Storage-Engines unterstützt, könnte sich daraus etwas entwickeln

  • Durch Fortschritte bei LLM-basierten Code-Generierungs-Tools ist es leichter geworden, solche Client-Lücken zu schließen
  • Aus Sicht von jemandem, der Kafka nicht mag, wirkt dieser Ansatz deutlich attraktiver

• Heutzutage fühlen sich viele Leute zu sehr von neuen Technologien angezogen
  Postgres ist großartig, aber man sollte das passende Tool für das Problem einsetzen
  Postgres wurde nicht für Pub-Sub entworfen, Kafka dagegen genau dafür
  Man sollte den Trend vermeiden, dass jedes Produkt „alles auf einmal“ machen will. Meiner Meinung nach sind Tools besser, die eine Sache richtig gut können

• Eine monoton steigende Offset-Nummer zu implementieren, ist ein kniffliges Problem
  Eine einfache Sequenz verursacht Probleme, weil Transaktionsreihenfolge und Commit-Zeitpunkt auseinanderlaufen können

  • Eine Möglichkeit ist eine dedizierte Zählertabelle, bei der innerhalb derselben Transaktion per Sperre die Reihenfolge garantiert wird (Referenzlink)
  • Mit Lamport Clock oder Vector Clock lässt sich die Reihenfolge auch in verteilten Umgebungen sicherstellen (Lamport timestamp, Vector clock)
  • Statt eine absolute Reihenfolge zu erzwingen, ist es oft realistischer, Nummern batchweise zu vergeben oder die Reihenfolge nach dem Commit durch einen separaten Prozess zuzuweisen
  • Man kann auch mit SELECT FOR UPDATE SKIP LOCKED doppelte Verarbeitung vermeiden

• Ich frage mich, ob überhaupt ein echtes Kafka-Benchmarking gemacht wurde
  Die Ergebnisse aus einer 96-vCPU-Umgebung wären auch mit einer Kafka-Konfiguration auf 4 vCPU erreichbar
  Die Postgres-Performance ist ungewöhnlich langsam
  Wenn man Kafka nicht braucht, sollte man es nicht verwenden, aber mit 5k msg/s auf Postgres zu prahlen, ist nicht besonders sinnvoll

  • Redpanda (eine Kafka-kompatible Implementierung) verarbeitet 250.000 Nachrichten pro Sekunde selbst auf einem Laptop (Videolink)
  • In einer 288-vCPU-Umgebung darunter zu bleiben, ist Verschwendung
  • Wenn man Postgres nur verwendet, weil es „eh schon da ist“, ist das nachvollziehbar, aber eine Validierung vor dem Hinzufügen neuer Infrastruktur ist trotzdem nötig
  • Kafka erreicht schon mit wenig Hardware die Grenze der Netzwerkbandbreite
  • Auf AWS eine einzelne 24xlarge-Instanz zu betreiben, ist ineffizient; für diese Kosten könnte man einen großen Kafka-Cluster betreiben

• Es gibt zwei Extreme: „Leute, die Buzzwords hinterherlaufen“ und „Leute, die nur an dem festhalten, was sie bereits kennen“
  Realistische Engineers treffen irgendwo dazwischen pragmatische Entscheidungen

  • Ich gehöre zu einer dritten Gruppe: der Typ Mensch, der denkt: „Alles, was wir jetzt haben, ist nicht besonders gut, und das Neue wird am Ende wahrscheinlich auch nicht besonders gut sein“
  • Am Ende ist entscheidend, Probleme vernünftig zu betrachten und die optimale Lösung zu finden
  • Zum Beispiel kann man versuchen, Elasticsearch durch Postgres zu ersetzen, aber bei der Qualität der Suchfunktionen ist ES deutlich überlegen

• Die Kernfunktion von Kafka ist die Offset-Steuerung pro Consumer
  In Umgebungen, in denen mehrere Teams dasselbe Topic lesen, ist das unverzichtbar
  Dass man Offsets vor- und zurücksetzen kann, war mehrfach ein echter Rettungsanker
  Ich frage mich, ob eine Postgres-Queue so etwas unterstützt

  • Es gibt auch die Meinung, dass jeder Consumer seine Offsets einfach selbst verwalten könnte
  • In den meisten Fällen braucht man Kafkas komplexes Offset-Management aber nicht, wenn kein hoher Durchsatz erforderlich ist
  • Letztlich ist es eine Frage des Gleichgewichts zwischen Geschwindigkeit der Business-Anforderungen und operativer Komplexität

• Die Gegenüberstellung „Lager der Buzzword-Jäger vs. Lager des gesunden Menschenverstands“ ist schon an sich falsch
  Kafka mit Postgres nachzubauen, ist kein gesunder Menschenverstand
  Wenn man wirklich Funktionen auf Kafka-Niveau braucht, sollte man einfach Kafka verwenden

  • Tatsächlich wurde nicht Kafka als Ganzes nachgebaut, sondern nur zwei einfache Pub-Sub-Queries