RisingWave vs Timeplus: Comparing Streaming Databases

RisingWave and Timeplus are both streaming databases that let you query real-time data with SQL, but they are built on different foundations and solve different operational challenges. RisingWave is an Apache 2.0-licensed PostgreSQL-compatible streaming database built in Rust, designed for cloud-native deployments with disaggregated S3-backed storage. Timeplus Proton is an Apache 2.0-licensed streaming SQL engine built in C++ on top of the ClickHouse engine, designed as a lightweight single-binary tool for local and edge deployments.

This comparison covers six dimensions: architecture, PostgreSQL compatibility, Kafka integration, SQL feature parity, deployment options, and community. The goal is to give data engineers an objective basis for evaluating which tool fits their streaming workload.

Architecture: ClickHouse-Based Single Binary vs Cloud-Native Disaggregated Storage

The most fundamental difference between Timeplus and RisingWave is their storage and execution architecture.

Timeplus: ClickHouse Engine with Streaming Extensions

Timeplus Proton extends the ClickHouse columnar engine with streaming SQL capabilities. ClickHouse was originally designed for fast analytical queries over historical data stored in column-oriented files. Timeplus adds streaming concepts on top: a dual-layer storage model that separates a streaming layer (recent data, similar to a Kafka consumer position) from a historical layer (persisted columnar files).

This design runs as a single binary under 500 MB with no external dependencies. There is no JVM, no ZooKeeper, and no object storage tier required. Proton stores data locally and processes queries using ClickHouse's vectorized query engine.

The Timeplus Enterprise edition, the commercial product, extends Proton with multi-node clustering, mutable streams, role-based access control, and cloud-hosted managed service options.

RisingWave: Purpose-Built Streaming Database with Disaggregated Storage

RisingWave is a distributed streaming database built from scratch in Rust. Its architecture separates compute, storage, and metadata into independent layers:

• Compute nodes run streaming operators and serve queries over the PostgreSQL protocol.
• Compactor nodes handle background compaction of storage files.
• Object storage (Amazon S3, GCS, or Azure Blob Storage) persists all state and materialized view results via Hummock, a purpose-built LSM-tree storage engine.
• A meta node coordinates checkpointing, scheduling, and cluster metadata.

Because each layer scales independently, you can add compute capacity without provisioning more disk, and state storage scales elastically with object storage -- no local SSD sizing required. Checkpoints write only metadata (not gigabytes of local state), so they complete in milliseconds regardless of how large your state grows.

Architectural Trade-offs

The single-binary simplicity of Timeplus Proton is a genuine advantage for local development, edge deployments, and small teams that do not want to operate cloud infrastructure. RisingWave's disaggregated design becomes the better fit when state size grows beyond local disk capacity, when workloads need independent compute and storage scaling, or when cloud-native recovery guarantees are required.

PostgreSQL Compatibility: Native Protocol vs Custom Wire Protocol

PostgreSQL compatibility is an important dimension for teams that want to use existing SQL tooling, BI connectors, and application drivers without writing custom integration code.

Timeplus: ClickHouse-Derived SQL Dialect

Timeplus inherits ClickHouse's SQL dialect rather than PostgreSQL's. The query syntax shares surface-level similarities with ANSI SQL but introduces Timeplus-specific semantics for streaming: queries run against a stream by default and return only future events, while table() wraps a stream to query historical data.

-- Timeplus: query future events from a stream (streaming mode)
SELECT user_id, url FROM clickstream;

-- Timeplus: query historical data stored in a stream (batch mode)
SELECT user_id, url FROM table(clickstream);

Timeplus does not implement the PostgreSQL wire protocol. This means psql, JDBC PostgreSQL drivers, SQLAlchemy with the psycopg2 adapter, Grafana's PostgreSQL data source, and most BI tools that expect a PostgreSQL-compatible endpoint do not connect to Timeplus out of the box. Timeplus provides its own REST API, a Python SDK, and a web console for query access.

RisingWave: Full PostgreSQL Wire Protocol

