A Job Queue in One SQLite File: ukue 0.1 Lets Small Teams Skip Redis

Tue, 06 Oct 2026 00:00:00 +0000

Sooner or later every web app needs to do something outside the request. Send the welcome email after the user has seen the page. Resize the photo while they carry on. Retry the webhook when the other side is down. The standard way to do that is a job queue, and the standard way to get a job queue is to run Redis or RabbitMQ next to your app.

ukue 0.1 puts the whole queue in one file instead. It’s a SQLite database with a documented layout, and it holds every queue, every waiting job, every retry and every job that failed for good. A Go program imports ukue as a library. Everything else uses the one small ukue binary, which runs a script for each job or serves a small HTTP API.

An Order and Its Receipt Email in One SQLite Transaction With ukue's EnqueueTx

Tue, 06 Oct 2026 00:00:00 +0000

Take a small online shop that runs as a single Go program with its data in SQLite: one file to back up and no database server to look after. When an order comes in, the shop saves it, and a receipt email goes out in the background.

The risk is in the gap between those two steps. If the order is saved and the program crashes before the email job is queued, the customer pays and never gets a receipt. If the job is queued first and saving the order then fails, the customer gets a receipt for an order that doesn’t exist. With a separate queue server, closing that gap takes real work, usually an “outbox” table in the database and a second process that copies its rows into the queue. With ukue, the queue can live inside the shop’s own database, so the order and its job go into the same transaction, and either both are saved or neither is.

Sqlite on ukue.com

A Job Queue in One SQLite File: ukue 0.1 Lets Small Teams Skip Redis

An Order and Its Receipt Email in One SQLite Transaction With ukue's EnqueueTx