Live data from Hacker News

Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

news.ycombinator.com

41–50 of 102 posts

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#41
I'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

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#42

can 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.

Long running transactions can easily lock up your database. I'd definitely avoid those. You're better off writing status records to the DB and using those to determine whether something is running, failing, etc.

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#43
post #33

Earlier 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.

We're source available, and a helm chart will be coming soon. We're actually doing the last of any queue migrations now.

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

#44
post #33
post #23

How 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…

If we’re going to give credit where credit’s due, the history of durable execution traces back to the ideas of AWS step functions and Azure durable functions alongside the original Cadence and Conductor project. A lot of the features here are attempting to make patterns in those projects accessible to a wider range of developers.

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...

[7] https://docs.hatchet.run/home/features/webhooks

[8] https://docs.hatchet.run/home/features/child-workflows

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#45

I 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…

I mostly agree... a traditional RDBMS can vertically scale a lot on modern hardware. It's usually easier for devs to reason with. And odds are already part of your stack. You can go a long way with just PostgreSQL. It works well for traditional RDBMS cases, works well enough as a Document store and other uses as well. The plugin ecosystem is pretty diverse as well, more than most competing options.

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

#46

Being 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'm not sure that it matters... all the cloud providers has simple queues and more complex orchestrators available already.

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

#47
post #23

How 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.

Hatchet and Temproral are MIT licensed and therefore usable by anyone, I can't find the license for Inngest, but in another comment they say it is "source available" and self hostable, not sure under what terms, but smart companies that avoid vendor lock in will want to steer well clear of it if they can.

Re: Launch HN: Hatchet (YC W24) – Open-source task queue, now with a cloud version

#48
post #33
post #23

How 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…

Maybe let them have their launch? Mitchell said it best:

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

#50

I'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

While the execution model is very similar to Airflow, we're primarily targeting async jobs which are spawned from an application, while Airflow is primarily for data pipelines. The connector ecosystem of Airflow is very powerful and not something that we're trying to replace.

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....

Post reply on HN