RisingWave implements the PostgreSQL wire protocol. Any client that speaks PostgreSQL connects directly -- psql, DBeaver, TablePlus, JDBC, Python's psycopg2, Node.js pg, Grafana's PostgreSQL data source, and Apache Superset all work without modification.

-- Connect with psql, exactly as you would with PostgreSQL
-- psql -h localhost -p 4566 -U root -d dev

-- Standard PostgreSQL syntax works out of the box
CREATE TABLE tpcmp_orders (
  order_id BIGINT,
  region    VARCHAR,
  amount    DOUBLE PRECISION,
  order_time TIMESTAMPTZ
);

CREATE MATERIALIZED VIEW tpcmp_regional_revenue AS
SELECT
    region,
    COUNT(*)       AS order_count,
    SUM(amount)    AS total_revenue,
    AVG(amount)    AS avg_order_value
FROM tpcmp_orders
GROUP BY region;

-- Query the materialized view like any PostgreSQL table
SELECT * FROM tpcmp_regional_revenue WHERE total_revenue > 1000;

The materialized view above is incrementally maintained as new rows arrive in tpcmp_orders. The SELECT query on the last line reads the pre-computed result with sub-millisecond latency, no re-scanning required.

For teams that already have PostgreSQL-compatible tooling in their data stack, RisingWave's compatibility means zero additional integration work. For teams building on ClickHouse or running Timeplus for observability alongside ClickHouse analytics, Timeplus's ClickHouse-native foundation is a cohesive choice.

Kafka Integration: External Streams vs Native Source Connectors

Kafka integration is a core requirement for most streaming database deployments. Both tools connect to Kafka, but the integration approach differs in syntax, configuration, and operational model.

Timeplus: External Streams as Kafka Topics

Timeplus reads from Kafka using the CREATE EXTERNAL STREAM command. External streams are not stored in Timeplus's own storage -- they are thin wrappers that map Timeplus SQL queries to Kafka consumer operations:

-- Timeplus: create a Kafka external stream
CREATE EXTERNAL STREAM timeplus_orders_stream (
  order_id   INT,
  region     STRING,
  amount     FLOAT
)
SETTINGS
  type     = 'kafka',
  brokers  = 'kafka:9092',
  topic    = 'orders',
  data_format = 'JSONEachRow';

-- Query the stream (returns future events only)
SELECT region, SUM(amount)
FROM timeplus_orders_stream
GROUP BY region;

External streams support Kafka, Confluent Cloud, and Redpanda. Supported data formats include JSONEachRow, CSV, TSV, Avro, ProtobufSingle, and RawBLOB. The seek_to setting allows replaying from earliest, a specific offset, or a timestamp.

Timeplus Enterprise adds sinks back to Kafka, allowing materialized view results to be continuously written to output topics.

RisingWave: Native Source Connectors with Persistent State

RisingWave reads from Kafka using CREATE SOURCE or CREATE TABLE ... WITH (connector = 'kafka'). The difference matters: a source feeds data into materialized views but does not store data itself, while a table ingests Kafka events into RisingWave's own storage, making them queryable directly.

-- RisingWave: Kafka source using the kafka connector
CREATE SOURCE tpcmp_orders_source (
  order_id   BIGINT,
  region     VARCHAR,
  amount     DOUBLE PRECISION,
  order_time TIMESTAMPTZ
)
WITH (
  connector                     = 'kafka',
  topic                         = 'orders',
  properties.bootstrap.server   = 'kafka:9092',
  scan.startup.mode             = 'earliest'
)
FORMAT PLAIN ENCODE JSON;

-- Build an incrementally maintained aggregation on top of the source
CREATE MATERIALIZED VIEW tpcmp_orders_per_minute AS
SELECT
    region,
    window_start,
    window_end,
    COUNT(*)    AS order_count,
    SUM(amount) AS window_revenue
FROM TUMBLE(tpcmp_orders_source, order_time, INTERVAL '1 MINUTE')
GROUP BY region, window_start, window_end;

