Blake wrote a nice page on the benefits of using transactional-based enqueuing here:

https://riverqueue.com/docs/transactional-enqueueing

It's true that it's not distributed, but there are a lot of benefits to not going distributed immediately, like extremely predictable data consistency. I would hazard to guess that the _vast_ majority of apps that are not built by the superscalers are already using a database like Postgres or SQLite to store their data, and River merely suggests that you hook your job queue into the database that you already have.

DBOS recently wrote a great blog post about why you should colocate your workflow data with your application data:

https://www.dbos.dev/blog/co-locating-workflow-state-with-yo...

I just think it's an odd line of argument. The system also avoids most if not all of the pitfalls of hydroponic cultivation. Because it categorically is not that.