Language guides

Every Honker binding is a first-class binding over the same SQLite layout. Pick your runtime for package names, extension loading notes, watcher-backend selection, transactional outbox usage, and ORM integration.

Python Native wheel, SQLAlchemy/Django notes, task helpers, and outbox workers.

Node Native npm package, better-sqlite3/Drizzle/Kysely notes, and watcher backend selection.

Rust The native honker crate, sqlx integration, and feature-gated watcher backends.

Go database/sql, GORM, extension loading, and subprocess-friendly queue workers.

Ruby Ruby gem, Rails/ActiveRecord notes, extension loading, and outbox workers.

Bun bun:sqlite binding, TypeScript API, Drizzle notes, and watcher backends.

Elixir exqlite/Ecto integration, process workers, scheduler, and outbox delivery.

.NET / C# NuGet package, Microsoft.Data.Sqlite, EF Core notes, and async listeners.

Java / Kotlin Maven artifacts, JDBC/Hibernate/jOOQ/Exposed notes, coroutine Flow helpers, and watcher backends.

C++ Header API, raw sqlite3 integration, RAII transactions, and C++ ORM notes.

One Contract

All bindings share these rules:

• Use a file-backed SQLite database, not :memory:, when testing worker or listener behavior.
• Keep business writes and Honker calls in the same transaction when you need atomic enqueue, publish, notify, or outbox behavior.
• Use a separate worker process for production queue and outbox delivery.
• If your ORM owns the connection, load the Honker extension there and call honker_* SQL functions inside the ORM transaction.
• watcher_backend / watcherBackend accepts poll, polling, kernel, kernel-watcher, shm, and shm-fast-path. Explicit experimental backend requests fail rather than silently falling back.

The detailed ORM recipes still live under Using with an ORM. These language pages include the short version so each binding doc stands on its own.