Que
pg-boss
Our great sponsors
Que | pg-boss | |
---|---|---|
10 | 12 | |
2,282 | 1,585 | |
0.4% | - | |
6.0 | 5.5 | |
17 days ago | about 1 month ago | |
Ruby | JavaScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
Que
-
Choose Postgres Queue Technology
> Can you define "low throughput"?
<1000 messages per minute
Not saying SKIP LOCKED can't work with that many. But you'll probably want to do something better.
FWIW, Que uses advisory locks [1]
Few things.
1. The main downside to using PostgreSQL as a pub/sub bus with LISTEN/NOTIFY is that LISTEN is a session feature, making it incompatible with statement level connection pooling.
2. If you are going to do this use advisory locks [0]. Other forms of explicit locking put more pressure on the database while advisory locks are deliberately very lightweight.
My favorite example implementation is que [1] which is ported to several languages.
[0] https://www.postgresql.org/docs/current/explicit-locking.htm...
-
Introducing tobox: a transactional outbox framework
Probably worth mentioning that aside from delayed_job there are at least two more modern alternatives backed by the DB: Que and good_job.
-
Sidekiq jobs in ActiveRecord transactions
Good article. Sidekiq is a good, well respected too. However if you are starting out I would recommend not using it, and instead choosing a DB based queue system. We have great success with que, but there are others like good_job.
-
SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue
(not sure why this comment was dead, I vouched for it)
There are a lot of ways to implement a queue in an RDBMS and a lot of those ways are naive to locking behavior. That said, with PostgreSQL specifically, there are some techniques that result in an efficient queue without locking problems. The article doesn't really talk about their implementation so we can't know what they did, but one open source example is Que[1]. Que uses a combination of advisory locking rather than row-level locks and notification channels to great effect, as you can read in the README.
-
Delayed Job vs. Sidekiq: Which Is Better?
https://github.com/que-rb/que
This one seems to be the most performant. By a lot too, from my understanding (haven't ran any benchmark myself, but the readme shows some good postgres knowledge)
-
Sidekiq VS Que - a user suggested alternative
2 projects | 3 Feb 2022
Que seems like a good alternative if one doesn't want to use Reids. However, given that most apps need Redis (and have it within their infrastructure) nowadays, I still think that Sidekiq is the better option in the generic case.
-
Devious SQL: Message Queuing Using Native PostgreSQL
Implementations that use advisory locks like https://github.com/que-rb/que are much more efficient (atleast when I last tested) and will easily reach 10k job/s on even very modest hardware.
There is a Go port of Que but you can also easily port it to any language you like. I have a currently non-OSS implementation in Rust that I might OSS someday when I have time to clean it up.
-
Postgres is a great pub/sub and job server
It’s also possible to use advisory locks to implement a job queue in Postgres. See e.g. Que[1]. Note there are a fair number of corner cases, so studying Que is wise if trying to implement something like this, as well as some (a bit older) elaboration[2].
We implemented a similar design to Que for a specific use case in our application that has a known low volume of jobs and for a variety of reasons benefits from this design over other solutions.
-
Ruby Schedulers: Whenever vs Sidekiq Cron vs Sidekiq Scheduler
Do also take into consideration que-scheduler (disclaimer, am author). It is built on top of the robust que async job system.
pg-boss
-
Choose Postgres Queue Technology
For running queues on Postgres with Node.js backend(s), I highly recommend https://github.com/timgit/pg-boss. I'm sure it has it scale limits. But if you're one of the 90% of the apps that never needs any kind of scale that a modern server can't easily handle then it's fantastic. You get transactional queueing of jobs, and it automatically handles syncing across multiple job processing servers using Postgres locks.
-
Build Your Own Personal Twitter Agent 🧠🐦⛓ with LangChain
Jobs use pg-boss, a postgres extension, to queue and run tasks under the hood.
-
SQL Maxis: Why We Ditched RabbitMQ and Replaced It with a Postgres Queue
If you don't want to roll your own, look into https://github.com/timgit/pg-boss
-
How to schedule tasks in a Node.js app 🕙
The best I've used till now. Has all kind of features and really great when you have a postgres dB in your stack. https://github.com/timgit/pg-boss
-
Cluster friendly task scheduler for NodeJS
Check out these; - https://github.com/mitranim/posterus - https://github.com/timgit/pg-boss - https://github.com/FirebaseExtended/firebase-queue - https://www.npmjs.com/package/rabbit-queue
-
Launch HN: Convoy (YC W22) – Open-source cloud-native webhooks service
Both! For context, we're currently using https://github.com/timgit/pg-boss as a task queue on top of postgres and it works great. No need to complicate things with Redis. I believe it's quite straightforward to implement a task queue on top of postgres using the SKIP LOCKED functionality.
- Devious SQL: Message Queuing Using Native PostgreSQL
-
Postgres is a great pub/sub and job server
If anyone is looking to use postgres as a job server with node.js clients, I can highly recommend the pg-boss library (https://github.com/timgit/pg-boss). Looks like it just added pub/sub too (yesterday), so I guess you could use it for that too.
-
Do you need Redis? how to get away with just Postgres
We’ve seen success in our current node.js application using pgboss [1] for job queueing. Since the primary database is Postgres, it’s nice to not introduce another dependency into the system, and take advantage of the infrastructure that we already have. The library supports most of what you’d expect from a job queue, and is crucially well maintained!
That being said, I agree with other comments that this is somewhat swimming against the tide. Redis is much more commonly used, and so if you don’t mind adding another service into the mix, I’d probably recommend going with Redis instead.
What are some alternatives?
worker - High performance Node.js/PostgreSQL job queue (also suitable for getting jobs generated by PostgreSQL triggers/functions out into a different work queue)
Sidekiq - Simple, efficient background processing for Ruby
celery - Distributed Task Queue (development branch)
good_job - Multithreaded, Postgres-based, Active Job backend for Ruby on Rails.
Delayed::Job - Database based asynchronous priority queue system -- Extracted from Shopify
Resque - Resque is a Redis-backed Ruby library for creating background jobs, placing them on multiple queues, and processing them later.
django-postgres-queue - A task queue for django
RabbitMQ - Open source RabbitMQ: core server and tier 1 (built-in) plugins
Redis - Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.
kue - Kue is a priority job queue backed by redis, built for node.js.
Karafka - Ruby and Rails efficient Kafka processing framework
Chronicle Queue - Micro second messaging that stores everything to disk