Kafka vs PostgreSQL as Queue

Not every system needs a dedicated message broker. PostgreSQL can serve as a task queue using SELECT ... FOR UPDATE SKIP LOCKED, and for many workloads, this is the right choice. Kafka is necessary when you outgrow what a database can handle.

The PostgreSQL Queue Pattern

The pattern is simple: create a jobs table, insert rows as tasks, and have workers poll with SELECT * FROM jobs WHERE status = 'pending' ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED. The SKIP LOCKED clause lets multiple workers dequeue concurrently without conflicts.*

This approach gives you:

• Transactional consistency: Enqueue a task in the same transaction that writes business data
• No new infrastructure: If you already run PostgreSQL, you have a queue
• ACID guarantees: No message loss, no duplicates (within a transaction)

When PostgreSQL Breaks Down

PostgreSQL queues struggle at scale. Table bloat from frequent inserts and deletes requires aggressive vacuuming. High contention on the jobs table creates lock pressure. At thousands of messages per second, you will see degraded query performance across the entire database.

The Transactional Outbox Advantage

The strongest argument for PostgreSQL-as-queue is the transactional outbox pattern. When you need to write to a database AND publish an event atomically, PostgreSQL lets you do both in one transaction. With Kafka, you need CDC tools like Debezium to capture outbox table changes — adding complexity.

Decision Framework

Start with PostgreSQL if your throughput is under ~1,000 messages/second and you value stack simplicity. Move to Kafka when you need replay, horizontal scaling, or stream processing. This is a common system design interview discussion point — showing you know when NOT to use Kafka demonstrates maturity.