Open Source Streaming SQL: A Free Alternative to Confluent

Introduction

You started with Kafka. You added ksqlDB to run SQL on your streams. Then the bills arrived, and the constraints became clear: a proprietary license, mandatory Kafka coupling, custom SQL syntax that your team has to learn from scratch, and monthly costs that scale faster than your data.

This is the reality for many engineering teams running Confluent Cloud with ksqlDB. The promise of "streaming SQL" is real, but the implementation comes wrapped in vendor lock-in and escalating Confluent Streaming Unit (CSU) charges that can reach tens of thousands of dollars per month for production workloads.

There is another path. RisingWave is an open-source streaming database licensed under Apache 2.0. It speaks PostgreSQL-compatible SQL, ingests from Kafka, Pulsar, Kinesis, MySQL CDC, PostgreSQL CDC, and dozens of other sources, and stores results in persistent, queryable state. No Kafka dependency. No proprietary license. No surprise bills. This article walks you through a detailed comparison of Confluent ksqlDB and RisingWave, covering architecture, features, cost, and a practical migration path.

The Problem with Confluent ksqlDB

ksqlDB was introduced in 2017 as KSQL, a SQL layer on top of Kafka Streams. The idea was compelling: let developers write SQL instead of Java to process Kafka topics. But over the years, several limitations have become pain points for teams that adopted it.

Proprietary Licensing

ksqlDB is licensed under the Confluent Community License, not a true open-source license. This restricts you from offering ksqlDB as a competing SaaS product, and it means Confluent controls the roadmap. Unlike Apache 2.0 or MIT licenses, the Confluent Community License does not meet the Open Source Initiative's definition of open source. If your organization has strict open-source compliance policies, ksqlDB may not qualify.

Kafka Lock-in

ksqlDB only works with Apache Kafka. Every input must be a Kafka topic. Every output goes to a Kafka topic. If you want to ingest from Amazon Kinesis, Google Pub/Sub, Apache Pulsar, or a PostgreSQL CDC stream, you need Kafka Connect connectors as intermediaries, adding operational complexity and latency.

This tight coupling also means your ksqlDB scaling is tied to Kafka partition counts. You cannot scale compute independently from your message broker.

Limited SQL Capabilities

ksqlDB uses a custom SQL dialect that is not ANSI SQL compliant. It lacks support for subqueries, common table expressions (CTEs), non-equi joins, and many standard SQL functions that data engineers expect. If your team already knows PostgreSQL or any standard SQL database, you still have to learn ksqlDB's specific syntax and its unique concepts like STREAM and TABLE declarations.

Rising Costs

Confluent Cloud charges for ksqlDB in Confluent Streaming Units (CSUs). A ksqlDB application requires a minimum of 4 CSUs, with options for 8 or 12. At approximately $0.23 per CSU per hour, even a minimal ksqlDB deployment costs roughly $670 per month before you factor in Kafka cluster costs, connector costs, Schema Registry, and data transfer fees. Production workloads with moderate throughput can easily push total Confluent bills into the $5,000-$20,000 per month range.

Uncertain Future

Confluent has been investing heavily in Apache Flink on Confluent Cloud, positioning Kafka plus Flink as the primary stream processing stack. While ksqlDB has not been officially deprecated, the community has noticed a slowdown in feature development and a strategic pivot toward Flink. This raises reasonable questions about ksqlDB's long-term trajectory.

RisingWave: The Open-Source Alternative

RisingWave is a distributed streaming database built from the ground up for real-time stream processing. Rather than wrapping a message broker's API in a SQL-like syntax, RisingWave is a full database that happens to process streams incrementally.

Apache 2.0 License

RisingWave is licensed under Apache 2.0, the most permissive widely-used open-source license. You can use it, modify it, distribute it, and build commercial products on top of it with zero restrictions. No "community license" caveats, no SaaS usage restrictions.

PostgreSQL Compatibility

RisingWave speaks PostgreSQL wire protocol. You connect to it with psql, any PostgreSQL driver, or any tool in the PostgreSQL ecosystem. Your team's existing SQL knowledge transfers directly. Complex joins, subqueries, CTEs, window functions, and UDFs (in Python, Java, and JavaScript) all work as expected.

-- Connect with any PostgreSQL client
-- psql -h localhost -p 4566 -U root -d dev

-- This is standard SQL, not a custom dialect
SELECT
    product_id,
    COUNT(*) AS order_count,
    SUM(amount) AS total_revenue,
    AVG(amount) AS avg_order_value
FROM orders
WHERE order_time > NOW() - INTERVAL '1 hour'
GROUP BY product_id;

Multi-Source Ingestion

RisingWave does not depend on Kafka. It natively connects to:

