Docs

honker ships as a Rust-built SQLite loadable extension plus bindings for Python, Node, Rust, Go, Ruby, Bun, Elixir, C++, .NET / C#, Java, and Kotlin. The extension defines the on-disk format; bindings are first-class wrappers that live in the main repo and share the same Rust core.

If you’re new, read Getting started. Otherwise, pick what you want to do:

Getting started Install honker, open a database, enqueue your first job.

Queues Work queues with retries, priority, delayed jobs, dead-letter.

Streams Durable pub/sub with per-consumer offsets and resume-after-crash.

Pub/Sub pg_notify-style ephemeral notifications. 0.7 ms p50 wake.

Scheduler Time-trigger scheduling with cron or @every expressions.

Tasks (decorators) Huey-style @task decorators. Enqueue by calling the function.

Language guides Install, queues, outbox, watcher backends, tests, and ORM notes for each binding.

Using with an ORM The non-framework philosophy plus per-language recipes for every Honker binding.

Binding support What each binding supports, and what CI proves.

Benchmarks Baseline throughput, wake latency, and idle watcher cost.

SQL function reference Every honker_* SQL function the extension installs.

Roadmap What stays in Honker, and which adjacent SQLite primitives may split out later.

What’s not here

Framework helpers for FastAPI/Django/Flask/Express/Rails aren’t shipped. Wiring honker into a web framework is about 20 lines of glue; the repo’s examples/ has patterns.

Out of scope on purpose: task pipelines, chains, groups, chords, multi-writer replication, workflow orchestration with DAGs.