RisingWave vs DeltaStream: Serverless Streaming SQL Compared

RisingWave and DeltaStream are both serverless streaming SQL platforms that let data engineers build real-time pipelines without managing Apache Flink clusters. The key difference: RisingWave is open source (Apache 2.0) and available as a self-hosted database or a managed cloud service, while DeltaStream is a SaaS-only managed platform built on top of Flink. This comparison covers architecture, Kafka integration, SQL compatibility, pricing model, deployment options, and community support to help you choose the right tool.

The Serverless Streaming SQL Landscape

For most of the last decade, running streaming SQL meant operating an Apache Flink cluster. That meant provisioning TaskManagers, tuning RocksDB checkpoints, sizing JobManagers, and dedicating engineering headcount to keep the cluster healthy. The operational cost was high enough that streaming was impractical for teams without dedicated infrastructure expertise.

Serverless streaming SQL platforms change this calculus. Both RisingWave and DeltaStream abstract away cluster operations and let engineers write SQL to define streaming pipelines. But they take fundamentally different approaches to the underlying architecture, and those differences affect what you can build, how much it costs, and how much control you retain over your data and infrastructure.

Architecture Comparison

DeltaStream: Managed Flink as a Service

DeltaStream is a SaaS platform that wraps Apache Flink in a serverless abstraction. When you submit a SQL query, DeltaStream constructs a Flink streaming topology and runs it in an isolated, managed environment. Each query runs in its own isolated execution context, which means resource contention between queries is minimized and failed queries recover independently.

The DeltaStream Fusion platform (generally available in 2025) expands this to include ClickHouse and Apache Spark alongside Flink, offering a unified interface for streaming, real-time, and batch processing from a single SQL interface.

DeltaStream does not expose the underlying Flink cluster to users. You interact with the platform entirely through SQL, a web UI, a CLI, or a REST API. The Flink version, checkpoint configuration, and resource allocation are managed by DeltaStream.

This model has a real advantage: you get the power of Flink without Flink's operational complexity. The trade-off is that you cannot drop down to Flink's DataStream API for custom operators, you cannot inspect or tune checkpoint behavior, and you cannot run DeltaStream outside DeltaStream's cloud environment.

RisingWave: Purpose-Built Streaming Database

RisingWave is a distributed streaming database built from scratch in Rust. It is not a wrapper around Flink. The core architecture separates compute, storage, and metadata into independent layers:

• Compute nodes execute streaming operators and serve query results.
• Compactor nodes handle background compaction of storage.
• Object storage (S3, GCS, Azure Blob) persists all state and materialized view data through Hummock, RisingWave's purpose-built LSM-tree storage engine.
• Meta service coordinates cluster scheduling and barrier (checkpoint) management.

Because each layer scales independently, you can add compute without provisioning more storage, or grow state on S3 without adding compute nodes. There is no local RocksDB disk to manage and no checkpoint state that grows proportionally with compute.

RisingWave exposes a PostgreSQL-compatible SQL interface. Any PostgreSQL client, driver, or visualization tool connects directly. You query materialized views with a standard SELECT statement, and the results are always up to date. No separate serving database is needed.

Kafka Integration

Both platforms treat Apache Kafka as a first-class data source. The integration mechanisms differ in important ways.

DeltaStream's Store Abstraction

DeltaStream introduces a "store" abstraction to represent a Kafka cluster. You declare a store for your Kafka environment (whether self-hosted, Confluent Cloud, AWS MSK, or Redpanda), and then create streams that reference topics within that store.

-- DeltaStream syntax: declare a Kafka store
CREATE STORE my_kafka
  WITH (
    'type' = 'KAFKA',
    'kafka.bootstrap.server' = 'broker1:9092,broker2:9092'
  );

-- Then create a stream backed by a Kafka topic
CREATE STREAM clickstream (
    event_id     BIGINT,
    user_id      VARCHAR,
    page         VARCHAR,
    event_type   VARCHAR,
    ts           TIMESTAMP
) WITH (
    'store' = 'my_kafka',
    'topic' = 'clickstream',
    'value.format' = 'JSON'
);

