Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Hatchet v1 – A task orchestration platform built on Postgres

github.com

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#21

Post by abelanger »

KraftyOne wrote: post #19
digdugdirk wrote: post #2

Interesting! How does it compare with DBOS? I noticed it's not in the readme comparisons, and they seem to be trying to solve a similar problem.

(DBOS co-founder here) From a DBOS perspective, the biggest differences are that DBOS runs in-process instead of on an external server, and DBOS lets you write worklflows as code instead of explicit DAGs. I'm less familiar with Hatchet, but here's a blog post comparing DBOS with Temporal, which also uses external orchestration for durable execution: https://www.dbos.dev/blog/durable-execution-coding-compariso...

> and DBOS lets you write worklflows as code instead of explicit DAGs

To clarify, Hatchet supports both DAGs and workflows as code: see https://docs.hatchet.run/home/child-spawning and https://docs.hatchet.run/home/durable-execution

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#22

Post by abelanger »

avan1 wrote: post #20

Don't want to steal your topic but I had written a lightweight task runner to learn GoLang [0]. Would be great to have your and others' comments. It works only as a Go library. [0] https://github.com/oneapplab/lq P.S: far from being alternative to Hatchet product

Nice! I haven't looked closely, but some initial questions/comments:

1. Are you ordering the jobs by any parameter? I don't see an ORDER BY in this clause: https://github.com/oneapplab/lq/blob/8c9f8af577f9e0112767eef...

2. I see you're using a UUID for the primary key on the jobs, I think you'd be better served by an auto-inc primary key (bigserial or identity columns in Postgres) which will be slightly more performant. This won't matter for small datasets.

3. I see you have an index on `queue`, which is good, but no index on the rest of the parameters in the processor query, which might be problematic when you have many reserved jobs.

4. Since this is an in-process queue, it would be awesome to allow the tx to be passed to the `Create` method here: https://github.com/oneapplab/lq/blob/8c9f8af577f9e0112767eef... -- so you can create the job in the same tx when you're performing a data write.

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#24

Post by morsecodist »

This is great timing. I am in the process of designing an event/workflow driven application and nothing I looked at felt quite right for my use case. This feels really promising. Temporal was close but it just felt like not the perfect fit. I like the open source license a lot it gives me more confidence designing an application around it. The conditionals are also great. I have been looking for something just like CEL and despite my research I had never heard of it. It is exactly how I want my expressions implemented, I was on the verge of trying to build something like this myself.

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#25

Post by latchkey »

Cool project. Every time one of these projects comes up, I'm always somewhat disappointed it isn't an open source / postgres version of GCP Cloud Tasks.

All I ever want is a queue where I submit a message and then it hits an HTTP endpoint with that message as POST. It is such a better system than dedicated long running worker listeners, because then you can just scale your HTTP workers as needed. Pairs extremely well with autoscaling Cloud Functions, but could be anything really.

I also find that DAGs tend to get ugly really fast because it generally involves logic. I'd prefer that logic to not be tied into the queue implementation because it becomes harder to unit test. Much easier reason about if you have the HTTP endpoint create a new task, if it needs to.

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#28

Post by someone13 »

abelanger wrote: post #22
avan1 wrote: post #20

Don't want to steal your topic but I had written a lightweight task runner to learn GoLang [0]. Would be great to have your and others' comments. It works only as a Go library. [0] https://github.com/oneapplab/lq P.S: far from being alternative to Hatchet product

Nice! I haven't looked closely, but some initial questions/comments: 1. Are you ordering the jobs by any parameter? I don't see an ORDER BY in this clause: https://github.com/oneapplab/lq/blob/8c9f8af577f9e0112767eef... 2. I see you're using a UUID for the primary key on the jobs, I think you'd be better served by an auto-inc primary key (bigserial or identity columns in Postgres) which will be slightly more performa…

I just want to say how cool it is to see you doing a non-trivial review of someone else’s thing here

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#29

Post by lysecret »

This is awesome and I will take a closer look! One question: We ran into issue with using Postgres as a message queue with messages that need to be toasted/have large payloads (50mb+).

Only fix we could find was using unlogged tables and a full vacuum on a schedule. We aren’t big Postgres experts but since you are I was wondering if you have fixed this issue/this framework works well for large payloads.

Re: Show HN: Hatchet v1 – A task orchestration platform built on Postgres

#30

Post by diarrhea »

abelanger wrote: post #6
diarrhea wrote: post #5

This is very exciting stuff. I’m curious: When you say FOR UPDATE SKIP LOCKED does not scale to 25k queries/s, did you observe a threshold at which it became untenable for you? I’m also curious about the two points of: - buffered reads and writes - switching all high-volume tables to use identity columns What do you mean by these? Were those (part of) the solution to scale FOR UPDATE SKIP LOCKED up to your needs?

I'm not sure of the exact threshold, but the pathological case seemed to be (1) many tasks in the backlog, (2) many workers, (3) workers long-polling the task tables at approximately the same time. This would consistently lead to very high spikes in CPU and result in a runaway deterioration on the database, since high CPU leads to slower queries and more contention, which leads to higher connection overhead, which le…

Thank you! Very insightful, especially the forum link and the observation around UUIDs bloating indexes.
Post reply on HN