jumski

Valid point!

So pgflow is really agnostic and Postgres is it's fundamental dependency. All components are modular and ready to be adapted to other runtimes.

It's just that Supabase is what I use and I figured out this will be my first platform, but the abstraction to port to others is there!

Oh really? Would love to check it out and borrow some ideas! :)

Using queues in atomic, transactional way was a core principle for building https://pgflow.dev - having whole workflow state transactionally updated alongside the work on the in db queue really simplifies a lot of things: debugging is easier, audit log is easy, reporting, stats etc are one SQL query away.

git worktree uses one repo to laid out multiple branches in separate directories.

git worktree add new/path/for/worktree branchname

I now refuse to use git checkout to switch branches, always keep my main branch checked out and updated and always use worktrees to work on features. Love this workflow!

Great article! I have similar observations and techniques and Claude Code is exceptionally good - most of the days I'm working on multiple things at once (thanks to git worktrees) and each going faster than ever - that's really crazy.

For the "sub agents"thing, I must admit, that Claude Code calling o3 via sigoden/aichat saved me countless of times!

There are just issues that o3 excells at (race conditions, bug hunting - anything that requires lot of context and really high reasoning abilities).

But I'm using it less since Opus 4 came out. And of course its none of the sub-agent thing at all.

I use this prompt @included in the main CLAUDE.md: https://github.com/pgflow-dev/pgflow/blob/main/.claude/advan...

sigoden/aichat: https://github.com/sigoden/aichat

Come here to write this - perfect analogy!

I’m tinkering on pgflow – an open-source, DAG-based workflow engine that uses Postgres to orchestrate workers on top of PGMQ queues. It seamlessly integrates with Supabase (no new infra needed!) and executes code on Edge Functions using custom, serverless task queue worker. All the current and past state of all executions is stored in Postgres and can be queries with simple SELECTs and flows can be started from within the db (think: pg_cron, triggers).

I have strong focus on db consistency and Type safety between steps.

### Built so far – core SQL orchestration (state machine, retries, observability, queue management) – strictly typed TypeScript DSL + compiler that turns flow definitions into migrations – a minimal Edge Function worker that polls, executes and reports back

### Current focus I’m heads-down on a dedicated client library. It leverages Supabase Realtime to stream events and progress of each flow run back to the browser, while having strict compile-time safety for flows defined with the TypeScript DSL.

### Next on the roadmap - Fanouts for processing arrays of data in parallel, with per-item retry logic. - SQL-based conditionals/branching that leverages JSONB containment operator and step outputs

Docs: https://www.pgflow.dev/concepts/how-pgflow-works/ Repo: https://github.com/pgflow-dev/pgflow

pgflow can be used with any language/runtime, I just started with TypeScript and Supabase, as that's what I'm using.

The worker is stateless and "dumb" by design (currently it runs on serverless functions) - it just calls SQL functions: "poll_for_tasks" to get some tasks from the queue and then either "complete_task" or "fail_task" after executing user code - that's it, nothing more, so it should be relatively easy to adopt it to other runtimes.

I have written a small architecture primer on pgflow if anyone is interested in its simple but flexible design https://www.pgflow.dev/concepts/how-pgflow-works/

It is kinda sad that the information about how many tokens are included is not provided - its hard to judge versus pay-as-you-go api usage because of that

I think Gemma 3 is marketed for single GPU setups https://blog.google/technology/developers/gemma-3/

Thanks! That's the reason I'm building it - I needed something like this but there was nothing abailable.

I'm very close to releasing an alpha, will post here when ready!

Nice to see some workflow engine action on Hacker News! :-)

I'm currently building pgflow, which is a simple, postgres-first engine that uses task queues to perform real work.

Have explicit DAG approach, strong typesafety, nice DSL in TypeScript and a dedicated task queue worker that allows it to run solely on Supabase without any external tools.

I'm super close to the alpha release, if you guys want more info, check out the readme for SQL core (https://github.com/pgflow-dev/pgflow/tree/main/pkgs/core#rea...) or my Twitter (https://x.com/pgflow_dev).

Hope that grabs someone attention :-) Cheers

I'm not sure if this would scratch your itch, but I'm building a Postgres-native workflow engine that separates orchestration from execution. I want to be able to start my flows from within db triggers.