• Message brokers: Apache Kafka, Amazon MSK, Redpanda, Apache Pulsar, Amazon Kinesis, Google Pub/Sub, NATS, MQTT
• Databases (CDC): PostgreSQL, MySQL, MongoDB, SQL Server, TiDB
• Storage: Amazon S3, Google Cloud Storage, Apache Iceberg
• Other: Webhooks, Datagen (for testing)

You can even join a Kafka stream with a PostgreSQL CDC stream in a single SQL query, something that would require multiple Kafka Connect connectors and complex routing in the Confluent ecosystem.

Persistent, Queryable State

Unlike ksqlDB, which stores intermediate state in Kafka's internal topics (making it hard to query directly), RisingWave persists results in its own storage layer backed by S3-compatible object storage. You can run ad-hoc analytical queries on materialized views at any time without routing data to yet another database.

Independent Scaling

RisingWave's architecture decouples compute from storage. You scale processing nodes independently of your storage or message broker. There is no dependency on Kafka partition counts for parallelism.

Feature Comparison Matrix

Here is a side-by-side comparison of ksqlDB and RisingWave across the dimensions that matter most for production stream processing:

Cost Comparison: Confluent Cloud vs. RisingWave

Cost is often the catalyst that pushes teams to evaluate alternatives. Here is a realistic comparison for a mid-sized streaming workload.

Scenario

Consider a team processing 50 million events per day across 10 streaming queries (materialized views) with moderate state size.

Confluent Cloud with ksqlDB

And this is for a moderate workload. High-throughput production deployments with dedicated clusters, governance features, and multiple ksqlDB applications regularly exceed $15,000 per month.

RisingWave (Self-Hosted)

Self-hosted RisingWave on Kubernetes can reduce costs by 50-70% compared to Confluent Cloud. The Apache 2.0 license means there are no license fees, no per-CSU charges, and no surprise cost multipliers.

RisingWave Cloud (Managed)

RisingWave Cloud offers a managed experience starting at $0.227 per RisingWave Unit (RWU) per hour, with a free trial to get started. For the same workload, a managed RisingWave deployment typically costs 30-50% less than the equivalent Confluent Cloud stack because you eliminate the separate Kafka cluster requirement for many use cases.

The Hidden Cost: Kafka Dependency

One cost factor that is easy to overlook: ksqlDB requires Kafka. If you are already running Kafka, this is a sunk cost. But if your primary data sources are not Kafka-native (e.g., PostgreSQL CDC, Kinesis, or S3), you are paying for a Kafka cluster purely to serve as an intermediary. RisingWave eliminates this middleman for non-Kafka sources.

Migration Path: From ksqlDB to RisingWave

Moving from ksqlDB to RisingWave is more straightforward than most migration projects because both systems use SQL as the primary interface. Here is a practical migration approach.

Step 1: Audit Your ksqlDB Queries

List all your ksqlDB STREAM and TABLE definitions, persistent queries, and materialized views. Identify which ones use Kafka-specific features versus standard SQL patterns.

-- ksqlDB: List running queries
SHOW QUERIES;

-- ksqlDB: List streams and tables
SHOW STREAMS;
SHOW TABLES;

Step 2: Translate SQL Syntax

Most ksqlDB queries translate to RisingWave with minor changes. Here are common patterns:

ksqlDB source definition:

-- ksqlDB syntax
CREATE STREAM orders (
    order_id VARCHAR KEY,
    customer_id VARCHAR,
    amount DOUBLE,
    order_time TIMESTAMP
) WITH (
    kafka_topic='orders',
    value_format='JSON'
);

RisingWave equivalent:

-- RisingWave syntax (PostgreSQL-compatible)
CREATE SOURCE orders (
    order_id VARCHAR,
    customer_id VARCHAR,
    amount DOUBLE PRECISION,
    order_time TIMESTAMPTZ
) WITH (
    connector = 'kafka',
    topic = 'orders',
    properties.bootstrap.server = 'kafka:9092'
) FORMAT PLAIN ENCODE JSON;

ksqlDB aggregation:

-- ksqlDB syntax
CREATE TABLE order_totals AS
SELECT customer_id,
       COUNT(*) AS order_count,
       SUM(amount) AS total_spent
FROM orders
WINDOW TUMBLING (SIZE 1 HOUR)
GROUP BY customer_id
EMIT CHANGES;

RisingWave equivalent:

-- RisingWave syntax
CREATE MATERIALIZED VIEW order_totals AS
SELECT customer_id,
       COUNT(*) AS order_count,
       SUM(amount) AS total_spent,
       window_start,
       window_end
FROM TUMBLE(orders, order_time, INTERVAL '1 hour')
GROUP BY customer_id, window_start, window_end;

Step 3: Set Up Dual-Write (Parallel Run)

Run RisingWave alongside ksqlDB during the migration period. Point RisingWave at the same Kafka topics your ksqlDB queries consume. Compare outputs to verify correctness before cutting over.

