At 3 am the pager is activated. Your queue is backed up, your database is on fire, and those two facts are the same fact. This is the trap nobody warns you about when they advise you to simply utilize Postgres for all your needs.
The hype has a new victim
The simple advice, "Just use Postgres" was very effective in the beginning. You didn't need a complex architecture involving six different services. It was enough to deploy the common monolith and you could rest at night. After that, the hype got out of control. Nowadays, individuals place their message queue directly into the database used by their customers. I see why people find it attractive. SELECT ... FOR UPDATE SKIP LOCKED allows you to reserve jobs with zero new infrastructure. No brokers, no ops, just one line of code. You just hid it inside your most critical, least replaceable component.
MVCC was not built for this
The downside you may encounter later on is that Postgres creates a new row for every update, but that's the nature of MVCC.
