Hatchet – plateforme d’orchestration de tâches basée sur Postgres

• Plateforme open source de traitement de tâches d’arrière-plan à grande échelle basée sur Postgres
• File de tâches distribuée (Distributed Task Queue) et plateforme d’orchestration de workflows
• Prend en charge les workflows de tâches complexes, la reprise après échec, la planification, les déclencheurs basés sur les événements et la supervision en temps réel
• SDK disponibles pour Python, Go et TypeScript
• Licence MIT, avec versions self-hosted et cloud

Résumé des principales fonctionnalités

• Gestion des files

  • Système de file durable basé sur Postgres
    • Mise en file basée sur des clés (implémente une répartition équitable des tâches)
    • Limitation de débit (Rate limiting)
    • Sticky Assignment et Worker Affinity
  • Gestion automatique de la distribution des tâches, des nouvelles tentatives et des alertes en cas d’échec
  • Exemples fournis en Python / TypeScript / Go

• Orchestration des tâches

  • Composition de workflows basée sur des DAG
    • Exécution conditionnelle (ex. : sleep, déclencheur basé sur un événement, exécution conditionnelle selon la valeur de sortie d’une tâche parente, etc.)
    • Capable de gérer une logique de branchement complexe
  • Définition des dépendances entre tâches, exécution parallèle de plusieurs tâches
  • Prise en charge de la sauvegarde et de la restauration des résultats intermédiaires via des durable tasks
    • Exécution de fonctions durables : en cas d’échec, l’état intermédiaire est mis en cache puis restauré lors de la réexécution
    • Prend aussi en charge Durable Sleep et Durable Events

• Contrôle de flux (Flow Control)

  • Limitation de concurrence par utilisateur
  • Limitation de débit (Rate Limiting) globale et dynamique
  • Stabilité du système assurée grâce à une répartition stratégique des tâches

• Planification des tâches

  • Prise en charge des tâches Cron, de l’exécution planifiée et de durable sleep
  • Ex. : exécution chaque jour à minuit, planification à une heure donnée, attente jusqu’à l’heure définie, etc.

• Routage des tâches

  • Sticky Assignment : tâche fixée au même worker
  • Worker Affinity : application d’une logique de sélection du worker optimal

• Déclencheurs basés sur les événements

  • Exécution possible des tâches après réception d’un événement externe
  • Possibilité de combiner des conditions d’événement et de sleep

• Interface Web en temps réel

  • Tableau de bord et supervision en temps réel
  • Consultation des logs de tâches, configuration des alertes (Slack/e-mail)

Quand utiliser Hatchet ?

• ✅ Quand vous avez besoin de composer des workflows basés sur des DAG
• ✅ Quand les nouvelles tentatives et la conservation d’état sont importantes en cas d’échec
• ✅ Pour répartir les traitements dans des applications avec un grand nombre d’utilisateurs
• ❌ Si vous avez seulement besoin d’une file simple et rapide à mettre en place (Celery/BullMQ recommandés)
• ❌ Si l’intégration avec divers connecteurs de données est un critère important (Airflow/Prefect recommandés)

Comparaison : Hatchet vs autres solutions

• Hatchet vs Temporal

  • Hatchet prend en charge à la fois queue + DAG + Durable Execution
  • Temporal est optimisé pour la Durable Execution
  • Hatchet est simple à self-hoster (Postgres suffit)

• Hatchet vs BullMQ / Celery

  • Hatchet intègre historique des tâches + visualisation UI + orchestration embarquée
  • BullMQ/Celery sont des bibliothèques de file légères, mais avec des fonctions de supervision limitées

• Hatchet vs Airflow / Prefect

  • Hatchet offre exécution rapide, faible latence et gestion native des workers
  • Airflow/Prefect sont centrés sur les pipelines de données, avec un avantage sur les connecteurs d’intégration

Résumé

• Hatchet est une plateforme moderne de traitement distribué des tâches qui fonctionne uniquement avec Postgres
• Elle permet de mettre en place, avec un seul outil, un système de tâches durable, observable et composable
• Elle prend en charge à la fois le cloud et le self-hosting, et s’intègre facilement avec Python, Go et TypeScript

[halfenif]

Je l’ai testé pendant 2 heures avant d’écrire ceci.

