The pitch landed on Hacker News without much fanfare: What if you could stuff message queues, event streams, and cron jobs directly into your SQLite database file—the same one already holding your application data?
Within days, developers were paying attention. The post collected 327 points and 84 comments, many from engineers who'd evidently been waiting for someone to build exactly this. The tool is called Honker, and it arrived on April 24 as an open-source extension that promises to do for SQLite what Postgres developers have long taken for granted: reliable background jobs and real-time notifications, no separate infrastructure required.
Whether it's a clever consolidation or an overreach depends largely on how you feel about SQLite handling more than just data storage. But for small teams and solo developers already committed to the embedded database, the proposition is hard to ignore. One file. One backup. No Redis, no Kafka, no message broker humming in a Docker container somewhere.
The Core Bet
Honker installs as a SQLite loadable extension with bindings across seven languages—Python, Node.js, Rust, Go, Ruby, Bun, and Elixir. Once loaded, it grafts four distinct capabilities onto your database: durable work queues with retry logic and priority handling, append-only event streams with consumer offsets for replay, ephemeral pub/sub for cross-process signaling, and a cron-style scheduler with leader election.
The implementation borrows ideas from Postgres. Think NOTIFY and LISTEN, but translated into SQLite's single-writer world. Jobs, streams, and scheduled tasks all persist in tables prefixed with _honker_—sitting right alongside your application schema.
For backend work, the queues support the standard playbook: visibility timeouts, heartbeats, delayed execution, dead-letter handling. Failed jobs can be retried. Results can be stored. Streams function as append-only logs where consumers track their own offsets and can rewind to replay events. The pub/sub layer offers no delivery guarantees—it's ephemeral by design—but it's fast, useful for real-time notifications within a process boundary or between processes sharing the same file.
The scheduler handles five-field cron expressions and includes catch-up logic for missed execution windows, a detail that matters if your application goes offline and comes back up expecting tasks to fire.
Works With Your ORM, If You Want
Perhaps the more pragmatic feature: Honker plugs into existing ORM connections. SQLAlchemy, Django, Drizzle, Kysely, sqlx, GORM, ActiveRecord, Ecto—it works across all of them, sharing the same on-disk format. You can enqueue a background job in the same transaction that updates your user table. Commit, and both changes persist. Roll back, and neither does.
That transactional guarantee is harder to achieve when your queue lives in Redis and your data lives in Postgres. Systems that span two databases inherit dual-write problems—commit one, fail on the other, now what? Honker collapses that problem by keeping everything in one file.
The Python package hit PyPI on launch day. Documentation for the Rust crates shows version 0.3.1 as of late April, suggesting the project has moved quickly in its early days. Whether those version numbers indicate stability or rapid iteration is still an open question.
Polling Without the Pain
The technical trick here is how Honker avoids per-client polling. SQLite doesn't have native NOTIFY semantics, so most attempts at queues or pub/sub end up with every worker hammering the database on a loop, checking for new work.
Honker runs a single shared watcher thread per database file, regardless of how many listeners are attached. That thread checks PRAGMA data_version every millisecond—about three microseconds per read—and fans out wake signals when commits land. The architecture evolved during launch week, apparently. Early descriptions mentioned WAL file stat polling; community feedback on Hacker News nudged the author toward the PRAGMA-based approach, which now includes reconnection logic and file replacement detection.
Queue claims use atomic UPDATE ... RETURNING statements, so workers can grab jobs without stepping on each other. Stream consumers store their offsets in a separate table. The scheduler uses advisory locks with configurable TTL values to elect a leader and avoid duplicate task execution.
It's a clever workaround for SQLite's constraints, though it also highlights them. This is still a single-writer database. You're not going to process millions of messages a day across a distributed cluster with this setup.
The Limits Are the Point
The project's documentation is refreshingly candid about what Honker isn't. It's not built for high-volume, multi-machine message pipelines. A recent technical write-up from ByteIota noted that teams operating at scale should stick with Redis or Kafka—tools designed for exactly that. The Honker homepage makes the same point in the other direction: "Use Postgres-native solutions if you already run Postgres." Tools like pg-boss and Oban are better choices if you're already managing Postgres infrastructure.
Performance claims are modest and self-reported. Cross-process wake latency around 0.7 milliseconds at the median on an M-series laptop. "Thousands of messages per second" on modern hardware. No independent benchmarks yet—this is still early—but the numbers sound plausible given SQLite's write characteristics.
The real limitation is operational, not technical. SQLite's single-writer model constrains throughput. Honker embraces that constraint rather than fighting it, which makes sense for the audience it's targeting: developers building applications where "good enough" throughput means avoiding the complexity of running separate message infrastructure.
When Does This Make Sense?
The use case is narrower than it first appears, but real enough. Startups. Small teams. Solo developers shipping SaaS products or internal tools. Anyone already using SQLite who needs background jobs, scheduled tasks, or lightweight event streaming without introducing new dependencies.
One database file means one deployment artifact. One backup strategy. Transactional integrity across your data and your job queue. For teams operating at that scale, those advantages are hard to dismiss.
The scheduler can replace cron or external services for periodic work. Streams provide event sourcing patterns without Kafka's operational overhead (or its operational benefits, depending on how you look at it). Pub/sub offers a simpler alternative to Redis channels for notifications within a single-file boundary.
Honker doesn't claim to have invented any of this. The docs cite prior art: Postgres tools like pg_notify, Huey (a Python task queue that added SQLite support well before Honker existed), and LiteQueue. The project itself went through a couple of name changes—litenotify, joblite—before settling on Honker after the maintainer secured the domain.
Still Experimental
The README carries a warning: the API may change. This is launch-week software, which means production case studies don't exist yet. Adopting it means accepting some risk that interfaces will shift as the tool matures—or that it won't mature at all.
But the license is Apache 2.0, and the code is available now across package registries for all supported languages. Whether Honker gains traction beyond its initial burst of attention will depend on whether enough developers find that its trade-offs align with their scale and operational tolerance. For teams already betting on SQLite, though, the pitch is straightforward enough: Why run more infrastructure than you need to?
