zlacker

>>hyzyla+(OP)
This seems a bit silly. We might be able to use only postgres, but this seems harder than using Postgres and Redis.

Any time someone says ‘this works for small workloads’ I hear, ‘we’ll eventually have to migrate this’.

That’s not a problem if you are talking about introducing a hugely complex piece of infrastructure, but Redis is hardly that.

>>Aeolun+z3
Or don't use Postgres to begin with. The reason you need to SELECT FOR UPDATE is because Postgres doesn't implement READ UNCOMMITTED. If you're implementing an ordered queue, you have no way of reliably getting the next page of queue items without taking a lock using SELECT FOR UPDATE because there may be pending uncommitted transactions that you need to block on. On MySQL and SQL Server you can compare counts computed with READ UNCOMMITTED and READ COMMITTED (on MSSQL, with snapshot isolation) to quickly figure out whether there are any uncommitted transactions in the range without taking a lock. That being said, SELECT FOR UPDATE and UPDLOCK equivalents are the easiest to get right, and if you need higher throughput you probably need a message queue or Kafka-equivalent.