// the find
riverqueue/river
Fast and reliable background jobs in Go
River is a Postgres-backed background job library for Go that leans hard into transactional enqueueing — you insert jobs inside your existing transactions, so they only exist if the transaction commits. It's the Go equivalent of Oban (which it openly credits) and is aimed at teams already running Postgres who don't want to add Redis or a separate queue service.
Transactional enqueueing is the real differentiator: a job enqueued in a failing transaction disappears automatically, eliminating a whole class of phantom-job bugs. The driver abstraction is genuinely thought through — pgx v5, database/sql, and SQLite are all supported, and the interface is clean enough that adding another isn't a heroic effort. Test helpers are first-class, not an afterthought; you can assert job insertion in unit tests without spinning up a worker. The resumable job primitives (cursor support, step transactions) show someone actually thought about long-running data migration jobs, not just fire-and-forget tasks.
The Go module layout is a mess of nested go.mod files — riverdriver, rivershared, rivermigrate, and the SQLite driver are all separate modules, which means version pinning across a monorepo and dependency upgrades are more painful than they should be. SQLite support is available but clearly a second-class citizen; the notification outbox approach it uses is a workaround for SQLite's lack of LISTEN/NOTIFY and will have different reliability characteristics that aren't well-documented. Cross-language support (Python, Ruby) only covers insertion, not workers, so if your job producers are polyglot you're fine, but you can't write a worker in anything other than Go. The Web UI is a separate repo with its own release cycle, meaning UI and library versions can drift.