Comparison with kSQLDB

[fabricebaranski]

What are the differences compare to kSQLDB?

[yingjunwu]

Hi @fabricebaranski - thanks for your interest. Both RisingWave and KsqlDB are distributed SQL streaming databases, but there are huge differences regarding both design and implementation. I'd like to give a very high-level overview of how there two products are different, from at least four perspectives: functionalities, cost, ease-of-use, and ecosystem.

Functionalities

• RisingWave is a database tailored for stream processing, and it includes all the major stream processing semantics and functionalities, including but not limited to: exactly-once semantics, windowing functiones, out-of-order processing (e.g., watermark), etc. Moreover, RisingWave can directly serve ad-hoc queries to analyze internal data.
• KsqlDB is more like a SQL wrapper on top of Kafka Stream. Unfortunately, it hasn't yet implemented some major stream processing functionalities, like out-of-order processing (e.g., watermark), and users cannot directly use KsqlDB to serve ad-hoc queries (e.g., you cannot connect your KsqlDB to a BI tool like Metabase).

Cost

• RisingWave is highly optimized. It achieves optimal cost-efficiency for several reasons: 1) materialized views in RisingWave can share computation resources, which attains very high CPU utilization rate; 2) RisingWave decouples compute and storage, and hence users can dynamically scale in/out compute and storage seperately; 3) RisingWave can be considered as a standalone system without cross-system communications at runtime; 4) RisingWave is implemented in Rust, which is highly cost-efficient.
• KsqlDB's cost can be high. 1) KsqlDB's stream processing jobs are maintained using different processes, and are unable to share computation resources efficiently; 2) It does not decouple compute and storage, which means if you want to scale in/out, you will have to scale in/out both compute and storage; 3) It's highly Kakfa-dependent - it uses Kafka for storage, for buffering, for communication, etc. Just imagine the cross-system cost; 4) It's written in Java (okay the local storage is maintained using C++-implemented RocksDB), and users need to think about how to manage JVM wisely.

Ease-of-use

• RisingWave is PostgreSQL-compatible. You can operate RisingWave in exactly the same way as you operate PostgreSQL. There's no wired SQL dialect, and you just use PostgreSQL-style SQL. You can use any system that can speak with PostgreSQL to talk to RisingWave - think about DBeaver, Metabase, Superset, dbt, etc. Connecting to RisingWave is simple - just use JDBC or any driver you like.
• KsqlDB has its own SQL dialect, and you will need to learn its own concept. It's not PostgreSQL-compatible, and cannot talk to any system listed above. There's no way to easily connect to KsqlDB - users have to use KsqlDB-specific toolings.

Ecosystem

• RisingWave does not have dependency on Kafka, and it can ingest data from whichever system you are using, from Redpanda, Apache Pulsar, to MySQL, PostgreSQL, MongoDB, etc. You can also deliver data to wherever you want, from Apache Iceberg, Delta Lake, to ClickHouse, Apache Druid, and many more.
• KsqlDB is just for Apacha Kafka, and you can only ingest data from Kafka and deliver data back to Kafka. Indeed, you can only use Confluent's Kafka - you may check the KsqlDB's license for details (meanwhile RisingWave is Apache 2.0 License).

I hope this helps, and feel free to give RisingWave a try. Any comment is welcome!