A really short piece (point form) on the Postgres subtransactions and exorcizing them from River. Written in part to remind myself why they're so prone to causing performance issues in the first place. riverqueue.com/blog/subtrans…

Huge River ship (biggest ever?): River, the polyglot queue. We've transliterated the project to Rust, TS, and Ruby and refined implementation and APIs endlessly. The result is the full River core, rewritten from the ground up. No Go dependency required. riverqueue.com/blog/polyglot…

Released River v0.48 + River Pro v0.31, and the fixed section is longer than my screen. This is a hardening release with only a couple new features, but we did add Yugabyte support. That's fun. github.com/riverqueue/river/…

Short post on a recent River story — A new feature (active job rescue) was about to significantly degrade perf on one of our queries. The most obvious fix was to add a new index, and a year ago we would've done just that, shipping a new migration, and that would be that. Today, instead of doing so right away, @blakegentry had Codex experiment with alternative query shapes and try to iterate to something more performant. LLM-as-laboratory. It worked! Use a MATERIALIZED CTE + multi-field join yielded up to 130x improvement compared to the first stab. Great perf meant no new migration which meant considerably less upgrade pain for users. Longer term, less pain → more users as fewer churn. Anyway, without further ado, Migration fatigue, and how LLMs help us avoid it: riverqueue.com/blog/migratio…

River Pro v0.26 ships today with active job rescue: • Jobs may become orphaned if the process running them crashes with no opportunity for graceful stop that'd set them back to available. • Traditional job rescue compares job timeout to job start time, adding a safety margin, and rescuing anything that should be finished. • River Pro tracks live clients/queues in an UNLOGGED table (no added WAL pressure) that's frequently heartbeated. • Active job rescue rescues any running jobs in a client/queue that's not reporting, reducing rescue delay from hours to minutes.

River road map for the next couple weeks: • Metrics [shipped] • Pro: Active job rescue • Turso support • Pro: Rate limiting More nebulous after that. Two that are working but I'm not sure about: • MySQL support • Pro: SQLite support Anyway, keep me accountable lol.

River workflows V2: 6+ month project, it's the biggest revision to River ever: • 60% faster throughput. • Backlogs drained 20x faster. • Wait on arbitrary OOB signals. • Workflow timers. • Wait expressions (CEL). e.g. `approval_received || timeout`. riverqueue.com/blog/river-pr…

Put together a post on some of the history of job queues in Ruby and our experience transitioning the Heroku API over the years from Delayed::Job → Queue Classic → Que. Original commits from DJ and Resque were from @tobi and Chris Wanstrath. How cool. riverqueue.com/blog/ruby-que…