Demo stream

A public demo broker runs at demo.getubik.dev:9092, plaintext, no credentials. It carries two topics, produced continuously and correlated at the source:

About 90% of orders receive exactly one payment 1 to 8 seconds later, 8% of those declined; a few payments reference no order at all. ts is a timestamp-shaped JSON string, so it is typed TIMESTAMP on read and TUMBLE works on it directly (formats).

A windowed aggregate

ubik --from kafka://demo.getubik.dev/orders \
  "SELECT merchant, TUMBLE(ts, INTERVAL '5' SECOND) AS w,
          count(*) AS orders, round(sum(amount), 2) AS total
   FROM orders GROUP BY merchant, TUMBLE(ts, INTERVAL '5' SECOND)"

{"merchant":"acme","w":"2026-08-04 20:02:15","orders":34,"total":1413.19}
{"merchant":"globex","w":"2026-08-04 20:02:15","orders":31,"total":1297.3}
{"merchant":"hooli","w":"2026-08-04 20:02:15","orders":5,"total":217.4}

The stream-stream interval join

The correlation is what the second topic is for: each payment lands inside a ten-second band of its order, so the interval join matches most orders and visibly filters the unpaid ones (the gaps in the ids).

ubik --from kafka://demo.getubik.dev/orders \
     --stream payments=kafka://demo.getubik.dev/payments \
  "SELECT o.order_id, o.merchant, round(o.amount, 2) AS amount, p.status
   FROM orders o JOIN payments p
     ON o.order_id = p.order_id
    AND p.ts BETWEEN o.ts AND o.ts + INTERVAL '10' SECOND"

{"order_id":"o1785873397","merchant":"initech","amount":42.5,"status":"captured"}
{"order_id":"o1785873398","merchant":"acme","amount":41.73,"status":"declined"}
{"order_id":"o1785873400","merchant":"globex","amount":39.94,"status":"captured"}

What the endpoint allows

• Read and describe on the two topics, for any client. Produce, topic creation, deletion and configuration are denied by ACL.
• Retention is one hour. Ubik reads from earliest, so a fresh run first replays the retained backlog (about 20 MB) before it reaches the live edge.
• The broker grants Describe on the consumer group ubik: every librdkafka consumer that carries a group.id issues FindCoordinator at startup, and an authorizing broker refuses the session without it. A locked-down cluster of your own needs the same grant for ubik to read it (security).

The demo data is synthetic, regenerated continuously, and the endpoint caps connections per IP and total egress. For anything beyond a first contact, run your own broker: source and sink starts one in a container in under a minute.