They avoided all those pesky distributed systems problems by making a system that is not distributed. Hell of a claim.

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.

	▲	jedberg 2 days ago \| parent \| next [-]
		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...
	▲	jeffbee 2 days ago \| parent \| prev [-]
		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.

▲

havercosine 2 days ago | parent | prev [-]

Well spotted but I don’t think it’s bad trade off. A beefy postgres instance (with standby configured), couple of worker nodes running dbos / river directly as a library backed by same db . This system can go surprisingly far.

I’ve seen and used airflow , spark , temporal for many systems. I’d def pick this simpler choice for 95% workloads these days.