I'm building a Postgres-native workflow engine using pgmq for queues and TypeScript worker. Workflows compile to definitions (SQL rows), letting Postgres orchestrate the DAG as state machines. The TypeScript DSL is type-safe with inferred inputs/outputs across dependencies with full autocomplete.
Declarative and functional in nature. Just a manifest wiring functions into a DAG and a Postgres SQL functions that manage the graph of state machines. Simple in principle and very opinionated.
Replaces 240 lines of manual pg_cron -> pgmq -> Supabase Edge Function boilerplate with 20 lines of explicit DAG definitions. Currently Supabase-only (leverages their primitives) but planning to make it agnostic for vanilla Postgres setups.
that sounds like a reasonable compromise, it may even provide more control and protection over what they are able to achieve on Windows?
i remember their anti cheat was utter crap tbh, not like something that Riot implemented for Valorant (a kernel-level system that runs from boot-up with deep system access)
I recently tried to run Apex Legends on my Manjaro (i played this a lot few years ago on my Windows dualboot), but it is impossible to play it on Linux, as EA/Respawn is preventing the game from running on Linux due to Anti cheat systems having troubles with protecting the game.
I'm really curious what would be the appropriate solution for an anti cheat that runs on Linux in a way that a) does not compromise my OS/privacy/security b) protects the game from cheaters at the same time.
The same pattern is everywhere: addictive games, addictive food, addictive social-media content.
It is really sad to see how society is driven by the monetization strategies of large companies.
I have a close friend who buried his depression under a pile of games built around these temporal reward loops. He’s not working and still living with his parents at 40.
Thank you for sharing this - awareness of these patterns needs to be spread.
Worth mentioning that WAL is enabling and used by Supabase Realtime [0] and WalEx [1] which both are doing very similar thing - polling the WAL changes in order to emit them as Websocket events.
I never worked with WalEx but have experience with Supabase Realtime and it is a joy to work with and fits great into the Supa ecosystem. So many layers are disappearing when you rely more on Postgres!
Good point! For the SQL functions I mentioned, I'm comfortable without triggers - all mutations go through functions (no direct table access), and only start_flow is user-fac
ing.
That said, there ARE other places that would benefit from triggers (aggregate counts). I've avoided them because they're hot paths and I was worried about perf impact - relyi
ng on pgTAP coverage instead.
Your defense-in-depth argument is solid though. I should revisit this and benchmark whether the safety is worth the perf cost. Something like RegreSQL would come in handy
No cliche at all - I'm in the same boat, showing my stuff online was way out of my comfort zone!
I was postponing proper, dedicated performance testing for some time and would really love to up my game in that regard.
I'm very happy with pgTAP approach of running stuff in transaction and rolling them back after the test - how this works in RegreSQL?
Would love to provide feedback and test the hooks when you will be working on them. I'm mostly interested in performance testing and my use case would be to run them on CI and compare to previous metrics stored somewhere in order to fail CI when performance regressions are introduced.
Looks really well thought out and I will be testing it for sure!
I'm wondering how I would be able to regression-test functions in my project (pgflow [0]) - it tracks a graph of state machines modeled in few tables. State is mutated only by calling few exposed SQL functions (task queue worker does it).
Given I can't enforce everything I need with check constraints and I try to avoid triggers if possible, I opted for only using exposed SQL API [1] for setting up state in my pgTAP tests.
It is imperative and harder to maintain, like scripts you described in the article, but really my only option, as I want to have maximum confidence level.
Does RegreSQL support some kind of init scripts or I would need to wire it myself and just run RegreSQL after the proper state is set? Would lose the "run once and get report on everything" benefit then :-(
Are skills in your system related to Claude 's skills or modelem in similar way?
I love the idea of relying on markdowns and filesystem as universal API .The progressive discovery is great and very flexible and I'm regularly extracting parts of my workflow to small, focused skills.
Declarative and functional in nature. Just a manifest wiring functions into a DAG and a Postgres SQL functions that manage the graph of state machines. Simple in principle and very opinionated.
Replaces 240 lines of manual pg_cron -> pgmq -> Supabase Edge Function boilerplate with 20 lines of explicit DAG definitions. Currently Supabase-only (leverages their primitives) but planning to make it agnostic for vanilla Postgres setups.
Live demo / explanation here: https://demo.pgflow.dev