RisingWave supports over 50 source and sink connectors, including Apache Kafka, Apache Pulsar, Redpanda, Amazon Kinesis, NATS, PostgreSQL CDC, MySQL CDC, MongoDB CDC, and Amazon S3. On the output side, RisingWave can sink to Apache Iceberg, Delta Lake, Snowflake, ClickHouse, Elasticsearch, StarRocks, and more.

The RisingWave Kafka connector is one of the most mature in the project's connector library. It supports exactly-once delivery semantics, schema auto-detection, Avro with Schema Registry, Protobuf, and JSON. The connector has been production-tested across hundreds of deployments.

Kafka Integration Comparison

SQL Feature Parity: Windowing, Joins, and Materialized Views

Both systems support streaming SQL with windowed aggregations, joins, and materialized views. The feature surface differs in specific areas that matter for production workloads.

Windowing Functions

Both systems support tumbling (non-overlapping) and hopping/sliding (overlapping) windows. RisingWave uses SQL-standard TUMBLE() and HOP() table functions; Timeplus uses a tumble() and hop() function with similar semantics.

RisingWave also supports session windows through the SESSION() table function, which groups events that occur within a configurable gap of each other. Timeplus does not document session window support in Proton.

-- RisingWave: sliding window with HOP
CREATE MATERIALIZED VIEW tpcmp_sliding_revenue AS
SELECT
    region,
    window_start,
    window_end,
    SUM(amount) AS sliding_revenue
FROM HOP(tpcmp_orders, order_time, INTERVAL '30 SECONDS', INTERVAL '2 MINUTES')
GROUP BY region, window_start, window_end;

Stream-Table Joins

Both systems support joining a streaming source against a dimension table. RisingWave supports equi-joins, non-equi joins (range conditions), interval joins (events within a time window of each other), and temporal joins against slowly-changing dimensions. It also supports full multi-way joins and subqueries within materialized views.

Timeplus supports stream-to-stream joins and stream-to-table lookups. Windowed joins require a BETWEEN clause that constrains the time range.

Cascading Materialized Views

RisingWave supports cascading materialized views, where one materialized view reads from another. This lets you build multi-stage pipelines entirely in SQL:

-- Stage 1: regional aggregation
CREATE MATERIALIZED VIEW tpcmp_regional_revenue AS
SELECT
    region,
    COUNT(*)    AS order_count,
    SUM(amount) AS total_revenue
FROM tpcmp_orders
GROUP BY region;

-- Stage 2: filter high-value regions from Stage 1
CREATE MATERIALIZED VIEW tpcmp_high_value_regions AS
SELECT region, total_revenue, order_count
FROM tpcmp_regional_revenue
WHERE total_revenue > 100000;

Timeplus supports materialized views that read from streams, and those views can feed into further downstream views. However, cascading depth for window aggregations is limited to two levels, and global aggregations cannot be layered over window aggregations.

CTEs and Subqueries

Both systems support CTEs (WITH clauses) and subqueries. One limitation in Timeplus is that column aliases defined inside a CTE are not accessible outside it, which requires workarounds in some query patterns.

User-Defined Functions

RisingWave supports Python UDFs that run in an external process via gRPC, Java UDFs, Rust UDFs, and JavaScript UDFs. Timeplus Proton supports Python and JavaScript UDFs.

Open Source Status and Licensing

Both projects use the Apache 2.0 license for their open-source components, but the boundary between open source and commercial differs significantly.

Timeplus: Split Between Proton and Enterprise

Timeplus Proton, the open-source engine, is released under Apache 2.0 and is available on GitHub with approximately 2,200 stars. Proton covers single-node deployments, Kafka external streams, materialized views, and the core streaming SQL engine.

Several features are reserved for Timeplus Enterprise, the commercial product:

• Mutable streams (streams that support updates and deletes, not just appends)
• Multi-node clustering for horizontal scaling
• Role-based access control and user management
• Managed cloud service

