Introducing Soniq
May 2026 • 307 words • 2 min read
Many Python applications end up adding Redis purely for background jobs. Soniq is an async job queue that uses PostgreSQL as its backend - the database you're already running. No broker. No separate infrastructure. MIT licensed.
Soniq - the job queue for people who don’t want another job queue
I’ve been rebuilding the same job scheduler since 2011.
The first version used MongoDB. The core trick was find_and_modify – MongoDB’s atomic operation that lets you fetch a document and update it in a single step. Claim a job before anyone else does, or don’t claim it at all. No double processing. I ran a hosted multi-tenant version for two or three years. People used it. It mostly worked.
Then I moved on. But the problem stayed with me.
Over the years I’ve used most of the serious job queue libraries. Resque and Sidekiq in Ruby. RQ in Python. Each one solved the core problem well enough. Each one also required something extra: Redis, a specific runtime, or an entirely different programming model. The closest thing to what I wanted was Oban in Elixir – PostgreSQL-backed, no broker, no Redis. But I was building in Python.
I kept thinking about the infra cost. Not the money, but the maintenance. Every component you add to a production system is something that can fail, something you have to monitor, something you have to explain to whoever reads your deploy config next. Redis is not expensive to run. But Redis is one more thing to run.
I believe in boring infrastructure. The best infra component is usually the one you don’t add. Most Python applications already run PostgreSQL. Your jobs can too. It’s already there. It’s already backed up. You already understand it.
Last year I built Fastjob. PostgreSQL as the datastore, transactional enqueue, dashboard, webhooks, scheduler. Feature-rich. I’m also willing to admit it became complicated. I added things before the core was solid, and eventually the project became what I was trying to avoid: one more thing to manage.
In January this year I started again, on weekends. I call it Soniq.
Soniq is a batteries-included async job queue for Python. The only infrastructure dependency is PostgreSQL.
No Redis cluster. No separate broker. No operational split brain between your app state and your queue state.
If your application already depends on PostgreSQL, your queue can too.
What that gives you that most queues don’t:
- Transactional enqueue. A job is either committed or it isn’t. A user signs up, the database transaction commits, the welcome email job commits in the same transaction - there is no gap where one succeeds and the other disappears.
- Built-in scheduler and recurring jobs
- Built-in dashboard, no paid tier
- Prometheus metrics out of the box
Most applications don’t need a dedicated distributed queue cluster just to send emails and process background tasks. Soniq is built for that majority - teams that need reliability and operational simplicity more than extreme throughput.
If you’re already running PostgreSQL and don’t want another broker, Soniq is ready - MIT licensed, batteries included.