4 ms·
They avoided all those pesky distributed systems problems by making a system that is not distributed. Hell of a claim.
by jeffbee 4mo ago
They avoided all those pesky distributed systems problems by making a system that is not distributed. Hell of a claim.
- brandur 4mo agoBlake wrote a nice page on the benefits of using transactional-based enqueuing here: https://riverqueue.com/docs/transactional-enqueueing 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 4mo agoDBOS 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-your-data https://www.dbos.dev/blog/co-locating-workflow-state-with-yo...
- jeffbee 4mo agoI 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 4mo agoWell 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.