DeltaStream also supports AWS Kinesis and is designed to provide a unified view across multiple streaming storage systems.

RisingWave's Direct Kafka Source

RisingWave connects to Kafka directly using a CREATE SOURCE or CREATE TABLE statement with a Kafka connector. No intermediate abstraction layer is required. You specify the bootstrap server, topic, and message format inline:

-- RisingWave: connect directly to a Kafka topic
CREATE SOURCE ds_kafka_events (
    event_id    BIGINT,
    user_id     VARCHAR,
    page        VARCHAR,
    event_type  VARCHAR,
    ts          TIMESTAMPTZ
) WITH (
    connector = 'kafka',
    topic = 'clickstream',
    properties.bootstrap.server = 'localhost:9092',
    scan.startup.mode = 'latest'
) FORMAT PLAIN ENCODE JSON;

RisingWave supports over 50 connectors including Kafka, Redpanda, Pulsar, Kinesis, PostgreSQL CDC, MySQL CDC, MongoDB CDC, and S3. You can join streams from different sources in a single materialized view without any manual data movement.

RisingWave can also write results back to Kafka as a sink, making it easy to build pipelines where downstream consumers read enriched or aggregated data from Kafka topics.

SQL Compatibility and Feature Depth

DeltaStream SQL

DeltaStream uses a SQL dialect designed for stream processing. It supports CREATE STREAM and CREATE CHANGELOG as the primary object types, with standard SQL for filtering, projection, and aggregation. The platform supports windowed aggregations, continuous queries, and materialized views.

DeltaStream also supports user-defined functions (UDFs and UDAFs) for custom logic that standard SQL cannot express.

Because DeltaStream is built on Flink, it inherits Flink's streaming semantics including event-time processing and watermarks. These are managed by the platform, so you do not configure them directly but benefit from them implicitly.

The SQL dialect is not PostgreSQL-compatible. You cannot connect standard PostgreSQL tooling (psql, DBeaver, Grafana via PostgreSQL data source, JDBC drivers) directly to DeltaStream. Interaction happens through the DeltaStream CLI, web UI, or REST API.

RisingWave SQL

RisingWave implements the PostgreSQL wire protocol. Literally any tool that works with PostgreSQL works with RisingWave without modification. This includes psql, DBeaver, Grafana, Metabase, Superset, dbt, JDBC, ODBC, and all major language drivers.

RisingWave's streaming pipelines are defined as materialized views, which are always incrementally maintained as data arrives. Here is a complete example: ingest clickstream events, compute per-page statistics in a tumbling window, and serve the results as a queryable view.

Step 1: Create the base table (or use a Kafka source)

CREATE TABLE ds_clickstream_events (
    event_id     BIGINT,
    user_id      VARCHAR,
    page         VARCHAR,
    event_type   VARCHAR,
    ts           TIMESTAMPTZ,
    PRIMARY KEY (event_id)
);

Step 2: Create a materialized view with a tumbling window

CREATE MATERIALIZED VIEW ds_page_stats AS
SELECT
    page,
    event_type,
    COUNT(*)                        AS event_count,
    COUNT(DISTINCT user_id)         AS unique_users,
    window_start,
    window_end
FROM TUMBLE(ds_clickstream_events, ts, INTERVAL '1 HOUR')
GROUP BY page, event_type, window_start, window_end;

Step 3: Query results with standard SELECT

SELECT * FROM ds_page_stats
WHERE page = '/pricing'
ORDER BY window_start DESC;

RisingWave also supports stream-table joins, which enrich streaming events with static or slowly-changing reference data in real time:

-- Join streaming events with a user profile table
CREATE MATERIALIZED VIEW ds_enriched_events AS
SELECT
    e.event_id,
    e.user_id,
    e.page,
    e.event_type,
    u.plan,
    u.region,
    e.ts
FROM ds_clickstream_events e
JOIN ds_user_profiles u ON e.user_id = u.user_id;

And cascading materialized views let you build multi-stage pipelines entirely in SQL, where one view reads from another:

