Hatchet combines queues and durable workflows in one service
Hatchet covers work that often starts with a queue and ends with several home-built systems. It runs one-off tasks, cron jobs, scheduled work, directed graphs, and durable tasks that can sleep or wait for events. Workers stay in Python, TypeScript, Go, or Ruby. The server records execution state in PostgreSQL, while its web interface exposes runs, logs, alerts, and metrics. That makes it useful when background processing is part of the product rather than an occasional maintenance script.
A 4,594-file repository with about 708,942 source lines shows the size of that promise. Hatchet includes priority, dynamic rate limits, concurrency policies, worker slots, labels, weighted affinity, OpenTelemetry, and Prometheus support. Multi-tenant controls let one installation serve several teams. The latest v0.105.2 release added workflow pausing and per-member payload visibility, alongside fixes for task eviction, retry backoff, and missing rows. This is a full control plane, not a small queue library.
Durable history costs more than a broker queue
PostgreSQL keeps task state and execution history for a configured retention period. That record helps operators inspect failures, resume long work, and understand what an agent did before it waited. Hatchet can also enforce per-customer concurrency or rate limits through dynamic keys. These controls matter when a downstream API has a quota or one tenant could consume every available worker. Teams already maintaining separate queue, scheduler, retry, and admin systems may remove a fair amount of glue.
Hatchet's README says durability adds overhead and contrasts it with Redis or RabbitMQ systems that can reach higher throughput. Its own cited load test reaches 10,000 tasks per second, but that is the project's figure, not ours and not a promise for another deployment. If jobs are short, independent, and safe to lose or retry blindly, retained workflow history may be needless expense. Celery or BullMQ will usually ask less of both the application and its operators.
What happened when we ran it
Our sandbox installed 438 packages in 67 seconds, then completed the build in 224 seconds. The checkout at commit 89d130f occupied 121.4 MB and contained about 708,942 source lines. Those figures describe a fresh unprivileged container with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image. They are source-tree results, not a Hatchet Cloud trial or a production throughput test.
The Go test command failed after 74 seconds. Its summary counted 40 passing package results and 3 failing results out of 43. The final log lines list many SDK examples with no test files, show sdks/go/internal and sdks/go/internal/eviction passing, and end with FAIL. The tail does not contain the names or assertions for the 3 failures, so we cannot responsibly assign a cause. Buyers should treat the red run as an unresolved compatibility finding.
Local setup requires Docker; self-hosting requires PostgreSQL
The README's shortest local route has 3 actions: install the CLI, check its version, and start the server. Docker is required on macOS, Linux, or WSL. Hatchet recommends trying its cloud service even if self-hosting is the eventual goal, which is sensible for evaluating the dashboard and workflow model before operating the stack. There is a Compose file in the repository, although our scan found no Dockerfile at the root.
A serious self-managed installation must handle PostgreSQL backups, retention, upgrades, service credentials, and worker deployment. Teams also need application tests for cancellation, duplicate delivery, timeouts, downstream throttling, and abrupt shutdown. Issue #4731 gives one pointed example: a Python action listener reportedly remained alive after its parent worker died and continued accepting jobs. The issue received activity on August 25, 2026, so abrupt process death belongs in an adoption test rather than a future checklist.
Application workflows fit better than connector-led data pipelines
Hatchet's SDK range is useful in a mixed service estate. A TypeScript API can trigger Python model work while Go workers handle another path, all visible through one control plane. Durable sleep and event waits suit approval steps, delayed agent actions, and outside callbacks because a worker does not have to stay occupied. Version v0.105.2 also introduced an early embedded mode beta for TypeScript and Python, aimed at local development, end-to-end tests, and CI.
Data teams should read Hatchet's comparison section carefully. The project supports DAGs, but says Airflow, Prefect, and Dagster focus on integrations with common data stores. Hatchet expects adopters to write their own integrations and positions itself for application workloads. The difference is the work surrounding the graph. A connector catalog favors a data orchestrator; request-driven jobs, tenant limits, durable waits, and several worker languages favor Hatchet.
Active releases reduce maintenance risk, not adoption work
GitHub recorded the latest push on August 26, 2026, one day after release v0.105.2. The repository had 7,791 stars and 139 open issues and pull requests when fetched. Recent reports and patches covered Python worker lifecycle, retry defaults, durable task behavior, and dependency updates. That combination supports a high community score, while the open count must not be misread as 139 confirmed bugs.
Hatchet is worth a pilot when a team is about to build its second generation of background-job infrastructure. Start with one workflow that includes a retry, a wait, a worker crash, and a rate limit. Pin the server and SDK versions, then repeat the failure tests during upgrades. If that exercise replaces custom recovery code and an admin dashboard, the control plane earns its keep. If it only sends emails and webhooks, keep the simpler queue.