Recall.ai's engineers write about scaling problems from running a meeting-recording API, including Postgres, Linux, WebSockets, and Chromium.
HN commenters cite its Postgres LISTEN/NOTIFY scaling post, which got fixed in Postgres core, and discuss the Postgres performance cliffs it describes.
Your version makes sense. I understood the OP's approach as being different.
Two (very, if indexed properly) short transactions at start and end are a good solution. One caveat is that the worker can die after t1, but before t2 - hence jobs need a timeout concept and should be idempotent for safe retrying.
This gets you "at least once" processing.
> this obviously has the drawback of knowing how long to sleep for; and tasks not getting "instantly" picked up, but eh, tradeoffs.
Right. I've had success with exponential backoff sleep. In a busy system, means sleeps remain either 0 or very short.
Another solution is Postgres LISTEN/NOTIFY: workers listen for events and PG wakes them up. On the happy path, this gets instant job pickup. This should be allowed to fail open and understood as a happy path optimization.
As delivery can fail, this gets you "at most once" processing (which is why this approach by itself it not enough to drive a persistent job queue).
A caveat with LISTEN/NOTIFY is that it doesn't scale due to locking [1].
[1]: https://www.recall.ai/blog/postgres-listen-notify-does-not-scale
I want an app that uses the accessibility API to plug into Meta, Snap, etc and gives you full control over your socials ala Recall using LLMs. I feel like Gen AI is the countermeasure to closed social ecosystems trying to treat you as the product. Ingest everything my social users have access to, and let me control the experience (Recall meets Buffer?).
Scraping is old and busted, consuming the firehose available to you and controlling consumption of it on your own terms is the new hotness.
https://www.recall.ai/
https://learn.microsoft.com/en-us/windows/ai/apis/recall
Running a high-scale postgres in production is fraught. We have a really demanding workload and have hit a lot of undocumented performance cliffs. Most of these stem from fundamental design flaws in postgres [0][1].
I'm glad to see projects like this trying to using new tools to improve upon these deeply rooted issues that was just not practical even 12-18 months ago. This is really ambitious and I'm excited to see where this goes!
[0] https://www.recall.ai/blog/postgres-postmaster-does-not-scale
[1] https://www.recall.ai/blog/postgres-listen-notify-does-not-scale
This is largely because LISTEN/NOTIFY has an implementation which uses a global lock. At high volume this obviously breaks down: https://www.recall.ai/blog/postgres-listen-notify-does-not-scale
None of that means Oban or similar queues don't/can't scale—it just means a high volume of NOTIFY doesn't scale, hence the alternative notifiers and the fact that most of its job processing doesn't depend on notifications at all.
People say you don’t need Redis, you can just use Postgres LISTEN/NOTIFY. I read a blog post about it locking the entire database and causing problems[0]. Apparently it’s fixed now but this only just being discovered in 2025 doesn’t give me confidence it’s battle tested for prod.
At some point shoving everything into Postgres is an anti pattern too.
[0]: https://www.recall.ai/blog/postgres-listen-notify-does-not-scale
It did fix the original "Postgres LISTEN/NOTIFY does not scale" [1] post's problem though, which was mentioned in an update of that article:
Update: Fixed in Postgres core
This commit has eliminated the bottleneck in the postgres core.
Credit to Joel Jacobson and the core postgres contributors for resolving this.
[1] https://www.recall.ai/blog/postgres-listen-notify-does-not-scale