At Apple, on iTunes, we used an Oracle database to do job queue stuff. Initially I will admit I made fun of it because I wanted to use a "real" queue like RabbitMQ or ActiveMQ or something, but I have to admit that it worked fine and to be fair it did predate both of those.
Anyway, it made me realize that there's really no reason you can't use a SQL database as a backing store for queue stuff. I should try building my own at some point.
This is exactly why I built bunqueue — a job queue for Bun backed by SQLite. No Redis, no external dependencies, just bun:sqlite with WAL mode for concurrent access. Handles 100k+ jobs/sec on a single node.
The SQL-as-queue pattern is definitely underrated. Great to hear it worked well at that scale.
I remember in my early dev days thinking I was clever for creating a queue. Was right in MySQL handing forum posts back when building your own forum software was a normal thing. It worked fine. Was it optimal? Not really but neither was the entire app. Didn’t matter at the time and probably doesn’t matter today either for most apps.