Honker: PostgreSQL NOTIFY/LISTEN for SQLite Pub/Sub Queues

Honker hit #1 on BuilderPulse (261 points) on April 24, 2026, solving a problem every developer faces once their weekend SQLite project somehow ends up in production. You need background jobs and pub/sub, but adding Redis + Celery means managing a second datastore, dual-write bugs, and infrastructure complexity. Honker keeps everything in one SQLite file with atomic transactions that guarantee business writes and queue messages commit together or roll back together—no more “user created but welcome email never sent” bugs.

Created by Russell Romney, Honker brings PostgreSQL’s NOTIFY/LISTEN semantics to SQLite, along with durable task queues and event streams—all without a separate message broker. This is the SQLite Renaissance in action, and it’s part of a bigger shift away from resume-driven architecture toward infrastructure that actually ships products.

The Technical Trick: Polling PRAGMA data_version

Honker achieves single-digit millisecond cross-process reaction times by polling PRAGMA data_version every 1 millisecond. This SQLite pragma returns a counter that increments on every transaction commit. When Honker detects a change, it checks for new messages—”push-like” semantics without application-level polling or webhooks.

Unlike PostgreSQL’s NOTIFY/LISTEN (which requires an active connection and loses messages if the listener disconnects), Honker provides durable message persistence. The three primitives are: notify() for ephemeral pub/sub, stream() for durable pub/sub with per-consumer offsets (like Kafka), and queue() for at-least-once work queues with retry logic and dead-letter handling.

The 1ms polling interval is efficient—minimal overhead, maximum responsiveness. For developers skeptical of SQLite for real-time use cases, this mechanism proves you don’t need Redis to build reactive systems.

Solving the Dual-Write Problem

The killer feature is atomic dual writes: business logic and queue messages commit together or roll back together. If you insert a user and enqueue a welcome email in the same transaction, you’ll never have “user created but email lost” bugs.

import honker
db = honker.open("app.db")
emails = db.queue("emails")
with db.transaction() as tx:
    tx.execute("INSERT INTO orders (user_id) VALUES (?)", [42])
    emails.enqueue({"to": "alice@example.com"}, tx=tx)
    # If transaction fails, both INSERT and enqueue roll back

This eliminates the dual-write problem that plagues Redis/Celery setups. Distributed systems engineers spend careers managing eventual consistency and compensating transactions. Honker’s answer: don’t distribute—keep everything in one transactional database.

Worker processes claim and process jobs while remaining responsive to database commits. No polling loops, no race conditions, no “orphaned jobs that were enqueued but the business write failed.”

Decision Guide: Honker vs Redis/RabbitMQ

Honker is ideal for solo developers, small teams, and apps with less than 10,000 background jobs per hour. It trades peak throughput for operational simplicity. For ultra-high-throughput use cases (more than 10k jobs/sec), multi-server deployments, or sub-millisecond latency requirements, stick with Redis or RabbitMQ.

Performance comparison: Redis pub/sub delivers sub-millisecond latency at 100k+ messages/sec. Honker hits 1-5ms latency at 5k-10k jobs/sec. Celery + Redis adds network overhead (10-50ms latency). For most applications, Honker’s throughput is more than enough—and you eliminate an entire class of operational headaches.

Decision criteria: Already using SQLite? Honker is a natural fit. Need more than 10k jobs/sec? Choose Redis. Want to minimize infrastructure? Honker wins. Need distributed queues across servers? RabbitMQ or Kafka. The pattern here is clear—match your architecture to your actual requirements, not your resume.

Related: Boring Tech Stack: The Most Controversial Choice in 2026

Part of the SQLite Renaissance

Honker isn’t an isolated project—it’s part of 2026’s “SQLite Renaissance.” Rails 8 ships with Solid Queue (SQLite background jobs) as the default. Bluesky’s Personal Data Server runs on SQLite. Turso and LiteFS enable edge deployments. The “boring tech stack” movement is rejecting Kubernetes complexity in favor of monoliths on single VPS deployments.

As one trending DEV.to post put it: “In 2026, developers are betting on simplicity as a radical architecture choice.” Teams are moving from microservices back to monoliths, from Kubernetes to single servers, from Redis + RabbitMQ to SQLite-based queues. The hype cycle exhausted everyone, and complexity drowned productivity.

This isn’t a step backward—it’s a correction. Most applications don’t need the complexity of distributed systems. Honker proves you can build production-grade background job processing with a single file, atomic guarantees, and zero infrastructure overhead.

Related: PostgreSQL Dethrones MySQL in 2026: 55.6% Developer Adoption Marks Historic Shift

Real-World Applications

Honker is perfect for weekend projects that hit production, solo developers avoiding Redis complexity, edge deployments (Fly, Cloudflare Workers), local-first apps (Electron, Tauri), and teams embracing boring tech. It’s not for multi-server horizontal scaling, ultra-high-throughput (more than 10k jobs/sec), or real-time gaming and financial trading.

Concrete scenarios: E-commerce checkout (user signs up, insert user + enqueue welcome email atomically). Background processing (CSV upload triggers row processing jobs). Cron jobs (database cleanup every 24 hours with leader election). Event-driven architecture (order created triggers inventory update, payment, email via SQLite streams).

Delayed jobs and cron tasks work out of the box:

from datetime import timedelta
# Delayed execution
queue.enqueue(
    {"action": "send_reminder"},
    delay=timedelta(hours=24)
)
# Periodic tasks (cron)
db.schedule(
    "cleanup",
    cron="0 0 * * *",
    handler=lambda: cleanup_old_records()
)

Simon Willison, Django creator and SQLite advocate, endorsed Honker with a simple observation: “It’s great to see a new implementation of that pattern for SQLite.” That’s high praise from someone who’s been championing SQLite for production use for years.

Key Takeaways

• Honker brings Postgres NOTIFY/LISTEN to SQLite with durable persistence—messages survive restarts, unlike PostgreSQL’s ephemeral notifications
• Atomic transactions eliminate dual-write bugs by committing business logic and queue messages together or rolling back both
• Ideal for solo developers and small teams with less than 10k jobs/hour—trades peak throughput for zero infrastructure overhead
• Part of 2026’s SQLite Renaissance alongside Rails 8 Solid Queue, Bluesky PDSs, and the “boring tech stack” movement
• Use Honker when operational simplicity matters more than distributed scale—use Redis when you actually need 100k+ jobs/sec

The smart money in 2026 isn’t on the flashiest architecture—it’s on systems that ship products, stay online, and let developers sleep at night. Honker delivers on all three.