This means a team building on Proton may eventually hit a ceiling -- if they need mutable data or horizontal scale, they need to move to Timeplus Enterprise. That transition involves a license change and (typically) a vendor conversation.

RisingWave: Full-Featured Open Source Core

RisingWave's core streaming database -- including multi-node clustering, materialized views, CDC connectors, Kafka connectors, windowed aggregations, and all SQL features -- is released under Apache 2.0 and available on GitHub with over 7,300 stars.

The commercial offering, RisingWave Cloud, is a fully managed hosted service. It adds operational features (monitoring dashboards, autoscaling, point-in-time restore) but does not gate core database functionality behind a commercial license. A team self-hosting RisingWave on Kubernetes gets the same SQL and connector feature set as a team using the cloud service.

This distinction matters for teams that prioritize avoiding vendor lock-in or need to run entirely in an air-gapped environment. RisingWave's open-source boundary includes everything needed for a production-grade streaming database deployment.

Cloud vs Self-Hosted Deployment

Timeplus Deployment Options

Timeplus Proton deploys as a single binary on Linux, macOS, or via Docker. For development and local testing, this is its biggest advantage: download the binary, run it, connect with the web console or REST API, and start writing streaming SQL in minutes.

For production multi-node deployments, Timeplus Enterprise is required. Enterprise supports Kubernetes deployment and bare-metal installation. The managed cloud service (Timeplus Cloud) provides a hosted version of Timeplus Enterprise with a web console, automatic upgrades, and monitoring.

RisingWave Deployment Options

RisingWave runs in multiple modes depending on the environment:

• Playground mode: Single binary for development and evaluation, risingwave playground
• Kubernetes: Helm chart and Kubernetes Operator for production self-hosted deployments
• Docker Compose: Multi-node local setup for development validation
• RisingWave Cloud: Fully managed hosted service on AWS, with automatic scaling, monitoring, and upgrades

The RisingWave Kubernetes Operator supports declarative cluster configuration, rolling upgrades without manual savepoints, and independent scaling of compute and compactor nodes.

For self-hosted production workloads, both tools require infrastructure investment. Timeplus Enterprise clustering requires a commercial license. RisingWave clustering is fully open source and runs on any Kubernetes environment.

Community and Documentation

RisingWave's documentation covers the full product surface including SQL command reference, connector configuration, deployment guides, and benchmark results. The community Slack is active with responses from the engineering team.

Timeplus's documentation is well-organized and covers Proton clearly, with distinct pages for open-source and Enterprise features. The project is smaller and the Proton repository reflects a more focused scope.

Full Feature Comparison Table

When to Choose Timeplus

Timeplus Proton is the better fit when:

• Single-node simplicity is the priority. If your streaming workload fits on one machine and you want the least operational overhead, Proton's single binary with no external dependencies is hard to beat.
• You are already on ClickHouse. Timeplus integrates natively with ClickHouse, making it a natural extension for teams that use ClickHouse for historical analytics and want to add a streaming layer using the same SQL dialect and data types.
• Edge or embedded deployments. The sub-500 MB binary with no external dependencies makes Timeplus Proton practical for edge hardware, IoT gateways, or observability pipelines running close to the data source.
• Performance claims over small datasets. Timeplus's ClickHouse vectorized engine delivers very low latency for single-node workloads.

When to Choose RisingWave

RisingWave is the better fit when:

• Your team thinks in PostgreSQL SQL. Any engineer who knows PostgreSQL can write RisingWave queries, create materialized views, and connect their existing tools without learning a new dialect.
• You need PostgreSQL-compatible tooling. Grafana, Superset, DBeaver, Metabase, JDBC, psycopg2, and any other PostgreSQL client connects to RisingWave without configuration changes.
• State grows beyond local disk. RisingWave stores all state in S3-compatible object storage, so there is no local disk capacity ceiling on your streaming pipelines.
• You need CDC sources in open source. RisingWave's built-in CDC connectors for PostgreSQL, MySQL, and MongoDB are part of the open-source release. Timeplus requires Enterprise for mutable/CDC-style patterns.
• Kafka sinks are required. Writing materialized view results back to Kafka topics is part of RisingWave's open-source connector library.
• Multi-node clustering without a commercial license. RisingWave scales horizontally as open source. Timeplus Proton is single-node; clustering requires Timeplus Enterprise.
• You want to grow from startup to scale. The open-source RisingWave feature set -- including clustering, connectors, and all SQL features -- does not change when workloads grow. There is no feature ceiling that forces a license upgrade.

