```markdown
1. PostgreSQL as the backbone for queues & durable workflows
"Continuously amazed by what you can do with few tools, as long as Postgres is a part of your toolkit." – sgt
"I used SKIP LOCKED so that workers can compete safely." – sgt
"Advisory locks are preferred for this anyways because holding a lot of SELECT FOR UPDATE doesn’t scale too well." – bootsmann These snippets show a strong preference for leveraging PostgreSQL primitives (SKIP LOCKED, advisory locks, pgmq/pgflow) to implement reliable queues without adding separate services.
2. Temporal’s scalability and cost concerns
"If you're doing anything non‑trivial (say, 200+ events/workflow) and you need to run only a couple hundred of them concurrently all day, you're going to spend millions on infra, and it's still going to absolutely suck." – temporal_thr123
"Temporal is, in my opinion having run it in prod for over a year – poorly designed, slow and ridiculously heavy infra wise." – temporal_thr123
"We run many hundreds of thousands of these a day... Temporal was a bad fit for us, and we regret it deeply." – temporal_thr321
The community repeatedly flags Temporal’s heavy infrastructure requirements, steep price at scale, and operational pain.
3. Alternatives & trade‑offs (DBOS, pgflow, pgmq, absurd, etc.)
"PgFlow is pretty awesome for DAG workflows – it's built on pgmq (which does the heavy lifting, making it backend agnostic)." – cpursley
"If you don’t need a ton of throughput I thinkabsurd(and our Rust derivativedurable) are very nice options that keep the client side extremely simple." – vrm
"All you need is Postgres until you scale into TBs of data. The main benefit is centralizing all the data in one place so we don’t need to worry about copying data in between multiple systems." – hmaxdml
These points capture the ongoing debate: stay within PostgreSQL for many use‑cases, but consider dedicated alternatives like DBOS, pgflow, or absurd when specific limitations arise.