Spate Benchmark
A reproducible comparison of streaming ETL systems on one fixed pipeline: Kafka → Avro → ClickHouse.
Every system consumes the same topic of Confluent-framed Avro, flattens each
message's events array into one row per event, and inserts those rows into
ClickHouse. Same bytes, same envelope, same hardware, same delivery guarantee.
Spate is measured here, and Spate is mine. That is a conflict of interest, and the only useful response to one is to make it impossible to hide.
- No published number is reported by the system that produced it. Throughput
is
SELECT count()against ClickHouse. CPU and memory are cgroup v2 counters read by a sidecar container. Latency is computed inside ClickHouse from a materialized ingest timestamp. A system's own metrics are available for debugging and are never read as results. - Every competitor configuration is in the repository, in full.
- Where Spate loses, that is published with the same prominence as where it wins. A comparison containing only wins is read as marketing and convinces nobody.
If you think an arm is configured badly, that is a bug and I want the pull request.
No measurements published yet
The harness, the workload and the fairness contract are in place and the arms are built, but no run has been recorded against them. Rather than show a number that does not exist, this page says so.
2 systems implemented, 4 planned. What each of them is waiting on is written down in the roadmap, and how they will be measured is in the methodology — both of which are worth more scrutiny before there are results than after.
The systems
| System | Status | Runtime | Licence | Delivery | Arms |
|---|---|---|---|---|---|
| Spate run by the vendor | active | native | Apache-2.0 | at-least-once | tier-a-native tier-a-rowbinary tier-a-native-typed tier-b-native tier-b-rowbinary |
| Apache Flink | active | jvm | Apache-2.0 | at-least-once | tier-a tier-b tier-a-reusing stripped |
| Vector | planned | native | MPL-2.0 | — | not yet implemented |
| Kafka Connect + clickhouse-kafka-connect | planned | jvm | Apache-2.0 | — | not yet implemented |
| ClickHouse Kafka table engine | planned | native | Apache-2.0 | — | not yet implemented |
| Redpanda Connect | planned | go | BUSL-1.1 | — | not yet implemented |
How to read a number here
Every result carries the version of the system that produced it, the exact image digest, the environment it ran on, and the date. None of that is optional and none of it is typed in by hand — a run whose image digest cannot be read is recorded as failed rather than published.
Three things invalidate comparison outright, and this site refuses to draw records across them rather than quietly averaging:
| If this differs | Then |
|---|---|
harness_version | The measurement protocol changed. Not comparable. |
dataset_version | The corpus or schema changed. Not comparable. |
env_id | Different hardware. Not comparable. |
Softer differences — a ClickHouse patch release, a compiler version — are recorded and shown as a footnote rather than treated as disqualifying.
Results are never deleted. A run found to be wrong is retracted by appending a marker; the record stays visible, struck through, with the reason. Re-running one system does not re-run or overwrite any other.
What this does not tell you
Read the limitations before citing anything here. The short version: one workload, one machine, one shape of data, and a benchmark whose author has a stake in the outcome.