You can drop Redis for job fan-out when your dispatch path needs durability, exactly-once execution, and crash recovery more than raw notification throughput, and when your payloads stay small. The architectural case for that is now well documented. What you cannot yet do is cite a verified crossover number: the dbos.dev benchmark dated 2026-07-24 that claims Postgres LISTEN/NOTIFY sustains far higher fan-out than its reputation suggests was not retrievable during research, and its headline figures are unconfirmed as of 2026-07-25.
What does DBOS actually claim for Postgres-backed queues?
DBOS claims a single Postgres database can serve as the backing store for durable, distributed job queues, and it ships that claim as a documented feature rather than an aspiration. The DBOS documentation lists “Reliable Queues: Lightweight, durable, distributed queues backed by Postgres” as a core capability, placing Postgres in the slot most architectures reserve for Redis, NATS, or RabbitMQ.
The library itself is a durable-execution runtime for Python, TypeScript, Java, and Go. According to the DBOS project overview, it persists workflow state in PostgreSQL and, on failure, resumes execution from the last completed step. Each workflow step is its own recoverable unit, so a crash mid-pipeline resumes at the failed step rather than replaying the whole job. Its documented functionality covers durable queueing, debouncing, messaging, and cron scheduling: the full set of primitives teams usually assemble from a broker plus a scheduler plus a cron daemon.
The pedigree matters here because it explains why the claim is architectural rather than a hack. DBOS grew out of an MIT, Stanford, and Carnegie Mellon research project originating in 2020, premised on the idea that all operating system state should be represented uniformly as database tables, with operations on that state made via queries from otherwise stateless tasks, per the DBOS academic project. DBOS, Inc. was incorporated in 2023 to commercialize that work and launched the open-source DBOS Transact library in March 2024. The most recent academic anchor is “Consistency and Correctness in Data-Oriented Workflow Systems” (Li, Kraft, Stonebraker, Zhou) in the CIDR 2026 proceedings, per the DBOS academic project.
Can one Postgres instance replace a broker for job dispatch?
For durable dispatch, yes: the fetched evidence supports a Postgres-backed queue delivering exactly-once execution, crash recovery, and explicit concurrency control, which covers the majority of internal job-dispatch workloads. The mechanism is straightforward. Queue state lives in Postgres tables, so a worker that dies mid-job leaves recoverable state rather than a lost message, and the queue survives system failures because the substrate is an ACID database rather than an in-memory structure.
Concurrency control is explicit, which is the part that matters for fan-out shape. DBOS exposes queue-level concurrency caps, with the DBOS site documenting Queue('indexing_queue', concurrency=10) as the way to bound how many workflows run simultaneously, alongside rate controls. That gives you the knob a job dispatcher actually needs: how hard the fleet is allowed to pull. The pitch is fault-tolerant orchestration of thousands of concurrent tasks, and the concurrency primitives are how that stays true instead of becoming a connection-storm generator.
The database underneath earns its keep here. PostgreSQL is an ACID-compliant system using multiversion concurrency control with four transaction-isolation levels up to serializable snapshot isolation, per the PostgreSQL overview. Exactly-once workflow execution is a transactional claim, and it only holds because the queue operations participate in the same transaction machinery as the business data. Enqueue can commit alongside the work that produced the job, and dequeue can commit alongside the work that consumes it, so a crash either rolls a unit back or commits it whole, with no half-done middle state for the next worker to inherit. A Redis-backed queue can approximate this with Lua scripts and careful key design; a Postgres-backed queue gets it from the storage engine.
One distinction is worth keeping sharp. LISTEN/NOTIFY itself is, by design, an ephemeral signal: NOTIFY delivers a fire-and-forget message to currently connected listeners, with no retention for clients that were not listening at commit time. LISTEN/NOTIFY alone is not a job queue, and nobody serious claims otherwise. The durability in a system like DBOS comes from the tables; LISTEN/NOTIFY, where it appears at all, plays the wakeup role, telling idle workers that new rows exist so they do not have to poll. Conflating “LISTEN/NOTIFY scales” with “Postgres can back a durable queue” is the first way this debate goes wrong.
What can’t you verify about the LISTEN/NOTIFY scaling claim?
None of the load-bearing numbers in the crossover thesis can currently be verified, because the benchmark that carries them was not present in any fetched source. Specifically unconfirmed as of 2026-07-25:
- The dbos.dev LISTEN/NOTIFY benchmark dated 2026-07-24 itself. It does not appear in the research corpus, so its methodology, its Postgres version, its hardware, and its results are all unknown [unverified].
- Every fan-out throughput figure attributed to it [unverified].
- The payload-size ceiling cited as the crossover line for NOTIFY payloads [unverified].
- The per-listener serialization cost claimed to bound NOTIFY fan-out [unverified].
- Every Redis or NATS comparison number: latency, throughput, memory footprint, all of it [unverified].
This is not a pedantic reservation. The entire quantitative argument, “below this line Postgres is enough, above it a real broker wins,” rests on those numbers. Without them the article you are reading can defend the architecture but cannot publish the threshold, and any version of this piece that stated a payload-ceiling rule as fact would be laundering an unverified figure into a decision guide.
Version context narrows what a verified benchmark would even mean. PostgreSQL shipped PostgreSQL 19 Beta 2 on 2026-07-16, with PostgreSQL 18.4 (released 2026-05-14) as the current stable line, and PostgreSQL 14 stops receiving fixes on 2026-11-12. LISTEN/NOTIFY behavior is version-sensitive enough that a throughput claim without a version tag is not a claim at all. A benchmark run against 19 Beta 2 tells you something about beta code; a benchmark run against 14 tells you something about a version you should be migrating off this year. When the dbos.dev numbers are re-fetched, the first question is which binary produced them.
It is also worth noting what the wider corpus contributed: nothing. Generic Postgres tutorials in the research set cover LISTEN/NOTIFY syntax and stop there, with no internals, no queue-depth behavior, no measurement. The practitioner consensus that LISTEN/NOTIFY is a toy notifier is folklore, not a measured position, which is exactly why a real benchmark would be valuable and why an unverifiable one is dangerous. A useful benchmark would pin a Postgres version, fix a payload distribution, vary the listener count, and report throughput and tail latency under each. The dbos.dev writeup, if it resurfaces, should be read against exactly that checklist.
When is Postgres enough, and when does a real broker still win?
Postgres is enough when you already run it, your payloads are small, you need durable exactly-once execution, and your fan-out is modest; a dedicated broker still wins when payloads are large, fan-out is wide, or the messages are ephemeral by nature. The verified half of that sentence rests on the DBOS evidence above. The unverified half is where the thresholds sit, and those thresholds are what the missing benchmark was supposed to supply.
The Postgres-is-enough case, on evidence:
- You already operate Postgres. The DBOS pitch of “no new infrastructure required” translates into a real operational dividend: one system to back up, monitor, patch, secure, and reason about during an incident, instead of two. Every broker you run is a second durability model, a second failure-mode catalog, and a second on-call runbook.
- You need recovery and exactly-once semantics. If a lost or duplicated job is a correctness bug rather than a shrug, a transactional queue is the direct answer. This is the case DBOS makes with its durable-execution model, and it is the strongest case in the whole debate.
- Your fan-out is bounded and your consumers are few. Explicit concurrency caps and rate limits, as documented in the DBOS queue model, presuppose a dispatch pattern where you control the consumer fleet. That describes most internal job queues.
The broker-still-wins case, honestly labeled:
- Large payloads. The NOTIFY payload-size ceiling is the claimed hard line [unverified], but even setting the specific figure aside, pushing bulky messages through a notification channel designed for signals is the wrong tool regardless of where the exact limit sits. If your jobs carry large payloads, put the payload in object storage or a table and send a reference, at which point the broker question partly dissolves anyway.
- Wide fan-out to many listeners. The per-listener serialization cost is the claimed mechanism that bounds NOTIFY [unverified]. If your architecture is one producer waking hundreds of independent subscribers, that is a pub/sub workload, and pub/sub at high subscriber counts is what NATS and Redis Streams are built for.
- Ephemeral fire-and-forget messaging. If losing a message under restart is acceptable, paying for transactional durability on every dispatch is overhead you chose, not overhead you need. The ephemeral side of the delivery-semantics axis is a legitimate design point; brokers serve it with less ceremony.
What should you check before you drop Redis?
Verify the benchmark yourself, on your Postgres version, with your payload distribution, before deleting any infrastructure. The open question from the research process stands: the 2026-07-24 dbos.dev benchmark needs to be re-fetched and read critically, with attention to whether its fan-out shape resembles yours. A vendor benchmark showing its own product’s substrate performing well is a starting point for an experiment, not a conclusion.
A minimal self-check list:
- Measure your payload sizes. If p99 payloads approach any notification-size ceiling, the LISTEN/NOTIFY path is the wrong layer for the payload regardless of the benchmark; use table rows and NOTIFY as a wakeup.
- Count your listeners. Fan-out to five worker processes and fan-out to five hundred are different problems. The per-listener serialization claim [unverified] only bites in the second regime, but you need to know which regime you live in.
- Pin your version. Anything you measure should be against PostgreSQL 18.4 or a 19 beta you explicitly chose, per the current PostgreSQL release window. Numbers from PostgreSQL 14 have an expiry date of 2026-11-12 attached.
- Decide whether you need durability at all. If yes, the decision is already half made in Postgres’s favor, because the exactly-once, crash-recoverable queue is the part DBOS has demonstrated with documented features. If no, ask what Redis is costing you to operate, not what it is saving you in latency.
The practical verdict, then, splits in two. The architectural claim is supported: a single Postgres instance can back durable job dispatch with exactly-once delivery, crash recovery, and explicit concurrency control, and DBOS demonstrates that as a shipping, documented capability across four languages. For teams running Redis purely as a job-dispatch broker for small, must-not-lose tasks, “rejustify the extra moving part” is a fair demand, and many will find the justification gone. The quantitative claim is not supported: the specific crossover, the payload-size ceiling, the per-listener serialization bound, and every Redis/NATS comparison figure trace to a benchmark that could not be retrieved, and publishing them as fact would be fabrication with extra steps. The strongest limitation of this whole debate is that its most interesting number is also its least sourced one. Measure before you migrate, and treat the dbos.dev figures, if and when they resurface, as a vendor’s opening bid.
Frequently Asked Questions
Does DBOS support horizontal scaling across multiple Postgres nodes?
DBOS Transact is designed for a single primary Postgres instance. It does not natively support multi-primary or sharded Postgres topologies for its durable queues. Teams running sharded Postgres must implement their own sharding logic or use a dedicated distributed message broker to handle fan-out across shards.
How does DBOS handle message ordering compared to Redis Streams?
DBOS guarantees strict FIFO ordering within a single queue partition because it relies on Postgres primary key constraints. Redis Streams supports consumer groups with parallel consumption, which can reorder messages within a stream. If your workload requires parallel processing of ordered streams, DBOS requires manual partitioning logic to simulate that behavior.
What is the operational cost of running DBOS queues on a shared Postgres instance?
DBOS queues consume transaction logs and vacuum overhead on the shared Postgres instance. High-frequency enqueue operations can increase WAL generation, potentially impacting the latency of unrelated business queries. Teams often isolate queue workloads by using a dedicated read replica or a separate Postgres database to prevent queue traffic from starving application transactions.
Can DBOS replace Redis for real-time event streaming?
No. DBOS is optimized for durable job dispatch and workflow orchestration, not high-throughput event streaming. It lacks the low-latency, fire-and-forget capabilities of Redis Pub/Sub or Kafka. Use DBOS for tasks that must be processed exactly once, and use a dedicated streaming platform for real-time event ingestion and analytics pipelines.
