proxy.golang.org: github.com/riverqueue/river/riverdriver/riverdrivertest

Example_libSQL demonstrates use of River's SQLite driver with libSQL (a SQLite fork). Example_sqlite demonstrates use of River's SQLite driver.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/riverdriver/riverdrivertest#section-documentation
• Licenses: MPL-2.0
• Latest release: (published 9 days ago)
• Last Synced: 2026-01-27T03:23:19.136Z (9 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Stargazers count: 1.186%
  • Forks count: 2.788%
  • Average: 3.641%
  • Dependent packages count: 5.124%
  • Dependent repos count: 5.468%

proxy.golang.org: github.com/riverqueue/river/riverdriver/riversqlite

Package riversqlite provides a River driver implementation for SQLite. It's also tested against libSQL (a SQLite fork), and that should continue to work as long they keep to their commitment in maintaining API compatibility. This driver is currently in early testing. It's exercised reasonably thoroughly in the test suite, but has minimal real world use as of yet. River makes extensive use of internal operations that might run in parallel, which doesn't naturally play well with SQLite, which only allows one operation at a time, returning errors like "database is locked (5) (SQLITE_BUSY)" in case another tries to access it. A good workaround to avoid errors is to set the maximum pool size to one connection like `dbPool.SetMaxOpenConns(1)`. A known deficiency in this driver compared to Postgres is that due to limitations in sqlc, it performs operations like completion and `InsertMany` one row at a time instead of in batches. This means that it's slower than the Postgres driver, especially when benchmarking.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/riverdriver/riversqlite#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.0 (published 23 days ago)
• Last Synced: 2026-01-18T20:05:30.404Z (17 days ago)
• Versions: 11
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 5.432%
  • Average: 5.615%
  • Dependent repos count: 5.797%

proxy.golang.org: github.com/riverqueue/river/rivershared

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/rivershared#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.1 (published 16 days ago)
• Last Synced: 2026-01-27T03:24:07.054Z (9 days ago)
• Versions: 39
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 6.422%
  • Average: 6.639%
  • Dependent repos count: 6.856%

proxy.golang.org: github.com/riverqueue/river/rivertype

Package rivertype stores some of the lowest level River primitives so they can be shared amongst a number of packages including the top-level river package, database drivers, and internal utilities.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/rivertype#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.0 (published 23 days ago)
• Last Synced: 2026-01-18T20:05:22.756Z (17 days ago)
• Versions: 52
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 8.625%
  • Average: 9.176%
  • Dependent repos count: 9.726%

proxy.golang.org: github.com/riverqueue/river/riverdriver/riverpgxv5

Package riverpgxv5 provides a River driver implementation for Pgx v5. This is currently the only supported driver for River and will therefore be used by all projects using River, but the code is organized this way so that other database packages can be supported in future River versions.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/riverdriver/riverpgxv5#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.13.0 (published over 1 year ago)
• Last Synced: 2024-10-29T17:09:37.891Z (over 1 year ago)
• Versions: 66
• Dependent Packages: 1
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 9.472%
  • Average: 10.11%
  • Dependent repos count: 10.747%

proxy.golang.org: github.com/riverqueue/river-licensetest

Package river is a robust high-performance job processing system for Go and Postgres. See homepage, docs, and godoc, as well as the River UI. Being built for Postgres, River encourages the use of the same database for application data and job queue. By enqueueing jobs transactionally along with other database changes, whole classes of distributed systems problems are avoided. Jobs are guaranteed to be enqueued if their transaction commits, are removed if their transaction rolls back, and aren't visible for work _until_ commit. See transactional enqueueing for more background on this philosophy. Jobs are defined in struct pairs, with an implementation of `JobArgs` and one of `Worker`. Job args contain `json` annotations and define how jobs are serialized to and from the database, along with a "kind", a stable string that uniquely identifies the job. Workers expose a `Work` function that dictates how jobs run. Jobs are uniquely identified by their "kind" string. Workers are registered on start up so that River knows how to assign jobs to workers: A River `Client` provides an interface for job insertion and manages job processing and maintenance services. A client's created with a database pool, driver, and config struct containing a `Workers` bundle and other settings. Here's a client `Client` working one queue (`"default"`) with up to 100 worker goroutines at a time: ## Insert-only clients It's often desirable to have a client that'll be used for inserting jobs, but not working them. This is possible by omitting the `Queues` configuration, and skipping the call to `Start`: `Workers` can also be omitted, but it's better to include it so River can check that inserted job kinds have a worker that can run them. ## Stopping The client should also be stopped on program shutdown: There are some complexities around ensuring clients stop cleanly, but also in a timely manner. See graceful shutdown for more details on River's stop modes. `Client.InsertTx` is used in conjunction with an instance of job args to insert a job to work on a transaction: See the `InsertAndWork` example for complete code. Batch job insertion for efficiently inserting many jobs at once using Postgres `COPY FROM`. Cancelling jobs from inside a work function. Error and panic handling. Multiple queues to better guarantee job throughput, worker availability, and isolation between components. Periodic and cron jobs. Scheduled jobs that run automatically at their scheduled time in the future. Snoozing jobs from inside a work function. Subscriptions to queue activity and statistics, providing easy hooks for telemetry like logging and metrics. Test helpers to verify that jobs are inserted as expected. Transactional job completion to guarantee job completion commits with other changes in a transaction. Unique jobs by args, period, queue, and state. Web UI for inspecting and interacting with jobs and queues. Work functions for simplified worker implementation. ## Cross language enqueueing River supports inserting jobs in some non-Go languages which are then worked by Go implementations. This may be desirable in performance sensitive cases so that jobs can take advantage of Go's fast runtime. See developing River. Example_batchInsert demonstrates how many jobs can be inserted for work as part of a single operation. Example_completeJobWithinTx demonstrates how to transactionally complete a job alongside other database changes being made. Example_cronJob demonstrates how to create a cron job with a more complex schedule using a third party cron package to parse more elaborate crontab syntax. Example_customInsertOpts demonstrates the use of a job with custom job-specific insertion options. Example_errorHandler demonstrates how to use the ErrorHandler interface for custom application telemetry. Example_globalHooks demonstrates the use of hooks to modify River behavior which are global to a River client. Example_globalMiddleware demonstrates the use of middleware to modify River behavior which are global to a River client. Example_gracefulShutdown demonstrates a realistic-looking stop loop for River. It listens for SIGINT/SIGTERM (like might be received by a Ctrl+C locally or on a platform like Heroku to stop a process) and when received, tries a soft stop that waits for work to finish. If it doesn't finish in time, a second SIGINT/SIGTERM will initiate a hard stop that cancels all jobs using context cancellation. A third will give up on the stop procedure and exit uncleanly. Example_insertAndWork demonstrates how to register job workers, start a client, and insert a job on it to be worked. Example_jobArgsHooks demonstrates the use of hooks to modify River behavior. Example_jobCancel demonstrates how to permanently cancel a job from within Work using JobCancel. Example_jobCancelFromClient demonstrates how to permanently cancel a job from any Client using JobCancel. Example_jobSnooze demonstrates how to snooze a job from within Work using JobSnooze. The job will be run again after 5 minutes and the snooze attempt will decrement the job's attempt count, ensuring that one can snooze as many times as desired without being impacted by the max attempts. Example_periodicJob demonstrates the use of a periodic job. Example_queuePause demonstrates how to pause queues to prevent them from working new jobs, and later resume them. Example_scheduledJob demonstrates how to schedule a job to be worked in the future. Example_subscription demonstrates the use of client subscriptions to receive events containing information about worked jobs. Example_uniqueJob demonstrates the use of a job with custom job-specific insertion options. Example_workFunc demonstrates the use of river.WorkFunc, which can be used to easily add a worker with only a function instead of having to implement a full worker struct.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river-licensetest#section-documentation
• Licenses: MPL-2.0
• Latest release: (published 20 days ago)
• Last Synced: 2026-01-16T00:49:58.558Z (20 days ago)
• Versions: 0
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 9.472%
  • Average: 10.11%
  • Dependent repos count: 10.747%

proxy.golang.org: github.com/riverqueue/river/cmd/river

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/cmd/river#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.0 (published 23 days ago)
• Last Synced: 2026-01-18T20:05:22.371Z (17 days ago)
• Versions: 61
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 9.564%
  • Average: 10.175%
  • Dependent repos count: 10.785%

proxy.golang.org: github.com/riverqueue/river/riverdriver

Package riverdriver exposes generic constructs to be implemented by specific drivers that wrap third party database packages, with the aim being to keep the main River interface decoupled from a specific database package so that other packages or other major versions of packages can be supported in future River versions. River currently only supports Pgx v5, and the interface here wrap it with only the thinnest possible layer. Adding support for alternate packages will require the interface to change substantially, and therefore it should not be implemented or invoked by user code. Changes to interfaces in this package WILL NOT be considered breaking changes for purposes of River's semantic versioning.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/riverdriver#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.0 (published 23 days ago)
• Last Synced: 2026-01-18T20:05:26.236Z (17 days ago)
• Versions: 62
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 9.564%
  • Average: 10.175%
  • Dependent repos count: 10.785%

proxy.golang.org: github.com/riverqueue/river/riverdriver/riverdatabasesql

Package riverdatabasesql bundles a River driver for Go's built-in database/sql, making it interoperable with ORMs like Bun and GORM. It's generally still powered under the hood by Pgx because it's the only maintained, fully functional Postgres driver in the Go ecosystem, but it uses some lib/pq constructs internally by virtue of being implemented with Sqlc. Example_migrateDatabaseSQL demonstrates the use of River's Go migration API through Go's built-in database/sql package.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river/riverdriver/riverdatabasesql#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.0 (published 23 days ago)
• Last Synced: 2026-01-18T20:05:35.831Z (17 days ago)
• Versions: 62
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 9.564%
  • Average: 10.175%
  • Dependent repos count: 10.785%

proxy.golang.org: github.com/riverqueue/river

Package river is a robust high-performance job processing system for Go and Postgres. See homepage, docs, and godoc, as well as the River UI. Being built for Postgres, River encourages the use of the same database for application data and job queue. By enqueueing jobs transactionally along with other database changes, whole classes of distributed systems problems are avoided. Jobs are guaranteed to be enqueued if their transaction commits, are removed if their transaction rolls back, and aren't visible for work _until_ commit. See transactional enqueueing for more background on this philosophy. Jobs are defined in struct pairs, with an implementation of `JobArgs` and one of `Worker`. Job args contain `json` annotations and define how jobs are serialized to and from the database, along with a "kind", a stable string that uniquely identifies the job. Workers expose a `Work` function that dictates how jobs run. Jobs are uniquely identified by their "kind" string. Workers are registered on start up so that River knows how to assign jobs to workers: A River `Client` provides an interface for job insertion and manages job processing and maintenance services. A client's created with a database pool, driver, and config struct containing a `Workers` bundle and other settings. Here's a client `Client` working one queue (`"default"`) with up to 100 worker goroutines at a time: ## Insert-only clients It's often desirable to have a client that'll be used for inserting jobs, but not working them. This is possible by omitting the `Queues` configuration, and skipping the call to `Start`: `Workers` can also be omitted, but it's better to include it so River can check that inserted job kinds have a worker that can run them. ## Stopping The client should also be stopped on program shutdown: There are some complexities around ensuring clients stop cleanly, but also in a timely manner. See graceful shutdown for more details on River's stop modes. `Client.InsertTx` is used in conjunction with an instance of job args to insert a job to work on a transaction: See the `InsertAndWork` example for complete code. Batch job insertion for efficiently inserting many jobs at once using Postgres `COPY FROM`. Cancelling jobs from inside a work function. Error and panic handling. Multiple queues to better guarantee job throughput, worker availability, and isolation between components. Periodic and cron jobs. Scheduled jobs that run automatically at their scheduled time in the future. Snoozing jobs from inside a work function. Subscriptions to queue activity and statistics, providing easy hooks for telemetry like logging and metrics. Test helpers to verify that jobs are inserted as expected. Transactional job completion to guarantee job completion commits with other changes in a transaction. Unique jobs by args, period, queue, and state. Web UI for inspecting and interacting with jobs and queues. Work functions for simplified worker implementation. ## Cross language enqueueing River supports inserting jobs in some non-Go languages which are then worked by Go implementations. This may be desirable in performance sensitive cases so that jobs can take advantage of Go's fast runtime. See developing River. Example_batchInsert demonstrates how many jobs can be inserted for work as part of a single operation. Example_completeJobWithinTx demonstrates how to transactionally complete a job alongside other database changes being made. Example_cronJob demonstrates how to create a cron job with a more complex schedule using a third party cron package to parse more elaborate crontab syntax. Example_customInsertOpts demonstrates the use of a job with custom job-specific insertion options. Example_errorHandler demonstrates how to use the ErrorHandler interface for custom application telemetry. Example_globalHooks demonstrates the use of hooks to modify River behavior which are global to a River client. Example_globalMiddleware demonstrates the use of middleware to modify River behavior which are global to a River client. Example_gracefulShutdown demonstrates a realistic-looking stop loop for River. It listens for SIGINT/SIGTERM (like might be received by a Ctrl+C locally or on a platform like Heroku to stop a process) and when received, tries a soft stop that waits for work to finish. If it doesn't finish in time, a second SIGINT/SIGTERM will initiate a hard stop that cancels all jobs using context cancellation. A third will give up on the stop procedure and exit uncleanly. Example_insertAndWork demonstrates how to register job workers, start a client, and insert a job on it to be worked. Example_jobArgsHooks demonstrates the use of hooks to modify River behavior. Example_jobCancel demonstrates how to permanently cancel a job from within Work using JobCancel. Example_jobCancelFromClient demonstrates how to permanently cancel a job from any Client using JobCancel. Example_jobSnooze demonstrates how to snooze a job from within Work using JobSnooze. The job will be run again after 5 minutes and the snooze attempt will decrement the job's attempt count, ensuring that one can snooze as many times as desired without being impacted by the max attempts. Example_periodicJob demonstrates the use of a periodic job. Example_queuePause demonstrates how to pause queues to prevent them from working new jobs, and later resume them. Example_scheduledJob demonstrates how to schedule a job to be worked in the future. Example_subscription demonstrates the use of client subscriptions to receive events containing information about worked jobs. Example_uniqueJob demonstrates the use of a job with custom job-specific insertion options. Example_workFunc demonstrates the use of river.WorkFunc, which can be used to easily add a worker with only a function instead of having to implement a full worker struct.

• Homepage: https://github.com/riverqueue/river
• Documentation: https://pkg.go.dev/github.com/riverqueue/river#section-documentation
• Licenses: MPL-2.0
• Latest release: v0.30.0 (published 23 days ago)
• Last Synced: 2026-01-18T20:05:26.149Z (17 days ago)
• Versions: 85
• Dependent Packages: 0
• Dependent Repositories: 0
• Rankings:
  • Dependent packages count: 9.429%
  • Dependent repos count: 10.745%
  • Average: 16.045%
  • Forks count: 18.762%
  • Stargazers count: 25.244%