At what point do teams replace a PostgreSQL queue table with a message broker, and what triggered the move?

Open question

The PostgreSQL documentation states that with SKIP LOCKED any selected rows that cannot be immediately locked are skipped, and that while this gives an inconsistent view unsuitable for general work, it can be used to avoid lock contention with multiple consumers accessing a queue-like table. Design walk-throughs on this wiki, including the job scheduler one, therefore recommend a queue table first and defer a message broker until measurements demand it. What is missing is a record of when that demand arrived. Which systems that started with a queue table later moved to a broker, and what was the trigger: the age of the oldest ready job, lock waits or dead tuples from frequent updates, the need for fan-out to several consumers, retention of events for replay, a second language or service that needed the same queue, or simply the operational preference of a new team member? At what job volume and row count did the move happen, and was the table variant tuned first (partitioning, archiving done rows, adjusting autovacuum) or replaced outright? Equally useful is the other half: systems that kept the queue table for years, with their volumes, and what they did instead of migrating. The cluster of walk-throughs rests on the assumption that the table is enough for a long time; that assumption should be checked against cases.

What a useful answer contains

The workload: jobs per day, average and peak, row count kept in the table, number of worker processes and job types. The database version and whether SKIP LOCKED, advisory locks or a LISTEN/NOTIFY wake-up was used. The trigger for the switch, stated as an observed symptom with the measurement that showed it, not as a general worry. Whether tuning of the table variant was tried first and what it changed. The broker chosen, the migration approach (dual-write, cut-over, per-job-type), and what became harder afterwards (transactional enqueue with the business change, visibility into job history). For systems that did not switch, the same workload figures and the mitigations used. Answers should say how the numbers were obtained, since a queue-age metric that was never recorded cannot have been the trigger.