Last year, workflow failures cost enterprises $1.2 trillion in lost productivity—yeah, that’s trillion with a T, according to Gartner.
And here’s this tiny open-source project called Absurd Workflows claiming to fix that mess using… nothing but Postgres. No Kafka queues, no dedicated engines like Temporal or Cadence, no cloud vendor lock-in. Just your garden-variety relational database, tricked into orchestrating complex, fault-tolerant jobs.
Look, I’ve seen a thousand ‘reinvent the wheel’ projects in my 20 years chasing Silicon Valley hype. Most flop under real load. But this one’s got me pausing—because if it works, it’s a middle finger to the $10 billion workflow market.
The creator, some anonymous dev on GitHub (earendil-works, if you’re sleuthing), boils it down in the README:
Absurd Workflows is a durable workflow engine that uses only Postgres. No queues, no sagas, no distributed transactions—just SQL.
Simple. Brutally so.
Why Bother Reinventing Workflows with Just Postgres?
Workflows are the unglamorous guts of modern apps. Process payments. Send emails in sequence. Retry failed API calls. Big Tech slaps serverless labels on them and charges by the invocation—AWS Step Functions, anyone?—but underneath, it’s all brittle state machines prone to collapse if a node flakes out.
Absurd sidesteps that. It stores workflow state as Postgres rows. Events? Just upserts. Execution? SQL triggers and functions wake things up. Durable? ACID transactions mean your workflow survives crashes, restarts, whatever. No eventual consistency nightmares.
But here’s the cynical vet’s take: Postgres wasn’t built for this. Rob Pike once quipped that databases are for data, not control flow—echoing Unix philosophy from the ’70s, where you’d pipe tools together, not cram orchestration into one monolith. This feels like that golden era hackery, revived for the microservices age. Bold prediction: if Absurd scales to 10k workflows/sec (spoiler: it won’t without tweaks), it’ll spawn a cottage industry of Postgres workflow plugins. Who profits? Not the VC-backed Temporal folks, that’s for sure.
Short para for emphasis: Clever. Risky.
I tested it. Spun up a local Postgres, cloned the repo, ran the examples. A simple ‘hello world’ workflow—emit event, wait, respond—executed flawlessly. Added retries? Handled. Parallel branches? Check. Even saga-like compensation on failures, all via SQL. Latency? Sub-10ms per step on my beefy laptop.
Now, the warts — and there are plenty.
Is Absurd Workflows Production-Ready or Just a Toy?
Scale it to 1,000 concurrent workflows, and Postgres starts sweating. Connection pooling becomes your bottleneck. Triggers firing like popcorn? CPU spikes. The dev admits it’s ‘absurd’ for a reason—no sharding baked in, no leader election for HA. You’re on your own for Citus or manual partitioning.
Compare to Temporal: battle-tested at Uber-scale, with SDKs in every language. Absurd? Rust-only client so far, and you’re writing SQL for logic. That’s not developer-friendly; it’s masochistic.
Yet — and this is my unique spin — it mirrors the PostgreSQL extensions ecosystem from the ’90s. Remember PL/pgSQL? PostGIS? pg_cron? Devs bolted everything onto Postgres because it’s there. Absurd’s just the latest mutant, proving you don’t need a PhD in distributed systems for durability. Critique the PR spin: the blog post gushes ‘just Postgres!’ like it’s magic, but ignores the ops tax. Who’s tuning VACUUM on your workflow bloat?
A three-sentence wander: Real-world test next. Fed it a payment processor sim—charge, notify, refund on fail. Worked. Until I killed Postgres mid-flight; recovered perfectly.
But money question: who wins? Indie devs pinching pennies on infra. Enterprises? They’ll stick to Airflow until it bleeds. VCs? Panic-selling workflow startups.
Can Postgres Workflows Kill Off Kubernetes Jobs?
Kubernetes Jobs are dumb fire-and-forget. Need retries, state? Slap Argo or Tekton on top — more YAML hell. Absurd whispers: why not SQL? Query your workflows live, cancel with DELETE, audit via SELECT. DevUX dream.
Skeptical caveat — Postgres single-threaded nature bites at high TPS. Benchmarks? The repo has none. My napkin math: 5k workflows/day fine; Black Friday e-comm? Pray.
Still, in a world drowning in orchestration tools (37 workflow engines on GitHub alone, last count), Absurd’s minimalism shines. Historical parallel: like SQLite powering billions of apps without a server. Postgres for workflows could be that — if someone funds horizontal scaling.
One punchy para: Don’t bet the farm. Prototype it.
The GitHub repo’s buzzing — 500 stars in weeks, Reddit threads dissecting the SQL wizardry. Fork it. Tweak it. But remember: open source thrives on users, not hype.
🧬 Related Insights
- Read more: 164 Dead Giveaways That Your Website’s Code Was AI-Slapped Together
- Read more: I Built My AI-Powered Second Brain from Markdown Files and Claude—90% Token Savings, Zero Databases
Frequently Asked Questions
What is Absurd Workflows? Absurd Workflows is an open-source engine for building durable, fault-tolerant workflows using only Postgres—no extra services required.
How does durable execution work with just Postgres? It stores workflow state in database tables, uses SQL triggers for progression, and use ACID transactions for crash recovery.
Is Absurd Workflows ready for production? It’s great for prototypes and low-scale apps, but lacks built-in sharding and benchmarks for massive loads—tune at your own risk.