-- Aggregate enriched events by plan and region
CREATE MATERIALIZED VIEW ds_plan_activity AS
SELECT
    plan,
    region,
    COUNT(*)                                        AS total_events,
    COUNT(DISTINCT user_id)                         AS unique_users,
    COUNT(*) FILTER (WHERE event_type = 'click')    AS clicks
FROM ds_enriched_events
GROUP BY plan, region;

This is the same pattern described in detail in Incremental Materialized Views Explained.

RisingWave also supports CTEs, subqueries, lateral joins, window functions (ROW_NUMBER, RANK, LAG, LEAD), and time-travel queries on historical state. The full PostgreSQL SQL surface area is available for both streaming and batch queries in the same interface.

Open Source vs SaaS: What This Means in Practice

This is the most consequential difference between the two platforms, and it affects far more than license cost.

DeltaStream is SaaS-Only

DeltaStream is a proprietary, fully managed cloud service. The source code is not publicly available. You cannot run DeltaStream on your own infrastructure, in your own VPC without DeltaStream's involvement, or on-premises.

DeltaStream does offer a "bring your own cloud" (BYOC) deployment option for regulated industries, where the compute runs in your cloud account while DeltaStream manages the control plane. But this is not the same as self-hosting: DeltaStream's control plane still operates the system.

The practical implications:

• Vendor lock-in is real. Your streaming pipelines are defined in DeltaStream's SQL dialect. Migrating to another platform requires rewriting queries.
• Data leaves your environment in standard SaaS mode. All data processed by DeltaStream passes through DeltaStream's infrastructure.
• Pricing is opaque. DeltaStream does not publish pricing. You must contact sales for a quote.
• No community edition. There is no free self-hosted version for development, testing, or smaller workloads.

RisingWave is Open Source with a Cloud Option

RisingWave is released under the Apache 2.0 license. The full source code is on GitHub. You can run it anywhere: Docker, Kubernetes, bare metal, or any cloud provider.

RisingWave Cloud is the managed version of the same open-source codebase, operated by RisingWave Labs. It offers a free tier for development and small workloads, and pay-as-you-go pricing for production.

The practical implications:

• No vendor lock-in. Your SQL is standard PostgreSQL-compatible SQL. If you start on RisingWave Cloud and decide to self-host, you take your SQL with you. If you later migrate to another PostgreSQL-compatible system, most queries transfer.
• Data stays in your environment for self-hosted deployments. You control the infrastructure.
• Transparent pricing. RisingWave Cloud publishes its pricing tiers. Self-hosted has no license cost.
• Community edition is full-featured. The open-source version has no artificial capability limits. The features you develop against locally are the same features that run in production.

For a detailed look at how the open-source model affects total cost of ownership, see Streaming Database Pricing: RisingWave vs Flink vs Confluent.

Pricing Model Comparison

RisingWave's open-source model means a team with existing Kubernetes infrastructure can run RisingWave at no software cost, paying only for compute and S3 storage. A cluster handling 100,000 events per second with 500 GB of state typically runs on three to five compute nodes plus S3, with total infrastructure costs well under $2,000 per month on most cloud providers.

DeltaStream's pricing is not published, which makes direct comparison impossible without a sales engagement. Managed Flink services from major cloud providers typically charge by the number of parallel operator instances (Flink Processing Units), and costs scale quickly for large state or high-throughput workloads.

Deployment Options

RisingWave's deployment flexibility makes it viable for a much wider range of environments. Teams in regulated industries (financial services, healthcare, government) that cannot send data outside their VPC can run RisingWave self-hosted with complete control. Teams in early development can run a single-node RisingWave with Docker Compose in minutes.

Community and Ecosystem

DeltaStream Community

DeltaStream is led by Hojjat Jafarpour, the creator of ksqlDB. The team brings genuine streaming SQL expertise. The company raised a $15M Series A in 2024.

DeltaStream does not have a public open-source community, because the platform is proprietary. There is no GitHub repository for the core product, no community Slack for users to exchange knowledge, and no ecosystem of community-contributed connectors or extensions. Support is provided through the DeltaStream team directly.

RisingWave Community

RisingWave has an active open-source community with thousands of GitHub stars and contributions from engineers at multiple companies. The project maintains a public Slack workspace, an active GitHub issue tracker, and a community forum.

