build(deps): bump github.com/hatchet-dev/hatchet from 0.53.14 to 0.56.3 in /go

[dependabot]

Bumps github.com/hatchet-dev/hatchet from 0.53.14 to 0.56.3.

Release notes

Sourced from github.com/hatchet-dev/hatchet's releases.

v0.56.3 - Benchmarking Service

Benchmarking Hatchet

Today, we're open-sourcing our new benchmarking container, which allows anyone to test the performance of their Hatchet setup. This load testing container can be run in pretty much any environment -- for example:

docker run -e HATCHET_CLIENT_TOKEN=your-token ghcr.io/hatchet-dev/hatchet/hatchet-loadtest -e "100" -d "60s" --level "warn" --slots "100"

Example Results

With our latest v1 Hatchet engine, we ran a series of internal benchmarks on an 8 CPU database (Amazon RDS m7g.2xlarge), achieving a stable throughput of up to 2000 events/second. Beyond that, we've also tested higher throughput on larger DB instances (for example, up to 10k events/second on an m7g.8xlarge).

Here's a brief summary of our results:

• Throughput: Scales smoothly up to 2000 events/s on m7g.2xlarge, leveling out at about 83% CPU utilization on the database.
• Latency: For lower throughput (100-500 events/s), average execution time remains below 50ms.
• Setup: Benchmarks were run against a Kubernetes cluster on AWS with 2 Hatchet engine replicas (c7i.4xlarge). The RDS database instance (m7g.2xlarge) was chosen to avoid disk/CPU contention under typical load.

The new engine design allows Hatchet to efficiently handle high volumes of background tasks with stable performance, making it well-suited for AI-driven workloads or large-scale async event processing.

Want to see more details or run your own benchmarks? Read our benchmarking guide for more information.

v0.55.26 - Hatchet v1 Engine

🪓 Launching our v1 Engine

March 24th, 2025

For the past several months, we've been working on a complete rewrite of the Hatchet queue with a focus on performance and a set of feature requests which weren't possible in the v0 architecture. The v1 engine has been available in preview for several weeks, and is currently running over 200 million tasks/month on Hatchet Cloud.

Migration Guide

To upgrade to the v1 engine, please see our migration guide in our docs.

In the rest of this document, we'll cover the major architectural improvements that we made to the Hatchet engine -- while you don't need to worry about these as a Hatchet user, perhaps they'll be interesting to other developers who are working on similar Postgres scaling problems.

TL;DR - nearly every usage pattern of Hatchet is faster and more efficient in v1, including usage of concurrency keys, high-throughput workflows, and long-running workflows. We've seen a 30% reduction in latency, a 10x increase in throughput, and a 5x reduction in CPU and IOPs load on the database.

Throughput Improvements

One of the main bottlenecks in the previous Hatchet engine was throughput -- we could only handle about 1k tasks/second on the ingestion side, even on a relatively large database, even though we could queue at a much faster rate once the work was ingested into the system.

Hatchet is a durable task queue built on Postgres, which means that every result and intermediate task event needs to be persisted to the database in a transactionally-safe manner. One of the main ways to increase throughput in Postgres is to perform batch inserts of data, which can considerably cut down on transaction overhead and round trips to the database.

While the v0 engine was utilizing batch inserts on a few high-volume tables, the v1 engine now uses batch inserts on almost every table in the system. This has allowed us to increase throughput by an order of magnitude -- we're now able to queue up to 10k tasks/second on a single Hatchet instance, and we've been able to sustain that rate over a 24 hour period.

However, throughput and latency are always a tradeoff -- so how did the Hatchet engine get faster as as well? The answer comes down to dynamic buffering...

Latency Improvements

... (truncated)

Commits

• b20b74d fix (#1422)
• 3ee2010 fixes (#1421)
• 1763878 feat: managed compute and benchmarks (#1419)
• 9a5b21b feat: load testing container (#1416)
• 0c4e52a [Docs] Concurrency, Additional Metadata (#1415)
• 9c389ee fix: get values for checksum after ordering (#1414)
• cff2b37 fix: checksums on workflow versions (#1410)
• 33b15c9 feat(ts): cancel, replay (#1412)
• e51a589 fix: update path for PydanticWorker in migration guide (#1411)
• 9681189 feat: docs (#1404)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #56.