Frequently Asked Questions

What is the main difference between RisingWave and Timeplus?

RisingWave is a PostgreSQL-compatible streaming database built in Rust with disaggregated cloud-native storage. Timeplus Proton is a lightweight streaming SQL engine built in C++ on top of ClickHouse, designed as a single-binary tool for local and edge deployments. The most practical differences are: RisingWave speaks the PostgreSQL wire protocol (psql and JDBC work directly), while Timeplus uses ClickHouse-derived SQL and a REST API; and RisingWave includes multi-node clustering and Kafka sinks in its open-source release, while Timeplus reserves those for its commercial Enterprise edition.

Can RisingWave replace Timeplus for Kafka stream processing?

Yes, for most Kafka-based streaming workloads. RisingWave's Kafka connector supports reading from topics, writing materialized view results back to Kafka, exactly-once semantics, Avro with Schema Registry, and Protobuf. It also supports Confluent Cloud, Redpanda, and other Kafka-compatible brokers. For teams that need PostgreSQL-compatible SQL over Kafka streams, RisingWave covers the full use case within its open-source release.

Is Timeplus Proton truly open source?

Yes, Timeplus Proton is released under the Apache 2.0 license. However, several production-critical features -- including mutable streams (equivalent to CDC table support), multi-node clustering, and role-based access control -- are only available in Timeplus Enterprise, the commercial product. RisingWave's Apache 2.0 open-source release includes all of those features, including CDC connectors and horizontal scaling.

Which streaming database is easier to get started with?

For local development and quick experiments, Timeplus Proton's single binary with no external dependencies starts faster. For teams that already use PostgreSQL clients, RisingWave's playground mode (risingwave playground) starts just as quickly and connects immediately with psql, DBeaver, or any JDBC driver without any additional setup.

Conclusion

RisingWave and Timeplus serve overlapping but distinct use cases.

Timeplus Proton is the stronger choice for single-node simplicity, ClickHouse ecosystem integration, and edge deployments where operational footprint matters most. Its single binary requires no infrastructure, which is a real advantage for the right environment.

RisingWave is the stronger choice for teams that want a full-featured open-source streaming database without feature restrictions, need PostgreSQL tool compatibility, require CDC sources or Kafka sinks without a commercial license, or are building workloads that will eventually scale beyond a single machine.

Key takeaways for data engineers:

• Open source scope: RisingWave's open-source release includes clustering, CDC connectors, Kafka sinks, and all SQL features. Timeplus requires Enterprise for clustering and mutable streams.
• PostgreSQL compatibility: RisingWave implements the full PostgreSQL wire protocol. Timeplus uses ClickHouse-derived SQL with a REST API.
• Kafka maturity: Both tools connect to Kafka, but RisingWave's Kafka connector is more mature and covers sink operations in open source.
• Deployment model: Timeplus Proton is simpler to start locally. RisingWave scales to distributed production deployments on Kubernetes without a license change.
• Scale model: RisingWave's storage is unbounded (S3). Timeplus Proton is constrained by local disk unless you move to Enterprise.

For teams evaluating streaming databases in 2026, the decision often comes down to one question: do you need a lightweight local SQL engine for streaming data, or a cloud-native streaming database that plugs into your existing PostgreSQL tool ecosystem? Timeplus Proton answers the first question. RisingWave answers the second.

Want to try RisingWave? You can start in under five minutes. Quickstart guide

Connect with the community on Slack or browse the connector documentation to see what RisingWave works with today.