Because RisingWave is PostgreSQL-compatible, it integrates directly with the broad PostgreSQL ecosystem: dbt for transformation, Grafana for visualization, Airbyte and Fivetran for ingestion, and hundreds of PostgreSQL-compatible tools. No custom integrations are needed.

RisingWave also participates in benchmarks and publishes results publicly. On the Nexmark streaming benchmark, RisingWave outperforms Apache Flink on 22 of 27 queries, with some queries running 10x faster due to RisingWave's incremental computation model.

When to Choose Each Platform

Choose DeltaStream if:

• You need a fully managed, zero-infrastructure experience with no self-hosting.
• Your team is already deeply invested in the Apache Flink ecosystem and wants managed Flink without operational overhead.
• You need the DeltaStream Fusion capabilities (combined streaming, real-time OLAP, and batch in one SaaS).
• You are comfortable with proprietary SaaS and have no regulatory constraint on data leaving your environment.
• Pricing negotiation with a vendor fits your procurement process.

Choose RisingWave if:

• You want open-source software you can run anywhere, audit, and extend.
• PostgreSQL compatibility matters, and you want your existing SQL knowledge, tooling, and drivers to work without changes.
• You need self-hosted deployment for regulatory, cost, or control reasons.
• You want transparent, published pricing and a free tier for development.
• You are connecting data from multiple source types beyond Kafka (CDC from databases, object storage, Kinesis, Pulsar).
• You want to avoid vendor lock-in and keep your streaming SQL portable.

For teams evaluating streaming databases more broadly, What Is a Streaming Database: Complete Guide covers the architectural patterns and tradeoffs across the full landscape.

Summary Comparison Table

FAQ

Is RisingWave truly serverless like DeltaStream?

RisingWave Cloud is a fully managed, serverless offering where you do not manage clusters, nodes, or infrastructure. Self-hosted RisingWave requires you to operate the cluster on Kubernetes or Docker, but the architecture (disaggregated compute and S3 storage) scales elastically without per-node state management. DeltaStream is serverless in the SaaS sense: all infrastructure is managed by DeltaStream on their cloud.

Can RisingWave replace DeltaStream for Kafka-based streaming pipelines?

Yes. RisingWave connects directly to Kafka topics as sources and can write results back to Kafka as sinks. You define streaming transformations, aggregations, and joins as materialized views using standard SQL. The primary difference is that RisingWave gives you more deployment options, PostgreSQL tooling compatibility, and the ability to join Kafka streams with CDC data from databases in the same query.

Does DeltaStream support PostgreSQL clients and drivers?

No. DeltaStream uses its own API surface (CLI, web UI, REST API with GraphQL). It does not implement the PostgreSQL wire protocol, so standard PostgreSQL drivers (JDBC, psycopg2, pg) and tools (psql, DBeaver, Grafana PostgreSQL data source) do not connect directly.

What happens to my streaming pipelines if I want to stop using DeltaStream?

Because DeltaStream is proprietary SaaS with its own SQL dialect and no self-hosted option, migrating away requires rewriting your streaming pipeline definitions in a different system's query language. With RisingWave, your pipelines use standard PostgreSQL-compatible SQL. If you move from RisingWave Cloud to self-hosted RisingWave, or to another PostgreSQL-compatible system, most SQL transfers with minimal or no changes.

RisingWave and DeltaStream both solve the problem of making streaming SQL accessible without Flink cluster management. DeltaStream provides a polished SaaS experience on top of proven Flink infrastructure. RisingWave provides open-source freedom, PostgreSQL compatibility, and multi-environment deployment at the cost of more responsibility in self-hosted scenarios.

For teams that want full control, transparent pricing, and no vendor lock-in, RisingWave's open-source model and PostgreSQL compatibility make it the more flexible choice. For teams that want zero infrastructure responsibility and are comfortable with managed SaaS pricing, DeltaStream is worth evaluating.

To get started with RisingWave, see RisingWave vs Apache Flink: A Practical Comparison for a deeper look at how the two approaches to streaming SQL differ in production.