Durable queues, streams, pub/sub, and a cron scheduler – inside your SQLite file

Your tiny database wants to replace Redis, and the comments are not calm

TLDR: Honker puts app data, background jobs, alerts, and scheduling into one SQLite file, promising less setup and fewer moving parts. Commenters split hard: some love the simplicity, while critics mocked its every-millisecond checking loop as a questionable trade-off.

A new project called honker is pitching a very seductive idea: if your app already stores everything in a single SQLite database file, why bolt on extra moving parts just to run background jobs, send alerts, or schedule tasks? In plain English, it tries to cram the jobs queue, message system, event feed, and even a cron-like scheduler into the same file. Fans love the simplicity: one file, one backup story, one place where your app data and your background tasks succeed or fail together. For small teams and scrappy projects, that sounds almost suspiciously convenient.

But the comments? Absolutely not a quiet room. The biggest fight exploded around how honker wakes things up: it checks for changes every millisecond. Security veteran tptacek threw the sharpest elbow, saying the pitch sounded like an overexcited AI had oversold things, because “busy-polling” every millisecond does not sound obviously better than using the operating system’s built-in file watching. Another commenter basically said, “Why are we even doing this? If SQLite is usually for one app process, just use a ring buffer and proper signaling.” Translation for normal people: some readers think this is clever engineering; others think it’s a very fancy workaround for a problem that shouldn’t exist.

The author jumped into the fray with a calm “author here,” insisting the trick is lighter than normal polling and teasing future upgrades that may remove polling entirely. That helped, but didn’t kill the drama. The vibe was part ‘this is kind of genius’, part ‘we are one benchmark away from a flame war’.

Key Points

  • honker is a SQLite loadable extension that adds durable pub/sub, work queues, streams, and cron-style scheduling inside a single SQLite database file.
  • The article says honker enables atomic commits between business-table writes and queue enqueues, so both succeed or roll back in the same transaction.
  • Supported use cases listed include cross-process signaling, retries and dead letters, transactional outbox patterns, per-consumer stream offsets, leader-elected scheduling, named locks, rate limiting, and optional task result storage.
  • The implementation described uses one background poller per database that checks SQLite’s PRAGMA data_version every millisecond and wakes subscribers to fetch new rows.
  • The article states that honker does not support SQLite in-memory database modes and recommends temporary file-backed databases for production-faithful testing.

Hottest takes

"the LLM that probably wrote this overshot the mark" — tptacek
"busy-polling a select does not actually sound better to me" — tptacek
"Are they joking?" — codedokode
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.