It just exposes set of functions to propagate the DAG through states and queues tasks for a task worker to perform the actual work and acknowledge completion or failure back to the sql orchestrator.

I was working on it for last few months and it will be ready in upcoming weeks, first version is dedicated to work on Supabase but I plan to make it agnostic.

If you want to learn more, check out the SQL Core readme which explains the whole concept (https://github.com/pgflow-dev/pgflow/tree/main/pkgs/core#rea...) or my Twitter for updates and some demos (https://x.com/pgflow_dev).

I'm building pgflow, a Postgres-native workflow orchestration engine that keeps the entire DAG's state and orchestration logic inside the database, while a dedicated task queue worker (Edge Worker) handles execution.

This split minimizes external dependencies and makes it easy to manage complex pipelines without leaving PostgreSQL.

I started pgflow because I wanted a fully integrated, Supabase-based system (no separate servers!) for reliable, parallel workflows which keep state in postgres so I can trigger flows from triggers and stream their progress via Supabase Realtime.

Started protytyping it in early November, released serverless task queue worker in January and I'm currently polishing the flow orchestrator pieces, releasing an alpha version in upcoming weeks.

If you're curious:

- More on Twitter/X: @pgflow_dev (https://x.com/pgflow_dev)

- Edge Worker docs (will get flow orchestration docs included soon): https://pgflow.dev

Reddit updates:

- https://www.reddit.com/r/Supabase/comments/1jfrky2/huge_mile...

- https://www.reddit.com/r/Supabase/comments/1ij9jcl/introduci...

Happy to discuss or collaborate if anyone's interested!

TypedAI looks solid, was not aware of it! Bookmarked for further research.

Personally I am not fond of the decorator approach and decided to not use it in pgflow (my soon-to-be-released workflow orchestration engine on top of Postgres).

1. I wanted it to be simple to reason about and explicit (being more verbose as a trade-off)

2. There are some issues with supporting decorators (Svelte https://github.com/sveltejs/svelte/issues/11502, and a lot of others).

3. I decided to only support directed acyclic graphs (no loops!) in order to promote simplicity. Will be supporting conditional recursive sub-workflows to provide a way to repeat some steps and be able to branch.

Cheers!

I think it is just easier to comprehend if the edges/dependencies are explicit (as an array for example).

Yeah, I also found this a bit unintuitive at first. I’m building a workflow engine myself (https://pgflow.dev/pgflow, not released yet), and I’ve been thinking a lot about how to model the DSL for the graph and decided to make dependencies explicit and use method chaining for expansion with other step types.

Here’s how it would look like in my system:

  new Flow<string>()  
    .step("llm", llmStepHandler)  
    .step("decider", ["llm"], deciderStepHandler)  
    .step("agentOne", ["decider"], agentOneStepHandler)  
    .step("agentTwo", ["decider"], agentTwoStepHandler)  
    .step("workflow", ["agentOne", "agentTwo"], workflowStepHandler);  

Mine is a DAG, so more constrained than the cyclic graph Mastra supports (if I understand correctly).

I'm using Avante daily for several months and it is great but kot without it's quirks. Thanks for sharing - I will be testing this companion because it seems like a nicer DX with the @agent and #context mentions

Yes I have. I'm on Pixel 6, just verified again and still no luck for me :-(

Thanks for the recommendation tho - you reminded me that I have some old Xiaomi phone that should be able to run it still!

Revolut stopped working for me on GrapheneOS with an official message "Sorry, Revolut is not supported on devices with custom firmware".

I believe you do not need to use HCL to be able to work in hybrid mode - it would be definitely a blocker for me.

Will get to testing it when getting more free time. Cool stuff! <3

thanks for contributing this! i will definitely check it, was thinking about using https://atlasgo.io/ for declarative sql code, glad there is another option!

Thank you for sharing this—it resonates deeply with me. I share the same passion and often struggle to separate work from life because I genuinely enjoy programming. Over time, I’ve come to realize that as long as I stay connected to my family and relationships, I can find balance and even relax by doing what I love—coding. Knowing there are others who share these experiences is truly reassuring.

By the way, have you read Paul Graham's essay "A Project of One's Own" (https://paulgraham.com/own.html)? I really connected with his idea of being a "skater," and I wonder if you might relate to it as well.

That is awesome!

Do you support any arbitrary queries? For example, can i call a plpgsql function with your DSL?