What does it do?
RQ, short for Redis Queue, lets a Python program push a task, like process this uploaded image, onto a list stored in Redis, a fast in-memory database, where a separate worker process picks it up and runs it whenever it’s free. It deliberately does far less than Celery: no elaborate configuration, no dozens of options, just a simple queue and workers that pull from it. That simplicity is the entire pitch, since you can understand RQ’s whole design in an afternoon.
See it in action
This queues up a ‘send an email’ job to be handled later by a separate background worker, instead of making the program wait for it right now.
from redis import Redis
from rq import Queue
def send_email(address):
print(f"Sending email to {address}")
queue = Queue(connection=Redis())
job = queue.enqueue(send_email, "user@example.com")
print(job.id)Why would a non-developer care?
Not every company needs an industrial-strength task queue with every bell and whistle; many just need to run this thing later, off the main page load, without a steep learning curve. RQ exists for exactly that gap, which is why smaller teams and side projects gravitate toward it.
Real-world examples
RQ was created by Vincent Driessen, also known for popularizing the gitflow branching model, and it’s become the go-to recommendation for Python developers who tried Celery and found it overkill for their needs. A small startup sending a handful of background emails a day doesn’t need Celery’s message-broker flexibility, it needs something it can set up before lunch, which is RQ’s whole reason for existing.
Who uses it
Small teams and solo developers who need simple background job processing without Celery’s configuration overhead.
How it compares to alternatives
It sits directly against Celery, trading flexibility and broker choice, since RQ only works with Redis, for radical simplicity, and against Dramatiq, which offers a similarly lightweight feel but with different design opinions.