Step 4: Migrate Downstream Consumers

Since RisingWave supports PostgreSQL wire protocol, downstream applications can query materialized views directly using any PostgreSQL client. For applications that consume from Kafka topics produced by ksqlDB, configure RisingWave sinks to write results to the same Kafka topics.

Step 5: Decommission ksqlDB

Once all queries are validated and downstream consumers are migrated, shut down your ksqlDB instances. If you were running Kafka solely as an intermediary for non-Kafka sources, evaluate whether you can connect RisingWave directly to those sources and reduce your Kafka footprint.

When to Choose Which

Not every team should switch. Here is an honest assessment of when each tool fits best.

Choose Confluent ksqlDB if:

• Your entire data pipeline is Kafka-native and you have no non-Kafka sources
• You are already deeply invested in the Confluent ecosystem (Schema Registry, Kafka Connect, Confluent Control Center)
• Your team prefers a fully managed, single-vendor solution and budget is not a primary concern
• Your streaming queries are simple aggregations and filters that do not require complex SQL

Choose RisingWave if:

• You need to ingest from multiple sources beyond Kafka (Pulsar, Kinesis, PostgreSQL CDC, MySQL CDC, S3)
• You want PostgreSQL-compatible SQL and the ability to use existing PostgreSQL tools
• Open-source licensing matters for compliance, auditability, or avoiding vendor lock-in
• Cost optimization is a priority, especially for mid-to-large workloads
• You need complex SQL features like subqueries, CTEs, non-equi joins, or advanced window functions
• You want queryable, persistent state without routing data to a separate analytical database
• You want flexibility to self-host on Kubernetes or use a managed cloud service

What Is the Difference Between ksqlDB and RisingWave?

ksqlDB is a SQL interface built on top of Kafka Streams, designed exclusively for processing Apache Kafka topics. It uses a custom SQL dialect and requires a running Kafka cluster. RisingWave is a standalone streaming database with PostgreSQL-compatible SQL that can ingest from Kafka, Pulsar, Kinesis, databases via CDC, and other sources without requiring any specific message broker. RisingWave also stores state persistently in S3-compatible storage, while ksqlDB relies on Kafka internal topics and local RocksDB for state management.

Can I Use RisingWave with My Existing Kafka Cluster?

Yes. RisingWave has a native Kafka connector that consumes from Kafka topics with full support for Avro, JSON, Protobuf, and CSV formats. You can point RisingWave at your existing Kafka topics and run it alongside ksqlDB during migration. RisingWave can also produce results back to Kafka topics using its sink connector, making it a drop-in replacement for ksqlDB in Kafka-centric pipelines.

Is RisingWave Really Free?

The core RisingWave engine is 100% free under the Apache 2.0 license. You can download it from GitHub, run it on your own infrastructure, modify the source code, and use it in commercial products without any license fees. For teams that prefer a managed service, RisingWave Cloud offers a pay-as-you-go model with a free trial. The self-hosted option has no usage limits, no CSU-style metering, and no feature gating.

How Hard Is It to Migrate from ksqlDB to RisingWave?

Migration difficulty is moderate and depends on the complexity of your ksqlDB queries. Simple aggregations, filters, and joins translate almost directly, requiring only syntax adjustments (e.g., changing CREATE STREAM to CREATE SOURCE, and CREATE TABLE AS to CREATE MATERIALIZED VIEW). The biggest effort is typically in reconfiguring downstream consumers if they read from ksqlDB-produced Kafka topics. RisingWave can produce to the same topics via its Kafka sink, which simplifies this transition. Most teams complete the migration in one to three sprints.

Conclusion

The streaming SQL landscape has evolved significantly since ksqlDB first launched. What was once the only way to run SQL on Kafka streams is now one option among several, and its proprietary license, Kafka-only constraint, and escalating costs make it a less competitive choice in 2026.

RisingWave offers a genuine open-source alternative that goes beyond what ksqlDB provides:

• True open source under Apache 2.0, with no licensing restrictions
• PostgreSQL-compatible SQL that your team already knows
• Multi-source ingestion from Kafka, Pulsar, Kinesis, databases, and object storage
• Persistent, queryable state backed by S3-compatible storage
• 50-70% lower costs for equivalent workloads compared to Confluent Cloud
• Advanced SQL features including subqueries, CTEs, non-equi joins, and full window functions

If you are paying Confluent bills that keep growing, wrestling with ksqlDB's SQL limitations, or locked into Kafka when your data lives elsewhere, it is worth running RisingWave alongside your current stack and seeing the difference firsthand.

Ready to try RisingWave? Get started in 5 minutes with the open-source edition. Quickstart guide

Join our Slack community to ask questions and connect with other stream processing developers.