# Timeplus Proton: a single-binary streaming SQL engine built on ClickHouse

> Proton folds streaming SQL, windowing and materialized views into one C++ binary that stores its own results, aimed at teams replacing Kafka consumer jobs with a queryable pipeline. The advertised 100+ GB/s figure traces back to one vendor laptop benchmark, and the install path ships no checksum.

**timeplus-io/proton** — The Fastest Unified Streaming SQL Engine in a Single C++ Binary.        ⚡ Millisecond latency. 100+ GB/s throughput. Continuously compute real-time context from streams, logs, metrics, events, and CDC.

- Repository: https://github.com/timeplus-io/proton
- Website: https://timeplus.com
- Stars: 2,273 · Forks: 112
- Language: C++
- License: Apache-2.0
- Published: 2026-10-14 · Updated: 2026-10-14 · Language: en
- Canonical page: https://hysenlabs.com/projects/timeplus-io-proton

## Streaming SQL without a JVM, ZooKeeper or cluster manager

Proton targets the engineer who already owns Kafka or Redpanda topics but a thicket of one-off consumer jobs kept in sync by hand. A filter that used to be a separate deployed consumer becomes a clause in a stream, and the offset bookkeeping disappears with it. Reading live topics is named as the strongest fit, reached through external streams.

Nothing outside the binary is required. No JVM, no ZooKeeper, no separate coordination service. ClickHouse sits underneath, and Proton extends the historical data, storage and computing that ClickHouse already does with stream processing on top. Tumble, hop and session windows, watermarks, incremental materialized views, CDC and data revision processing all execute inside that one process.

Footprint is part of the argument. A single binary under 500MB, small enough that the project says it also runs on an AWS t2.nano instance with 1 vCPU and 0.5 GiB of memory. SQL is the interface, so anyone who already writes ClickHouse SQL arrives with the grammar already in hand.

## One C++ binary on top of ClickHouse storage and functions

The codebase is C++ throughout, with base/, src/, programs/, cmake/ and contrib/ sitting at the root beside CMakeLists.txt, build.sh and a .clang-tidy configuration. SQL functions are inherited from the ClickHouse layer rather than reimplemented, and the README says thousands of them are available. That inheritance is also the trade-off: query semantics transfer in both directions, including whatever surprises ClickHouse already has.

What is different is where results live. Proton does not hand materialized output downstream and forget about it. Incremental materialized views are stored inside the engine as queryable analytical and row based tables, meant for dashboards and applications that read current state instead of replaying a topic. UDF in Python and JS extend the query surface without leaving the process.

Multi-stream JOINs, alerting and Tasks sit on top of the window functions, and that is the part that reshapes a pipeline rather than just relocating it. One declarative query replaces several chained consumers, their schemas and their lag monitoring.

## External streams are how Kafka and Redpanda reach the query layer

External streams are the named mechanism for live data. A stream is bound to a Kafka or Redpanda topic, and the example the project points to, examples/ecommerce/, is a Docker Compose stack that reads and writes Kafka or Redpanda data through external streams. That directory is also the clearest look at the full wiring of source, transform and sink in one place.

The native source and sink list runs long: Kafka, ClickHouse, MySQL, Postgres, MongoDB, S3 with Iceberg, and OpenSearch, alongside streaming ingestion, multi-stream JOINs, incremental materialized views, alerting, Tasks and UDF in Python or JS. Two documented pipeline shapes cover most traffic. One ingests live data, filters, enriches and masks it inside the pipeline, then routes it to ClickHouse, other Kafka topics or analytical stores. The other handles logs, metrics and traces, doing noise reduction and real-time alerting before anything is forwarded to Splunk, Elastic or S3.

## From the curl script to a running SQL client

Install is one line, and the script is the same command shown twice in the docs:

```shell
curl https://install.timeplus.com/oss | sh
```

With `proton` on the path, the engine and the SQL client are separate processes. The server writes its configuration, logs and data into a `proton-data` folder in the directory you launched it from, so the working directory decides where state lands. Run the client from a second terminal:

```shell
proton server
```

```shell
proton client
```

Homebrew handles install, upgrade and uninstall on macOS, and Docker covers the container case. Note what the container command does on every start:

```bash
brew install timeplus-io/timeplus/proton
```

```bash
docker run -d --pull always -p 8123:8123 -p 8463:8463 --name proton d.timeplus.com/timeplus-io/proton:latest
```

Those two ports are not the full story. The docs hand you to a separate Server Ports page to work out what else to expose so that other tools, DBeaver among them, can connect. A hosted trial at demos.timeplus.com exists for anyone who would rather not set any of this up.

## The headline throughput numbers trace to one laptop

The repository description advertises millisecond latency, 100+ GB/s throughput, and the title of fastest unified streaming SQL engine in a single C++ binary. The only measured figures anywhere in the README come from a different exercise: a company blog post about an Apple MacBookPro with M2 Max, reporting 90 million events per second, 4 millisecond end-to-end latency and aggregation across 1 million unique keys. One machine, one vendor, one workload shape.

