Top all-time · #4660
River
Company blog · riverqueue.com/blog · on HN as bgentryprogrammingsystems
River is the company blog at riverqueue.com, writing about programming and systems. Since 2024, 17 different Hacker News readers have linked it 28 times, most often “River Queue”. No feed was found, so read it on the site itself.
Too few sampled comments (9) to say how often HN recommends it.?
Why HN links it
HN readers link River's docs for its Go job queue on Postgres, including benchmarks, transactional enqueueing, and the Pro workflows page. Most comments compare River to other queues.
Summarised by Claude from a sample of 9 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Atomic, transaction-safe job queueing for Go, Java, Ruby, Rust, and TypeScript. Backed by Postgres or SQLite and built to scale.
Most-linked posts?
- River Queue6 people · 6 mentions · first linked 2024-02-10
- /docs/transactional-enqueueing3 people · 3 mentions · first linked 2025-05-11
- Fast and reliable background jobs in Go2 people · 3 mentions · first linked 2024-07-03
- Private Go proxies: How they work and why it matters2 people · 2 mentions · first linked 2025-09-06
What Hacker News says?
How does this compare to River Queue ( https://riverqueue.com/ )? Besides the additional Python and TS client libraries.
Comment linking /
on “Show HN: Hatchet – Open-source distributed task queue”Submitted Building an idempotent email API with River unique jobs as a story · 33 points
HN discussionRiver ( https://riverqueue.com ) is a Postgres background job engine written in Go, which also has insert only clients in other languages. Currently we have these for Ruby and Python: https://github.com/riverqueue/riverqueue-ruby https://github.com/riverqueue/riverqueue-python
Comment linking /
on “Show HN: PgQueuer – Transform PostgreSQL into a Job Queue”Submitted Private Go proxies: How they work and why it matters as a story · 5 points
HN discussionI'm curious how this performs compared to River https://riverqueue.com/ https://news.ycombinator.com/item?id=38349716
Comment linking /
on “Show HN: An SQS Alternative on Postgres”Submitted Fast and reliable background jobs in Go as a story · 4 points
HN discussionDeveloper of River here ( https://riverqueue.com ). I'm curious if you ran into actual performance limitations based on specific testing and use cases, or if it's more of a hypothetical concern. Modern Postgres running on modern hardware and with well-written software can handle many thousands or tens of thousands of jobs per second (even without partitioning), albeit that depends on your workload, your tuning / aut…
Comment linking /
on “Show HN: Hatchet v1 – A task orchestration platform built on Postgres”Submitted River UI as a packaged Go module as a story · 3 points
HN discussionAnd in Go you’ve got River: https://riverqueue.com/
Comment linking /
on “Postgres as queue”Submitted River: Launching Workflows and River Pro as a story · 3 points
HN discussionDefinitely not! Jobs in River are enqueued and fetched by worker clients transactionally, but the jobs themselves execute outside a transaction. I’m guessing you’re aware of the risks of holding open long transactions in Postgres, and we definitely didn’t want to limit users to short-lived background jobs. There is a super handy transactional completion API that lets you put some or all of a job in a transaction if…
Comment linking /docs/transactional-job-completion
on “An Introduction to Solid Queue for Ruby on Rails”Submitted River UI as a story · 3 points
HN discussionvery interesting and TIL about the project, thanks for sharing. What DB is River Queue for 46k jobs/sec ( https://riverqueue.com/docs/benchmarks ) UPDATE: I see its PG - https://riverqueue.com/docs/transactional-enqueueing
Comment linking /docs/transactional-enqueueing
on “An Introduction to Solid Queue for Ruby on Rails”Submitted Migration fatigue, and how LLMs help us avoid it as a story · 2 points
HN discussionYou can get pretty high job throughput while maintaining transactional integrity, but maybe not with Ruby and ActiveRecord :) https://riverqueue.com/docs/benchmarks That River example has a MacBook Air doing about 2x the throughput as the Sidekiq benchmarks while still using Postgres via Go. Can’t find any indication of whether those Sidekiq benchmarks used Postgres or MySQL/Maria, that may be a difference.
Comment linking /docs/benchmarks
on “An Introduction to Solid Queue for Ruby on Rails”Submitted The evolution of background job frameworks in Ruby as a story · 2 points
HN discussionI recently started using this DBOS in Go and it’s been good. https://github.com/dbos-inc/dbos-transact-golang I have River on my list to try someday too https://riverqueue.com/pro
Comment linking /pro
on “Show HN: Stepped Actions – distributed workflow orchestration for Rails”Submitted Private Go proxies: How they work and why it matters as a story · 2 points
HN discussionPostgres can definitely handle a lot of use cases; background job scheduling always had me tempted to reach for something like rabbitmq but so far happy enough with riverqueue[0] for Go projects. [0]: https://riverqueue.com/
Comment linking /
on “It's 2026, Just Use Postgres”Submitted SQLite for River, durable periodic jobs and dbsql for Pro, better performance as a story · 2 points
HN discussionYeah, River generally recommends this pattern as well (River co-author here :) To get the benefits of transactional enqueueing you generally need to commit the jobs transactionally with other database changes. https://riverqueue.com/docs/transactional-enqueueing It does not scale forever, and as you grow in throughput and job table size you will probably need to do some tuning to keep things running smoothly. But af…
Comment linking /docs/transactional-enqueueing
on “I Love You, Redis, but I'm Leaving You for SolidQueue”Submitted River Queue as a story · 2 points
HN discussionthe problem i see here is that we end up treating the background job/task processor as part of the production system (e.g. the server that responds to requests, in the case of a web application) instead of a separate standalone thing. rails doesn’t make this distinction clear enough. it’s okay to back your tasks processor with a pg database (e.g. river[0]) but, as you indirectly pointed out, it shouldn’t be the same…
Comment linking /
on “I Love You, Redis, but I'm Leaving You for SolidQueue”Submitted Designing River's hooks and middleware for change resistance and extensibility as a story · 2 points
HN discussionBlake 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…
Comment linking /docs/transactional-enqueueing
on “Rive, Fast and reliable background jobs in Go”Submitted Dependabot and private Go proxies: how they work and why it matters as a story · 1 points
HN discussionHow does it compare to a full-fledged durable execution platform like DBOS[0], which follows the same philosophy? Looks like River does have workflows, but it's locked behind Pro [1]. [0] https://dbos.dev [1] https://riverqueue.com/docs/pro/workflows
Comment linking /docs/pro/workflows
on “Rive, Fast and reliable background jobs in Go”
