// the find
hatchet-dev/hatchet
🪓 Run Background Tasks at Scale
Hatchet is a durable background task queue and workflow orchestration platform built on Postgres, with SDKs for Go, Python, and TypeScript. It sits in the space between simple queues like BullMQ/Celery and heavy orchestrators like Temporal or Airflow. Primarily aimed at backend engineers who've outgrown Redis-backed queues but don't want to run Temporal's operational complexity.
- Postgres-only persistence is a significant operational advantage — no Cassandra, no separate result store, just one dependency you likely already have. This makes self-hosting genuinely tractable.
- Feature set is genuinely broad without being padded: DAG orchestration, durable execution with sleep/event-wait, per-key concurrency limits, dynamic rate limiting, sticky worker assignment, cron scheduling — these are real primitives you'd otherwise build yourself.
- SDK parity across Go, Python, and TypeScript is solid, with idiomatic patterns for each language rather than a thin wrapper over a single implementation.
- The comparison section in the README is honest about tradeoffs (e.g., 'use Temporal if you need non-Postgres backends') rather than claiming to replace everything — that's a good sign for project maturity.
- Self-hosting complexity is non-trivial — the server needs Postgres, a message bus, and several internal services, and the quickstart hides this behind Docker. Production deployment docs are sparse compared to what you'd need before trusting this with critical workloads.
- Throughput ceiling is explicitly called out as ~10k/s, which is fine for most apps but not stated with enough nuance — that number almost certainly varies heavily based on Postgres hardware, task size, and concurrency settings, and there are no published benchmarks to validate it.
- The Go SDK has a notably clunkier API than the Python/TypeScript ones — the factory/create opts pattern produces verbose boilerplate that feels like it was designed to accommodate the type system rather than the developer.
- Multi-tenant isolation (the RBAC, tenant model) adds complexity that solo or small-team self-hosters probably don't need, and there's no obvious way to run a simplified single-tenant mode without understanding the full data model.