← All build notesENGINEERING NOTE / OCTOBER 10, 2026

A queue without another service.

Why CloudCrew keeps task state in PostgreSQL—and what that does not guarantee.

  1. 01Submit
  2. 02Durable row
  3. 03Lease + fencing token
  4. 04Persist result

CloudCrew already needs durable task history. Using PostgreSQL for the queue keeps the claim, lifecycle state, and result close together instead of introducing another service just to coordinate work. SKIP LOCKED lets available workers claim different rows without waiting on one another.

A lease gives a stopped worker's task a path back into circulation. A fencing token prevents an old attempt from overwriting the new attempt's saved result. Recovery and stale-write protection solve different problems; both matter.

This is still at-least-once execution. A worker can make an external call and crash before persisting the result. Fencing a database write cannot undo that call. Owner-scoped idempotency and careful side-effect design remain important.

The useful next question is not whether a message broker would look more impressive on a diagram. It is where contention, operational needs, or measured throughput justify the additional complexity. The repository's local benchmarks identify the API bottleneck; they are not proof of linear worker scaling.

Based on the documented implementation and recorded artifacts—not an independent audit. Read the repository source ↗

Explore the full case study ↗