Honker : les queues Postgres arrivent enfin sur SQLite

Pourquoi Honker change la donne pour SQLite

Jusqu'à présent, si tu voulais des queues transactionnelles ou des flux d'événements en SQLite, tu devais choisir : soit rester minimal (et perdre la fiabilité), soit ajouter une dépendance externe (Postgres, Kafka, Redis).

Honker apporte une troisième voie. C'est une extension SQLite écrite en Rust qui reproduit fidèlement les sémantiques de NOTIFY/LISTEN de Postgres.

Comment ça marche

Pour les queues de jobs :

import honker
db = honker.open("app.db")
emails = db.queue("emails")
emails.enqueue({"to": "alice@example.com"})

# Dans un worker process
async for job in emails.claim("worker-1"):
    send(job.payload)
    job.ack()

C'est lisible, c'est direct. Les jobs ne sont mis en file que si ta transaction est validée (transactional outbox pattern).

Pour les flux façon Kafka :

stream = db.stream("user-events")
with db.transaction() as tx:
    tx.execute("UPDATE users SET name=? WHERE id=?", [name, uid])
    stream.publish({"user_id": uid, "change": "name"}, tx=tx)

async for event in stream.subscribe(consumer="dashboard"):
    await push_to_browser(event)

Le secret des performances : Honker surveille le fichier WAL (~1ms) via un appel stat, pas une requête SQL. Tu approches du temps réel sans la latence d'une base traditionnelle.

Le piège à éviter

Honker nécessite le mode WAL (Write-Ahead Logging) de SQLite. C'est un prérequis, pas un bug. Si tu ne sais pas ce que c'est, tu l'actives en une ligne et c'est oublié.

Pour qui ?

Parfait pour :

• ▸Les startups qui veulent rester sur SQLite le plus longtemps possible
• ▸Les créateurs solo qui ont besoin de fiabilité sans ops complexe
• ▸Les cas où Postgres est surdimensionné mais Redis seul ne suffit pas

Moins adapté si tu as déjà Postgres et que tu l'aimes.