ETA: I really like the idea of this being entirely built on Postgres. That makes infrastructure a lot easier to manage
Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
41–50 of 102 posts
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#42can you run the whole task as a postgres transaction? like if i want to make an idempotent job by only updating some status to "complete" once the job finishes.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#43Earlier quoted context omitted.
Chiming in as the founder of https://www.inngest.com . It looks like Hatchet is trying to catch up with us, though some immediate differences: * Inngest is fully event driven, with replays, fan-outs, `step.waitForEvent` to automatically pause and resume durable functions when specific events are received, declarative cancellation based off of events, etc. * We have real-time metrics, tracing, etc. out of the box in o…
But we can't self host, right? So it's locked in.
One of our key aspects is reliability. We were apprehensive of officially supporting self hosting with awkward queue and state store migrations until you could "Set it and forget it". Otherwise, you're almost certainly going to be many versions behind with a very tedious upgrade path.
So, if you're a cowboy, totally self hostable. If you're not (which makes sense — you're using durable execution), check back in a short amount of time :)
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#44How does this compare to Temporal or Inngest? I've been investigating them and the durable execution pattern recently and would like to implement one soon.
Chiming in as the founder of https://www.inngest.com . It looks like Hatchet is trying to catch up with us, though some immediate differences: * Inngest is fully event driven, with replays, fan-outs, `step.waitForEvent` to automatically pause and resume durable functions when specific events are received, declarative cancellation based off of events, etc. * We have real-time metrics, tracing, etc. out of the box in o…
Hatchet is also event driven [1], has built-in support for tracing and metrics, and has a TS [2], Python [3] and Golang SDK [4], has support for throttling and rate limiting [5], concurrency with custom multi-tenancy keys [6], works on serverless [7], and supports procedural workflows [8].
That said, there are certainly lots of things to work on. Batching and better tracing are on our roadmap. And while we don’t have a Java SDK, we do have a Github discussion for future SDKs that you can vote on here: https://github.com/hatchet-dev/hatchet/discussions/436.
[1] https://docs.hatchet.run/home/features/triggering-runs/event...
[2] https://docs.hatchet.run/sdks/typescript-sdk
[3] https://docs.hatchet.run/sdks/python-sdk
[4] https://docs.hatchet.run/sdks/go-sdk
[5] https://docs.hatchet.run/home/features/rate-limits
[6] https://docs.hatchet.run/home/features/concurrency/round-rob...
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#45I love seeing commercial activity around using Postgres as a queue. Last year I wrote a post titled "Choose Postgres queue technology" that spent quite a bit of time on the front page here. I don't think it's likely that my post actually sparked new development in this area, but for the people who were already using Postgres queues in their applications, I hope it made them feel more comfortable talking about it in p…
Where I defer is if you already have Redis in the mix, I might be inclined to reach for it first in a lot of scenarios. If you have complex distribution needs then something more like RabbitMQ would be better.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#46Being MIT licensed, does that mean that another company could also offer this as a hosted solution? Did you think about encumbering with a license that allowed commercial use, but prohibited resale? Also, somewhat related, years ago I wrote a very small framework for fan-out of Django-based tasks in Celery. We have been running it in production for years. It doesn't have adoption beyond our company, but I think there…
I do think their cloud offering is interesting, and being PostgreSQL backed is a big plus for in-house development.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#47How does this compare to Temporal or Inngest? I've been investigating them and the durable execution pattern recently and would like to implement one soon.
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#48How does this compare to Temporal or Inngest? I've been investigating them and the durable execution pattern recently and would like to implement one soon.
Chiming in as the founder of https://www.inngest.com . It looks like Hatchet is trying to catch up with us, though some immediate differences: * Inngest is fully event driven, with replays, fan-outs, `step.waitForEvent` to automatically pause and resume durable functions when specific events are received, declarative cancellation based off of events, etc. * We have real-time metrics, tracing, etc. out of the box in o…
https://x.com/mitchellh/status/1759626842817069290?s=46&t=57...
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#49Looks cool, but I’m still team everything-in-Postgres
Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version
#50I'm really curious how you folks compare to something like Apache Airflow. They do a similar durable execution w/ DAGs on top of postgres and redis. They're Python-only (one definite difference). I'm curious what other comparisons you see ETA: I really like the idea of this being entirely built on Postgres. That makes infrastructure a lot easier to manage
That's not to say you can't use Hatchet for data pipelines - this is a common use-case. But you probably don't want to use Hatchet for big data pipelines where payload sizes are very large and you're working with payloads that aren't JSON serializable.
Airflow also tends to be quite slow when the task itself is short-lived. We don't have benchmarks, but you can have a look at Windmill's benchmarks on this: https://www.windmill.dev/docs/misc/benchmarks/competitors#re....