Che cos'è Hatchet
Hatchet è un motore open-source di orchestrazione per task in background, workflow durevoli e agenti AI. Nato come alternativa moderna alle classiche code di messaggi, si presenta come una "distributed task queue" costruita interamente sopra PostgreSQL: niente broker aggiuntivi come Redis o RabbitMQ da installare e mantenere, perché il database relazionale che quasi ogni applicazione già possiede diventa il cuore del sistema di accodamento, scheduling e tracciamento dello stato.
Il progetto è pubblicato su GitHub dall'organizzazione hatchet-dev con doppia licenza permissiva (MIT e Apache-2.0), e offre SDK nativi per Python, TypeScript, Go e — più di recente — Ruby. Può essere usato in self-hosting (tipicamente con Docker Compose) oppure come servizio gestito tramite Hatchet Cloud, mantenendo la stessa API e la stessa semantica.
Il problema che risolve
Ogni applicazione web seria, prima o poi, deve eseguire lavori fuori dal ciclo richiesta-risposta: inviare email, generare report, processare file, chiamare API di modelli linguistici, sincronizzare dati con sistemi esterni. Il modo ingenuo — eseguire tutto dentro la richiesta HTTP — si rompe appena i task diventano lenti, inaffidabili o numerosi. Servono code, retry, timeout, concorrenza controllata e visibilità su ciò che sta succedendo.
Il panorama open-source offre molte risposte parziali: Celery e BullMQ richiedono un broker separato; le code su database spesso mancano di funzionalità avanzate; gli orchestratori di workflow enterprise sono complessi da adottare. Hatchet prova a coprire l'intero spettro in un unico strumento: può fare da semplice coda FIFO, ma anche da orchestratore di workflow a grafo (DAG), da scheduler tipo cron, da sistema di esecuzione durevole per processi lunghi e persino da infrastruttura di checkpointing per agenti AI.
Come funziona
L'architettura si compone di tre elementi: il server Hatchet (con il suo database PostgreSQL), gli SDK client e i worker. Il server si occupa di accodare i task, distribuirli ai worker disponibili, gestire retry e stato. I worker sono processi della vostra applicazione che si registrano al server e dichiarano quali task sanno eseguire; il client è il codice che "lancia" i job dall'applicazione principale, per esempio da una route API.
La scelta di PostgreSQL come unico componente infrastrutturale non è un vezzo: permette l'accodamento transazionale, cioè la possibilità di inserire un job nella stessa transazione che modifica i dati applicativi. Se la transazione fallisce, il job non parte; se riesce, il job è garantito. Questo elimina un'intera classe di bug — i cosiddetti "dual write problem" — tipici delle architetture con broker separato.
Sui task singoli Hatchet innesta i workflow: si definiscono passaggi con dipendenze esplicite (il task B parte solo quando A è completato), formando grafi aciclici diretti. Ogni passaggio ha retry configurabili, timeout e backoff. Per i processi di lunga durata c'è la durable execution: lo stato intermedio viene salvato (checkpointing), così un worker che si riavvia riprende da dove si era fermato invece di ricominciare da zero — proprietà cruciale quando un singolo run può durare minuti o ore, come nelle pipeline multi-step di agenti AI.
Completano il quadro funzionalità normalmente riservate a sistemi ben più pesanti: rate limiting per controllare la pressione su API esterne, controllo della concorrenza a livello di worker o di chiave (per esempio "massimo due job simultanei per cliente"), routing complesso, multi-tenancy nativa con utenti e ruoli, scheduling cron, e una console web con osservabilità integrata: log applicativi ricercabili in full-text, tracciamento dei singoli run, metriche su durata ed errori.
Perché conta per l'AI e per le PMI
Due tendenze convergenti spiegano l'interesse crescente attorno a Hatchet. La prima è l'esplosione degli agenti AI in produzione: chiamate a LLM che si concatenano, tool invocati in sequenza, attese su risposte umane, timeout da gestire. Questi workload sono per natura lunghi, costosi e fallibili, e richiedono esattamente le proprietà di durabilità e osservabilità che Hatchet mette al centro. Il progetto parla esplicitamente a questo caso d'uso, posizionandosi come alternativa open e self-hostable a piattaforme chiuse.
La seconda tendenza è la ricerca di semplicità operativa. Per una PMI o un'agenzia che si auto-hosta, ogni componente infrastrutturale in più è un costo: macchine, aggiornamenti, monitoraggio, competenze. Poter dire "la coda job vive dentro il Postgres che già ho" riduce sensibilmente il carico. Inoltre la disponibilità di SDK sia Python sia TypeScript è rilevante per i team full-stack moderni, che spesso hanno il frontend e le API in TypeScript (Next.js e simili) e i workload di data/AI in Python: con Hatchet entrambi i mondi parlano con lo stesso orchestratore, senza dover mantenere due sistemi di code diversi.
Confronto con le alternative
Rispetto a Celery, lo standard storico in Python, Hatchet elimina la dipendenza da Redis o RabbitMQ e aggiunge nativamente workflow a DAG e console di osservabilità. Rispetto a BullMQ, molto diffuso in ambito Node, offre il vantaggio della persistenza transazionale su Postgres e il supporto multi-linguaggio. Rispetto a Temporal, il riferimento per la durable execution enterprise, Hatchet punta a una curva di apprendimento e un'operatività molto più leggere, a scapito di una maturità inferiore su scenari distribuiti estremi. Le code minimaliste su Postgres (per esempio quelle specifiche di un singolo linguaggio) restano più semplici per casi basilari, ma non coprono workflow, checkpointing e multi-tenancy con la stessa completezza.
Adozione e limiti
L'installazione self-hosted richiede il server Hatchet e PostgreSQL; la via più rapida è il Docker Compose ufficiale. Da lì si installa l'SDK nel linguaggio scelto (per esempio npm per TypeScript o pip per Python), si definisce un primo task con il suo worker e lo si lancia dal client. La documentazione su docs.hatchet.run copre guide per linguaggio, deployment e pattern avanzati.
I limiti da conoscere: il progetto è relativamente giovane e la sua API ha attraversato evoluzioni importanti tra le versioni, quindi conviene fissare la versione e seguire le note di rilascio. Usare Postgres come coda scala benissimo nella grande maggioranza dei casi reali, ma volumi estremi (milioni di task al minuto) richiedono tuning attento. Infine, come ogni sistema di orchestrazione, introduce un concetto in più da imparare: per una manciata di job settimanali può essere più che sufficiente una semplice coda o addirittura un cron.
Dove trovarlo
Il codice sorgente, gli SDK e le istruzioni di installazione sono su GitHub all'indirizzo github.com/hatchet-dev/hatchet, con licenza MIT/Apache-2.0. La documentazione ufficiale è su docs.hatchet.run, mentre hatchet.run ospita il sito del progetto e l'offerta cloud gestita per chi preferisce non auto-hostare. La community è attiva su Discord, canale indicato nel repository, e il progetto accetta contributi esterni.