Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite

honker is a SQLite extension + language bindings that add Postgres-style NOTIFY/LISTEN semantics to SQLite, with built-in durable pub/sub, task queue, and event streams, without client polling or a daemon/broker. Any language that can SELECT load_extension('honker') gets the same features.

honker ships as a Rust crate, a SQLite loadable extension, and language packages for Python, Node, Bun, Ruby, Go, Elixir, and C++. The on-disk layout is defined once in Rust; every binding is a thin wrapper around the loadable extension.

honker works by replacing a polling interval with event notifications on SQLite's WAL file, achieving push semantics and enabling cross-process notifications with single-digit millisecond delivery.

SQLite is increasingly the database for shipped projects. Those inevitably require pubsub and a task queue. The usual answer is "add Redis + Celery." That works, but it introduces a second datastore with its own backup story, a dual-write problem between your business table and the queue, and the operational overhead of running a broker.

honker takes the approach that if SQLite is the primary datastore, the queue should live in the same file. That means INSERT INTO orders and queue.enqueue(...) commit in the same transaction. Rollback drops both. The queue is just rows in a table with a partial index.

Key features include:

• Notify/listen across processes on one .db file.
• Work queues with retries, priority, delayed jobs, and a dead-letter table.
• Atomic sends with business writes.
• Single-digit millisecond cross-process reaction time, no polling.
• Handler timeouts, declarative retries with exponential backoff.
• Delayed jobs, task expiration, named locks, rate-limiting.
• Crontab-style periodic tasks with a leader-elected scheduler.
• Durable streams with per-consumer offsets.
• SQLite loadable extension so any SQLite client can read the same tables.