honker is a SQLite loadable extension adding Postgres-style NOTIFY/LISTEN, durable queues, streams, pub/sub, and a cron scheduler – no daemon or broker required.
Key Takeaways
Enqueue and business writes commit atomically in the same SQLite transaction; a rollback drops both the job and the business row together.
Uses stat(2) on the WAL sidecar file instead of FSEvents or inotify; FSEvents silently drops same-process write notifications on macOS.
Requires WAL journal mode – honker_bootstrap() refuses non-WAL databases because DELETE mode serializes all readers behind an EXCLUSIVE writer lock.
Ships as a Rust crate, a SQLite 3.9+ loadable extension, and language bindings for Python, Node, Bun, Ruby, Go, and Elixir; any language loading the extension shares the same _honker_live and _honker_dead tables.
Deliberately excludes task pipelines, DAG orchestration, and multi-writer replication; positioned as a single-server Redis + Celery replacement for SQLite-primary apps.
Hacker News Comment Review
The atomic-commit guarantee was flagged as the core differentiator over external IPC: separate message-passing systems have the classic “notification sent, transaction rolled back” split-brain problem.
Two commenters independently raised a WAL checkpoint edge case: when SQLite truncates the WAL file back to zero, a size-based stat() poll could interpret the shrink as a non-event and lose the wakeup signal.
Some questioned whether same-machine OS IPC (Unix sockets, shared memory) would outperform file-stat polling, with SQLite handling only the durable parts – the author’s position is that unifying both in one file is the design goal, not raw latency.
Notable Comments
@tuo-lei: raises the WAL checkpoint truncation window as an unaddressed edge case where stat() polling could silently miss events.
@ArielTM: independently confirms the Darwin same-process FSEvents drop, validating stat(2) as the only portable signal; also asks whether a WAL shrink triggers a spurious or missed wakeup.