Radio

The model: buffers in, a delivery queue out

Radio runs an asynchronous I/O thread per subscription so SQL never blocks on the wire. Inbound messages land in a per-subscription in-memory buffer that Radio exposes as ordinary table functions — each row carries a seen_count so re-querying drains only what's new, and the rows JOIN, WHERE, GROUP BY, and CREATE TABLE AS like any other table. Outbound messages go the other direction: you hand one to a transmit queue that delivers asynchronously and exposes per-message status plus per-subscription success/failure counters, so retries and audits are themselves SQL. That single shape — buffer incoming into tables, queue outgoing with delivery status — covers live dashboards refreshed on a timer, SQL-driven event responders that read then publish a reply, and ad-hoc inspection where you drain an unfamiliar channel into a table and GROUP BY to learn its shape; you can even inject canned messages into a subscription's inbox to test downstream SQL without a real upstream.

Supported transports

Two transports are wired up today, and the table-function surface stays identical regardless of protocol — you subscribe, drain, and transmit the same way whether the bytes arrive over a WebSocket or a Redis channel.

• • WebSocket: A standard RFC 6455 client. ws:// for plaintext or wss:// for TLS; the extension handles ping/pong and reconnect internally. Fits browser-style real-time feeds, event streams, and any custom server-sent API that speaks WebSocket.
• • Redis Pub/Sub: Point a subscription at a Redis URL plus channel name and Radio handles the Redis-specific SUBSCRIBE and PUBLISH under the same SQL surface. Fits application data flows that already use Redis as the bus.
• • Roadmap: Google Pub/Sub, Azure Service Bus, MQTT, and subprocess pipes are listed as planned on the extension's documentation page. Only WebSocket and Redis Pub/Sub exist today.

Production caveats

What to know before pointing this at anything important. Radio trades durability for the simplicity of living entirely inside one DuckDB process.

• • In-memory, process-scoped buffers: Subscriptions, the received-message buffer, and the transmit queue all live in DuckDB process memory. When DuckDB exits, subscriptions tear down and unread messages are lost. For at-least-once delivery across restarts, drain to a durable store before processing — a standalone consumer service can crash-restart from the bus, Radio cannot.
• • Fixed-capacity receive buffer: The inbound buffer is size-limited; older messages are evicted as new ones arrive. Drain at a cadence that keeps up with the inbound rate so you don't lose messages to eviction.
• • Best-effort outbound delivery: Transmit returns once the message is queued, not once it's delivered — the I/O thread updates each message's status asynchronously. Per-subscription transmit_successes / transmit_failures counters and the per-message status table expose progress so you can build retry logic in SQL.
• • Single connection per subscription: Subscription state is not shared across DuckDB connections in the same process. Open a subscription on the same connection that will drain it.
• • Experimental status: Function shapes may change as more transports land. Pin a known-good extension version in production.

Subscribe to a WebSocket channel — the URL is the subscription key

CALL radio_subscribe('wss://stream.example.com/events');

Drain buffered messages as a normal table

SELECT receive_time, channel, message
FROM radio_subscription_received_messages('wss://stream.example.com/events')
ORDER BY receive_time DESC
LIMIT 50;

Send a message — args are (url, channel, payload, max_attempts, retry_delay)

CALL radio_transmit_message(
  'wss://stream.example.com/events',
  'main',
  '{"type":"hello"}'::BLOB,
  3,
  INTERVAL '500 milliseconds'
);