mfrye0 an hour ago

I've been keeping an eye on this space for awhile as it matures a bit further. There's been a number of startups that have popped up around this - apart from Temporal and DBOS, Hatchet.run looked interesting.

I've been using BullMQ for awhile with distributed workers across K8 and have hacked together what I need, but a lightweight DAG of some sort on Postgres would be great.

I took a brief look at your docs. What would you say is the main difference of yours vs some of the other options? Just the simplicity of it being a single sql file and a sdk wrapper? Sorry if the docs answer this already - trying to take a quick look between work.

  • the_mitsuhiko an hour ago

    > I took a brief look at your docs. What would you say is the main difference of yours vs some of the other options? Just the simplicity of it being a single sql file and a sdk wrapper? Sorry if the docs answer this already - trying to take a quick look between work.

    It's really just trying to be as simple as possible. I was motivated by trying to just do the most simple thing I could come up with after I did not really find the other solutions to be something I wanted to build on.

    I'm sure they are great, but I want to leave the window open to having people self host what we are building / enable us to deploy a cellular architecture later and thus I want to stick to a manageable number of services until until I can no longer. Postgres is a known quantity in my stack and the only postgres only solution was DBOS which unfortunately did not look ready for prime time yet when I tried it. That said, I noticed that DBOS is making quite some progress so I'm somewhat confident that it will eventually get there.

motoboi an hour ago

Restate was built for agents before agents were cool.

Surprisingly haven take off yet when agents is all we are looking for now.

saadatq 2 hours ago

Somebody said this the other day on HN, but we really are living in the golden age of Postgres.

oulipo2 3 days ago

Really cool! How does it compare to DBOS ? https://docs.dbos.dev/architecture

  • the_mitsuhiko 3 days ago

    I'm sure with time DBOS will be great, I just did not have a lot of success with it when I tried it. It's quite complex, the quality of the SDKs was not overly amazing (when I initially used it, it had a ton of dependencies in it) and it just felt early.

oulipo2 3 days ago

Other question: why reimplementing your framework, rather than using an existing agent framework like Claude + MCP, or OpenAI + tool calling? Is it because you're using your own LM models, or just because you wanted more control on retries, etc?

  • the_mitsuhiko 3 days ago

    There are not that many agent frameworks around at the moment. If you want to be provider independent you most likely either use pydantic AI or the vercel AI SDK would be my guess. Neither one have built-in solution for durable execution so you end up driving the loop yourself. So it's not that I don't use these SDKs, it's just that I need to drive the loop myself.

    • jedberg 2 days ago

      > If you want to be provider independent you most likely either use pydantic AI ... Neither one have built-in solution for durable execution

      PydanticAI has DBOS built in [0].

      [0] https://ai.pydantic.dev/durable_execution/dbos/

      • the_mitsuhiko 2 days ago

        Oh interesting, maybe this makes for a better example then. If it has DBOS and Temporal it must be exposing some way to drive the loop. I'll investigate.

    • oulipo2 3 days ago

      Okay very clear! I was saying that because your post example is just a kind of basic "tool use" example which is already implemented by MCP/OpenAI tool use, but obviously I guess your code can be suited to more complex scenarios

      Two small questions:

      1. in your README you give this example for durable execution:

      const shipment = await ctx.awaitEvent(`shipment.packed:${params.orderId}`);

      I was just wondering, how does it work? I was more expecting a generator with a `yield` statement to run "long-running tasks" in the background... otherwise is the node runtime keeping the thread running with the await? doesn't this "pile up"?

      2. would your framework be suited to long-running jobs with multiple steps? I have sometimes big jobs running in the background on all of my IoT devices, eg:

      for each d in devices: doSomeWork(d)

      and I'd like to run the big outerloop each hour (say), but only if the previous one is complete (eg max num of workers per task = 1), and that the inner-loop be some "steps" that can be cached, but can be retried if they fail

      would your framework be suited for that? or is that just a simpler use-case for pgmq and I don't need the Absurd framework?

      • the_mitsuhiko 3 days ago

        > Okay very clear! I was saying that because your post example is just a kind of basic "tool use" example which is already implemented by MCP/OpenAI tool use, but obviously I guess your code can be suited to more complex scenarios

        That's mostly just because I found that to be the easiest way to use any existing AI API to work. There are things like vercel's AI SDK which internally runs the agentic loop in generateText, but then there is no way to checkpoint that.

        > I was just wondering, how does it work? I was more expecting a generator with a `yield` statement to run "long-running tasks" in the background... otherwise is the node runtime keeping the thread running with the await? doesn't this "pile up"?

        When you `awaitEvent` or `sleepUntil`/`sleepFor` it sets a wake point or sets a re-schedule on the database. Then it raises `SuspendTask` and ends the execution of the task temporarily until it's rescheduled.

        As for your IOT case: yes, you should be able to do that.

SrslyJosh 2 hours ago

Durable execution paired with an unpredictable text generator? Sign me up! /s