The tree does contain examples/proton3-benchmarks/, next to run-sql-tests.sh, run-unit-tests.sh, run-smoke-tests.sh and local_coverage.sh at the root, yet no documentation says how to start the benchmarks or what they print. There is no in-repo procedure for reproducing the quoted throughput, and the highest cardinality claim, 1 million unique keys, arrives without a stated key distribution.

Practically, 100+ GB/s is a vendor claim until you push your own keys, your own retention and your own join graph through the engine. Two numbers in one blog post do not describe a default deployment.

## Three gaps between the shell script and a production install

First, the install pipes a remote script straight into a shell, and no checksum, signature, pinned version or offline bundle is published for checking what arrived. Second, the container command pairs the :latest tag with --pull always, so a restart silently swaps the running build for the newest one; pinning a known version means editing the command yourself. Both are one flag changes, and nothing in the docs walks through them.

The third gap is the folder. Configuration, logs and data land in `proton-data` under the current directory, so two instances launched from two shells in two folders become two unrelated engines unless you move that directory on purpose. Port exposure has a matching wrinkle: the sample publishes 8123 and 8463, then points you elsewhere for anything more, and a client such as DBeaver needs a port that sample never opens.

On upkeep, the project sits under Apache-2.0 and its last push was on 2026-09-20, with the three most recent builds v3.0.31 on 2026-09-17, v3.0.30 on 2026-09-01 and v3.0.29 on 2026-08-02. Usage coverage stops mid-sentence at "SQL is the main interface. You can start a", so nothing beyond `proton server` and `proton client` is spelled out for the command line. That examples/broken-stream-monitor/ sits in the example list at all is an honest signal that a broken stream is a routine condition to watch.

## What changes when you pick ksqlDB or Flink instead

Both named alternatives keep the pipeline inside the Kafka ecosystem. ksqlDB is the Kafka-native streaming SQL engine, Flink is the general stream processor, and Proton positions itself against both by dropping the JVM and the external coordination. The concrete difference claimed is where results land: a pure stream processor pushes output onward, while Proton keeps incremental materialized views inside the engine as queryable analytical and row based tables, ready for a dashboard to read.

The comparison has a hard edge. No side-by-side numbers exist in the repository, there is no guide for running either alternative against the same topic, and no migration notes exist for lifting an existing ksqlDB application over. For a team already standardised on one of them, switching cost decides this, not binary size.

A third path deserves weighing before either. Teams already running ClickHouse for storage can keep writing batch inserts into it and install no streaming engine at all. Proton exists to close the distance between event time and query time, and that distance is the entire reason to add it.

## Conclusion

Adopt Proton when a Kafka or Redpanda pipeline needs SQL windows, CDC and queryable materialized views without dragging in a JVM. Leave it alone if your production rules forbid an unpinned remote shell script or a :latest image, and hold the throughput claims until you measure your own topic shapes. Verify three gaps before anything else: what checksum the install script serves, which ports your clients actually need, and what `proton server` accepts beyond the current folder and the two published ports.

## FAQ

### How do I install Timeplus Proton and start it locally?

One command installs it: `curl https://install.timeplus.com/oss | sh`. Then run `proton server` in one terminal, which keeps configuration, logs and data in a `proton-data` folder in the current directory, and `proton client` in a second terminal for the SQL client. macOS users can instead run `brew install timeplus-io/timeplus/proton`.

### Which sources and sinks can Timeplus Proton read from and write to?

The native list covers Kafka, ClickHouse, MySQL, Postgres, MongoDB, S3 with Iceberg and OpenSearch. Pipelines can also route results to other Kafka topics or analytical stores, and forward cleaned telemetry to Splunk, Elastic or S3 after in-pipeline noise reduction and alerting.

### Does Timeplus Proton require a JVM, ZooKeeper or a cluster?

No. It ships as a single C++ binary under 500MB with no JVM and no ZooKeeper, and the project says it also runs on an AWS t2.nano instance with 1 vCPU and 0.5 GiB of memory. A Docker image and a Docker Compose example are provided as well.

### How do I connect an external tool such as DBeaver to Timeplus Proton?

The published Docker command publishes 8123 and 8463. The docs direct you to a separate Server Ports page to determine which ports to expose so that other tools can connect, since a client like DBeaver needs a port the sample command does not publish.

### Can I write my own functions in Timeplus Proton?

Yes, UDF in Python and JS are part of the feature list alongside streaming ingestion, multi-stream JOINs, incremental materialized views, alerting and Tasks. The README does not document a packaging or deployment procedure for user defined functions beyond that listing.

## Sources

- [License: Apache-2.0](https://github.com/timeplus-io/proton/blob/develop/LICENSE)
- [Project website](https://timeplus.com)
- [README](https://github.com/timeplus-io/proton/blob/develop/README.md)
- [Releases](https://github.com/timeplus-io/proton/releases)
- [timeplus-io/proton on GitHub](https://github.com/timeplus-io/proton)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/timeplus-io-proton