• Comme je suis en train de mettre en place un MQ, je l’ai testé en me demandant si c’était quelque chose de nouveau basé sur Postgres, mais j’ai été un peu déçu en voyant qu’il fallait un rabbit
• Comme l’approche n’est pas pensée du point de vue k8s, j’ai lancé le docker-compose.yaml sur podman (+Arch)
• Comme je voulais utiliser Postgres séparément, il a fallu faire un peu plus de configuration, mais j’ai finalement arrêté en tombant sur SSL routines:OPENSSL_internal:WRONG_VERSION_NUMBER: Invalid certificate verification context
• Si quelque chose se passait mal en cours de route, il fallait supprimer la base de données Postgres et repartir de zéro
• Il faut recréer une API Key à chaque fois, et comme la clé complète n’est pas visible dans l’interface Web, il a fallu l’extraire avec les outils de développement.

[GN⁺]

Avis Hacker News

• Je me demande en quoi cela diffère d’autres exécuteurs de tâches Python basés sur pg, comme Procrastinate ou Chancy

• C’est très intéressant

  • lorsqu’il est dit que FOR UPDATE SKIP LOCKED ne passe pas à l’échelle jusqu’à 25k requêtes/s, je me demande à quel moment la limite a été atteinte
  • je m’interroge sur les lectures et écritures avec buffering, ainsi que sur le passage de toutes les tables volumineuses à des colonnes d’ID
  • je me demande si ces éléments faisaient partie de la solution pour faire évoluer FOR UPDATE SKIP LOCKED selon les besoins

• Je me demande si les opérations de file d’attente (mettre une tâche en file puis la marquer comme terminée) se produisent dans la même transaction que ma logique métier

  • je pense que c’est une capacité essentielle d’une file basée sur une base de données
  • cela simplifie la logique autour des nouvelles tentatives
  • le même problème peut aussi se poser lors de l’exécution des tâches
  • à ce stade, il vaudrait peut-être mieux utiliser SQS

• Je conçois une application basée sur des événements / workflows, et cette solution semble très prometteuse

  • j’ai aussi envisagé Temporal, mais je n’ai pas eu l’impression d’une adéquation parfaite
  • la licence open source me donne confiance pour la conception de l’application
  • je cherchais des conditions du type CEL

• Les six améliorations de l’architecture Hatchet ont permis d’améliorer les performances sur tous les plans

  • partitionnement par plage des tables de séries temporelles
  • partitionnement par hachage des événements de tâches
  • séparation des tables de monitoring et des files
  • lectures et écritures avec buffering
  • passage de toutes les tables volumineuses à des colonnes d’ID
  • usage intensif des triggers Postgres
  • on peut faire des choses étonnantes quand on lit le manuel

• Le README part du principe que davantage d’utilisateurs utilisent le mode sombre

  • le logo est blanc, donc sans mode sombre il est invisible
  • les statistiques GitHub seraient intéressantes à voir

• En utilisant Postgres comme file de messages, j’ai rencontré des problèmes pour traiter de grosses charges utiles (50 Mo et plus)

  • la solution a été d’utiliser des tables non journalisées et un vacuum complet régulier
  • je ne suis pas expert Postgres, mais je me demande si ce problème a été résolu

• Après avoir parcouru la documentation pendant 15 minutes, voici mon retour

  • le mode clair, l’open source, le logging et l’interface DX sont bien
  • il vaudrait mieux remplacer l’exemple Hello World par un scénario réel
  • le code d’un workflow avec des tâches à plusieurs étapes n’est pas intuitif
  • il faut se familiariser avec l’état d’esprit, les patterns et la terminologie de Hatchet
  • il semble manquer d’efforts pour rendre cela simple pour les clients
  • les billets d’ingénierie ont du sens, mais les clients ne s’intéressent pas à l’infrastructure cloud
  • comme il existe beaucoup d’options sur le marché des workflows, il y a de fortes chances qu’ils réécrivent ou pivotent encore une dernière fois
  • il faudrait se concentrer sur le parcours d’automatisation et permettre aux gens de facilement récupérer et configurer la solution
  • il est difficile de sérialiser des workflows en JSON
  • il faudrait permettre de déplacer facilement des workflows Hatchet vers une autre entreprise

• Félicitations pour la sortie de la v1

  • j’utilise Hatchet depuis presque un an et je l’ai déployé en production il y a 6 mois
  • le support open source et le démarrage rapide sont excellents
  • le travail d’ingénierie investi dans le système se voit

• Bonne première impression, félicitations pour le lancement

  • j’ai quelques questions
  • je me demande si les tâches persistantes sont prises en charge
  • je me demande où sont stockées les entrées et sorties des tâches
  • je me demande s’il est possible d’estimer le nombre de tâches que le système peut traiter par seconde en se basant sur la taille de l’instance PostgreSQL et les métriques d’E/S
  • j’évalue différents outils et j’aimerais savoir quelle impression donne Hatchet
  • je cherche un outil avec lequel il est possible de travailler avec un minimum de boilerplate