Mikael Müläri built Honker to solve a specific pain point. When you're using SQLite as your primary datastore, you still need a queue for background jobs. The usual answer is adding Redis plus a task runner like Celery. That works, but it means managing two data stores, dealing with backup for both, and facing the dual-write problem where your business data and your queue can get out of sync. Honker keeps the queue in the same SQLite file, so your INSERT INTO orders and your queue.enqueue happen in the same transaction. Rollback drops both.
The extension polls SQLite's PRAGMA data_version every millisecond. That's a monotonic counter that SQLite increments on every commit. A single background thread fans out to subscribers, and cross-process wake latency sits around 0.7ms at p50 on Apple silicon. The queue itself is just rows in a table with a partial index, supporting retries, priority queues, and dead-letter handling. Bindings exist for Python, Node, Rust, Go, Ruby, Bun, Elixir, and C++, all sharing the same on-disk format.
Honker draws inspiration from Postgres tools like pg-boss and Oban, plus Python's Huey for SQLite-backed queuing. The project docs state it plainly: if you already run Postgres, use those. But SQLite is showing up in serious production environments now. Bluesky's Personal Data Server runs on it. Turso built an edge platform around it. Fly.io is investing in replication tooling with LiteFS. The gap between "weekend project database" and "production datastore" keeps shrinking, and tools like Honker fill in the missing pieces. Hacker News commenters compared it to Ruby's Litestack. Some questioned whether polling beats kernel file watchers, but Müläri's design prioritizes simplicity and low idle cost.