What you actually have to run
If you have Kafka and a job that fits on one machine, these are your real alternatives. The table is deployment shape only, because that is what you can verify yourself. Delivery guarantees are each vendor's to state, and ours is the harness that proves it.
| Ubik | Kafka Streams | Proton | Flink | |
|---|---|---|---|---|
| What you run | one process, or a library inside yours | a library inside your JVM app | a server | a JobManager and TaskManagers |
| Query language | SQL | Java or Kotlin | SQL | SQL or Java |
| Where window state lives | one local file | RocksDB, plus a changelog topic in your broker | server-local | RocksDB, plus a checkpoint store |
| Embed in your own process | yes, C ABI, any language | JVM only | no | no |
| Runtime dependencies | libc and libstdc++ | a JVM | a server | a JVM and a cluster |
What Ubik is not
Not a Flink replacement at hyperscale
Above a few million events/s sustained, state beyond one machine’s NVMe, or hot-state sub-second failover, that is Flink territory, and the docs say so plainly.
Not a message broker
It reads and writes logs, it never becomes the log of record. You bring the durable Kafka-shaped thing upstream. Rebuilding one is out of scope.
Not append-and-correct
Windows close on the watermark and emit once. No retractions, no stream-stream joins, no Protobuf yet. Those are year-two scope, and they will disqualify some workloads.
Not a distributed system
No distributed code path will ever land in the core. A second machine would make it the thing it replaces.