Hatchet – Eine auf Postgres basierende Plattform zur Orchestrierung von Jobs

• Open-Source-Plattform für die Verarbeitung umfangreicher Hintergrundjobs auf Basis von Postgres
• Verteilte Job-Queue (Distributed Task Queue) und Workflow-Orchestrierungsplattform
• Unterstützt komplexe Job-Workflows, Fehlerbehebung, Scheduling, ereignisbasierte Trigger und Echtzeit-Monitoring
• SDKs für Python, Go und TypeScript verfügbar
• MIT-Lizenz, als Self-Hosting- und Cloud-Version verfügbar

Zusammenfassung der wichtigsten Funktionen

• Queue-Management

  • Robustes Queue-System auf Postgres-Basis
    • Schlüsselbasiertes Queueing (für faire Job-Verteilung)
    • Rate Limiting
    • Sticky Assignment und Worker Affinity
  • Automatische Verarbeitung von Job-Verteilung, Wiederholungen und Fehlerbenachrichtigungen
  • Beispiele für Python / TypeScript / Go verfügbar

• Job-Orchestrierung

  • Workflow-Aufbau auf DAG-Basis
    • Bedingte Ausführung (z. B. sleep, ereignisbasierte Trigger, bedingte Ausführung basierend auf Ausgabewerten übergeordneter Jobs usw.)
    • Kann komplexe Verzweigungslogik verarbeiten
  • Definition von Abhängigkeiten zwischen Jobs, parallele Ausführung mehrerer Jobs
  • Unterstützt das Speichern und Wiederherstellen von Zwischenergebnissen mit Durable Tasks
    • Dauerhafte Funktionsausführung: Bei Fehlern wird der Zwischenzustand zwischengespeichert und durch erneute Ausführung wiederhergestellt
    • Unterstützt auch Durable Sleep und Durable Events

• Ablaufsteuerung (Flow Control)

  • Nebenläufigkeitsbegrenzung pro Nutzer
  • Globales und dynamisches Rate Limiting
  • Sicherstellung der Systemstabilität durch strategische Job-Verteilung

• Job-Scheduling

  • Unterstützt Cron-Jobs, geplante Ausführung und durable sleep
  • Beispiele: tägliche Ausführung um Mitternacht, Ausführung zu einem bestimmten Zeitpunkt, Warten bis zu einer festgelegten Zeit usw.

• Job-Routing

  • Sticky Assignment: Fixierung von Jobs auf denselben Worker
  • Worker Affinity: Anwendung einer Logik zur Auswahl des optimalen Workers

• Ereignisbasierte Trigger

  • Jobs können nach Empfang externer Ereignisse ausgeführt werden
  • Event-/Sleep-Bedingungen können kombiniert werden

• Web-UI in Echtzeit

  • Echtzeit-Dashboard und Monitoring
  • Anzeige von Job-Logs, Konfiguration von Benachrichtigungen (Slack/E-Mail)

Wann ist Hatchet eine gute Wahl?

• ✅ Wenn ein DAG-basierter Workflow-Aufbau erforderlich ist
• ✅ Wenn Wiederholungen bei Job-Fehlern und Zustandsbewahrung wichtig sind
• ✅ Für die verteilte Verarbeitung von Jobs in Anwendungen mit vielen Nutzern
• ❌ Wenn nur eine einfache Queue mit schneller Einrichtung benötigt wird (Celery/BullMQ etc. empfohlen)
• ❌ Wenn die Integration mit verschiedenen Daten-Connectors wichtig ist (Airflow/Prefect etc. empfohlen)

Vergleich: Hatchet vs. andere Lösungen

• Hatchet vs. Temporal

  • Hatchet unterstützt Queue + DAG + Durable Execution zugleich
  • Temporal ist für Durable Execution optimiert
  • Hatchet lässt sich einfach selbst hosten (nur Postgres erforderlich)

• Hatchet vs. BullMQ / Celery

  • Hatchet bietet Speicherung der Job-Historie + UI-Visualisierung + integrierte Orchestrierung
  • BullMQ/Celery sind leichtgewichtige Queue-Bibliotheken, bieten aber wenig Monitoring-Funktionen

• Hatchet vs. Airflow / Prefect

  • Hatchet bietet hohe Ausführungsgeschwindigkeit, geringe Latenz, eigenes Worker-Management
  • Airflow/Prefect sind stärker auf Datenpipelines fokussiert und bei integrierten Connectors im Vorteil

Zusammenfassung

• Hatchet ist eine moderne Plattform für verteilte Job-Verarbeitung, die nur mit Postgres arbeitet
• Ein langlebiges, beobachtbares und komponierbares Job-System lässt sich mit einem einzigen Tool umsetzen
• Unterstützt sowohl Cloud als auch Self-Hosting und lässt sich leicht mit Python/Go/TypeScript integrieren

[halfenif]

Ich habe es zwei Stunden lang getestet und danach diesen Kommentar geschrieben.

• Da ich gerade eine MQ aufbaue, habe ich es getestet, weil ich dachte, es könnte etwas Neues auf Postgres-Basis sein, war dann aber etwas enttäuscht, als ich sah, dass RabbitMQ benötigt wird.
• Da es nicht aus einer k8s-Perspektive gedacht ist, habe ich die docker-compose.yaml auf podman (+Arch) ausgeführt.
• Da ich Postgres separat nutzen wollte, musste ich noch etwas mehr konfigurieren, habe dann aber beim Fehler SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context abgebrochen.
• Wenn zwischendurch etwas schiefging, musste ich die Postgres-Datenbank droppen und neu anfangen.
• Jedes Mal musste ein API Key neu erstellt werden; da der Key in der Web-Oberfläche nicht vollständig angezeigt wurde, musste ich ihn mit den Entwicklertools extrahieren.

