Results

Side-by-side benchmarks of Turbine vs competing Python stream processors. Each workload page shows the latest batch of every product (and every cores setting it was run at) side by side; numbers are relative and same-machine — the host is printed at the bottom of each page.

Workloads

• Stateless Filter + Enrich — Per-record filter keeping European regions (eu-*), then enrich each kept row with a derived latency_ratio and an ok/breach SLA decision. No state — measures the raw I/O + serde + per-record compute ceiling (fed above each consumer's capacity so CPU saturates).
• End-to-end Latency (iso-rate) — The stateless filter + enrich app of every product, fed the SAME modest rate every product keeps up with, with a probe consumer tailing the output topic: latency = record published − gendata's timestamp (p50 / p99 / p99.9). Prices each product's batching / commit / epoch model rather than its ceiling — the regime where a serving or alerting pipeline actually runs. Only meaningful in the keep-up regime.
• Windowed Low Cardinality — Tumbling 30s event-time window grouped by region (16 fixed keys), aggregating count + avg(latency_ms). The tiny key set keeps state trivial, so this isolates framework + windowing overhead. Benched at each product's max sustainable single-partition rate (its knee).
• Windowed High Cardinality — Same tumbling 30s window and count + avg(latency_ms) aggregates as the low-cardinality bench, but grouped by user_id (~100k keys) — one open window per active user. Stresses the keyed-state store rather than framework overhead.
• Model Inference — Score every record with the SAME frozen 4-16-1 PyTorch MLP (models/, trained once by models/make_model.py). No filter, so selectivity is 1.0 — this prices what each framework costs around a forward pass: decode, feature extraction, the call itself, encode, produce. The model is deliberately tiny so the frameworks, not the matmul, are what is measured. Benched at each product's max sustainable single-partition rate (its knee).

Reading the tables

• KPI 1 — one partition's capacity: consumed/s at the product's operating point, next to the cores it was allowed on that partition through its own mechanism. regime says whether that point is sustainable (keep-up) or a ceiling (saturated).
• KPI 2 — efficiency: rows/s per core, rows/s per GB, µs CPU per record. Raw CPU/memory sit in their own table and are never bar-charted against products fed different rates.
• Fairness: extra rec/rec counts records that crossed the broker on topics other than the input/output (0 = in-process end to end); the consumer fetch configuration is identical for every product; sanity checks compare output ÷ consumed against theory.