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 — at open in most bindings; in the JVM/Kotlin bindings the watcher is created lazily, so the failure surfaces when a subscriber attaches.

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.