A Postgres queue, Amazon SQS or Kafka for background jobs?

The question

Our team of 5 needs a background job system for roughly 3,000 jobs per minute (emails, report generation, webhooks), with retries and scheduling. We already run Postgres and deploy on AWS. Options: a Postgres-backed queue (SELECT FOR UPDATE SKIP LOCKED, for example via a library), Amazon SQS with workers, or Kafka. Which should we pick, and what would make us change our minds?

What each model said

Each answer is the model’s own words, with formatting marks removed.

• Claude Sonnet 5.5

  Pick a Postgres-backed queue (Oban, Graphile Worker, River, or pg-boss, depending on language). 3,000 jobs/min is only ~50/sec, trivial for SKIP LOCKED. You get transactional enqueue (no dual-write bugs), built-in retries, scheduling, and visibility via SQL, with no new infrastructure for a 5-person team. Switch to SQS if sustained load grows ~20x, job tables cause bloat or contention, or you need cross-service decoupling. Kafka only for event streaming/replay needs, not job queues.

• GPT-4.1

  Pick a Postgres-backed queue (using SKIP LOCKED), since you already run Postgres, 3,000 jobs/minute is well within its capacity, and it simplifies ops for a small team. Use a robust library (like que or pg-boss). Switch to SQS or Kafka only if you need much higher scale, multi-region reliability, or decoupling from your database.

• Gemini 3.5 Flash-Lite

  Pick AWS SQS. At 3,000 jobs/minute (~50/sec), Postgres risks connection exhaustion and vacuum bloat under heavy transactional writes. Kafka is massive over-engineering for simple queues without event-streaming needs. SQS natively handles retries, DLQs, scheduling (via delay seconds), scales effortlessly, and requires zero infrastructure management on AWS. Change your mind if: You need complex multi-table transactional consistency between job creation and business data (favor Postgres), or your throughput scales 100x and requires event replay (favor Kafka).

• Grok 4.20

  Pick Postgres-backed queue (SKIP LOCKED). It reuses your existing Postgres, adds zero new services for a 5-person team, and easily handles 50 jobs/sec with retries + scheduling via standard libraries. SQS is viable but unnecessary; Kafka is massive overkill. Change to SQS only if volume exceeds ~15k/min or DB contention becomes measurable.