zlacker

> You need a table with a primary id and a "status" field.

For a queue, you need a table with an insertion order and a status indicator. “Primary id” is not enough because “primary id” may not be ordered (e.g., a UUID primary key is a primary id.)

OTOH, while a DB can do this, therr are plenty of well-tested open source purpose built message queueing solutions, so the swt of scenarios where “roll your own with a DB” isn’t a misuse of effort is limited.

>>dragon+(OP)
Why on earth would you make a queue table with a non-serial primary key? What benefit do you gain from a UUID here?