Hatchet

What it is

Hatchet is a distributed task queue and workflow orchestration engine, built to replace Celery, BullMQ, or hand-rolled cron+queue setups for background job processing. It's Postgres-backed (uses LISTEN/NOTIFY and row-level locking rather than Redis), which means you get durable execution, retries, rate limiting, concurrency control, and DAG-style workflows without adding another stateful service to your stack if you already run Postgres. It's positioned in the "AI Agent" category because a large chunk of current adoption is teams orchestrating LLM calls, agent steps, and long-running AI pipelines that need retries, timeouts, and observability — but the core engine is general-purpose background job infrastructure.

SDKs exist for Python, TypeScript, and Go. You can self-host the engine or use their managed cloud offering.

Who builds it and why

Hatchet is a VC-backed startup product, not a foundation project or community-governed effort. The company builds it because durable task execution is a real, recurring pain point — every team building agentic workflows or async pipelines eventually reinvents retry logic, dead-letter queues, and concurrency limits badly. Hatchet's bet is that Postgres-backed orchestration is simpler to operate than Redis+Celery or a full Temporal deployment, while still being production-grade. The open-core model (MIT-licensed engine, paid managed cloud) is the commercial mechanism.

81 contributors and steady commit activity through mid-2026 suggest an actively maintained project with a real engineering team behind it, not a side project.

Production readiness signal

7,441 GitHub stars, MIT license, Go core, and a recent release (v0.90.13) indicate active, iterative development — the sub-1.0 version number is worth noting: this is still pre-1.0 software, which means breaking changes between minor versions are plausible and you should read changelogs before upgrading.

CNCF maturity is not publicly available — this is not a CNCF project, so don't expect the governance, security audit trail, or vendor-neutrality guarantees that come with that ecosystem. Founded date is not publicly available either, so tenure and long-term survivability are hard to independently verify beyond commit history.

The commit cadence and contributor count are reasonable production-readiness proxies, but at pre-1.0, you should treat this as "solid engineering, immature API contract" rather than "battle-tested at scale for years."

Who should use this

• Teams running LLM/agent pipelines that need durable retries, timeouts, and step-level observability without building it themselves.
• Teams already running Postgres who want to avoid adding Redis/RabbitMQ just for a task queue.
• Python/TypeScript/Go shops replacing Celery or BullMQ who want built-in workflow DAGs, rate limiting, and a real UI for debugging task state.
• Small-to-mid engineering teams that want self-hosted control but don't want to operate Temporal's complexity.

Who should NOT use this

• Teams needing strict CNCF governance or vendor-neutral guarantees for compliance reasons — this is a single-vendor commercial product.
• Very high-throughput, low-latency queueing use cases (millions of messages/sec) where Kafka or a purpose-built message broker will outperform a Postgres-backed queue.
• Organizations that need long-term API stability guarantees today — pre-1.0 versioning means you should expect churn.
• Teams already deeply invested in Temporal or Airflow with no acute pain — migration cost likely exceeds benefit.

Alternatives

• Temporal — more mature, battle-tested at massive scale, but heavier operationally and steeper learning curve.
• Celery + Redis — the incumbent; more battle-tested, but you own all the retry/observability tooling yourself.
• Airflow — better fit for scheduled batch/ETL DAGs, weaker fit for real-time task execution or agent workflows.

Pricing

The core engine is MIT-licensed and free to self-host. Hatchet also offers a managed cloud product with usage-based pricing — exact tiers and costs are not publicly available in the data provided; check their pricing page directly before committing.