[GN⁺]

Hacker-News-Kommentare

• Ich frage mich, worin sich das im Vergleich zu anderen pg-basierten Python-Job-Runnern wie Procrastinate oder Chancy unterscheidet.

• Sehr interessant.

  • Als gesagt wurde, dass FOR UPDATE SKIP LOCKED nicht auf 25k Abfragen/Sekunde skaliert, frage ich mich, an welchem Punkt die Grenze erreicht wurde.
  • Ich frage mich auch, wie es mit gepufferten Lese- und Schreibvorgängen aussieht und mit der Umstellung aller großen Tabellen auf ID-Spalten.
  • Ich frage mich, ob diese Punkte Teil der Lösung waren, um FOR UPDATE SKIP LOCKED passend zum Bedarf zu skalieren.

• Ich frage mich, ob Queue-Arbeit (Jobs in die Queue legen und als abgeschlossen markieren) in derselben Transaktion wie meine Business-Logik passiert.

  • Ich halte das für eine Schlüsselfunktion datenbankbasierter Queues.
  • Das vereinfacht die Logik für Retries.
  • Beim Ausführen von Jobs kann dasselbe Problem ebenfalls auftreten.
  • Ab diesem Punkt ist es möglicherweise besser, einfach SQS zu verwenden.

• Ich entwerfe gerade eine event-/workflowbasierte Anwendung, und diese Lösung wirkt sehr vielversprechend.

  • Ich habe auch Temporal in Betracht gezogen, hatte aber nicht das Gefühl, dass es perfekt passt.
  • Die Open-Source-Lizenz gibt mir Vertrauen bei der Anwendungsarchitektur.
  • Ich habe nach Bedingungen wie CEL gesucht.

• Dank der sechs Verbesserungen an der Hatchet-Architektur wurde die Performance in jeder Hinsicht gesteigert.

  • bereichsbasierte Partitionierung der Time-Series-Tabellen
  • hashbasierte Partitionierung der Job-Events
  • Trennung von Monitoring-Tabellen und Queues
  • gepufferte Lese- und Schreibvorgänge
  • Umstellung aller großen Tabellen auf ID-Spalten
  • intensiver Einsatz von Postgres-Triggern
  • Wenn man das Handbuch liest, kann man erstaunliche Dinge tun.

• Das README scheint davon auszugehen, dass mehr Nutzer den Dark Mode verwenden.

  • Das Logo ist weiß und ohne Dark Mode nicht sichtbar.
  • Es wäre interessant, dazu die GitHub-Statistiken zu sehen.

• Bei der Nutzung von Postgres als Message Queue bin ich auf Probleme mit großen Payloads (50 MB oder mehr) gestoßen.

  • Die Lösung waren unlogged tables und regelmäßiges vollständiges Vacuuming.
  • Ich bin kein Postgres-Experte, frage mich aber, ob dieses Problem gelöst wurde.

• Ich gebe Feedback, nachdem ich die Dokumentation 15 Minuten lang durchgesehen habe.

  • Light Mode, Open Source, Logging und die DX-Oberfläche gefallen mir.
  • Es wäre gut, das Hello-World-Beispiel durch ein reales Szenario zu ersetzen.
  • Der Code für Workflows mit mehreren Schritten ist nicht intuitiv.
  • Man muss sich an die Denkweise, Muster und Begriffe von Hatchet gewöhnen.
  • Es scheint an Aufwand zu fehlen, es für Kunden einfach zu machen.
  • Der Engineering-Post ist sinnvoll, aber Kunden interessieren sich nicht für Cloud-Infrastruktur.
  • Da es im Workflow-Markt viele Optionen gibt, besteht eine hohe Wahrscheinlichkeit, dass sie am Ende noch einmal umschreiben oder pivotieren.
  • Sie sollten die Automatisierungsreise stärker fokussieren und es Menschen leicht machen, etwas zu übernehmen und zu konfigurieren.
  • Es ist schwierig, Workflows als JSON zu serialisieren.
  • Hatchet-Workflows sollten sich leicht in andere Unternehmen mitnehmen lassen.

• Glückwunsch zum v1-Launch.

  • Ich nutze Hatchet seit fast einem Jahr und habe es vor sechs Monaten in Produktion ausgerollt.
  • Der Open-Source-Support und der schnelle Einstieg sind großartig.
  • Die in das System gesteckte Engineering-Arbeit ist deutlich sichtbar.

• Der erste Eindruck ist gut, Glückwunsch zum Launch.

  • Ich habe ein paar Fragen.
  • Ich frage mich, ob permanente Jobs unterstützt werden.
  • Ich frage mich, wo Job-Eingaben und -Ausgaben gespeichert werden.
  • Ich frage mich, ob sich auf Basis der Größe der PostgreSQL-Instanz und der I/O-Metriken abschätzen lässt, wie viele Jobs pro Sekunde das System verarbeiten kann.
  • Ich evaluiere verschiedene Tools und möchte verstehen, wie sich Hatchet anfühlt.
  • Ich suche nach einem Tool, mit dem man mit minimalem Boilerplate arbeiten kann.