We’re thrilled to unveil RisingWave v2.4, packed with enhancements designed to elevate your real-time data processing capabilities. This release brings enhanced performance analysis, expanded data storage and sinking capabilities, new SQL commands, and much more.
Follow along to learn more about some of the standout features in this version release. If you are interested in the full list of v2.4 updates, see the full release note.
Runtime profiling with EXPLAIN ANALYZE
You can now inspect the actual runtime performance of a streaming job using the new EXPLAIN ANALYZE command.
Unlike the traditional EXPLAIN, which only shows the query plan before execution, EXPLAIN ANALYZE provides runtime statistics—including output rates and buffer metrics—for running jobs such as materialized views, sinks, or indexes. It is enabled by default and helps pinpoint performance bottlenecks in complex streaming pipelines.
To learn more about its syntax and the key performance metrics it reports, see EXPLAIN ANALYZE.
Physical plans with DESCRIBE FRAGMENTS
Understand how a streaming job is physically executed with the new DESCRIBE FRAGMENTS command. This tool helps you visualize distributed execution fragments—including fragment IDs, actor assignments, and operator topology—making it easier to debug, tune parallelism, and optimize streaming applications.
DESCRIBE FRAGMENTS command works on existing running jobs and offers insights similar to EXPLAIN (DISTSQL), but with live job mappings.
Check out more examples in our documentation.
Append-only tables with Iceberg table engine
RisingWave v2.4 enhances its integration with Apache Iceberg by introducing support for append-only tables. The key implication is that data written to these append-only tables becomes available to downstream streaming jobs (such as materialized views or sinks built upon them) only after it has been successfully committed to the Iceberg table. These downstream jobs will then consume data via RisingWave's Iceberg streaming source capabilities.
This option is particularly beneficial for use cases where Iceberg serves as the primary data lake storage, and you prefer a direct, commit-based integration, aligning streaming operations closely with data lake commit cycles.
For more information, see Append-only tables.
Enhanced Redis sink: Pub/Sub messaging
Expanding its sink connector capabilities, RisingWave now supports publishing messages to Redis channels using the Pub/Sub model. This feature facilitates real-time notifications, event-driven architectures, or inter-service communication using Redis's robust Pub/Sub mechanism.
You have the flexibility to publish messages to a predefined, static Redis channel using the channel parameter. Alternatively, for more dynamic routing, you can use the channel_column parameter. With channel_column, the value from a specified column in your streaming data dynamically determines the target Redis channel for each message, offering greater control over message distribution.
For more information, see Sink data from RisingWave to Redis.
Implementing Row-Level Security (RLS)
RisingWave v2.4 provides a robust method to implement row-level security (RLS). This approach involves a powerful combination of logical views and RisingWave's access control mechanisms (using GRANT and REVOKE).
You can create logical views that embed specific filtering logic. These views essentially pre-filter the data, restricting the rows visible through that view. Subsequently, you grant specific users or roles permissions to access these carefully crafted views, rather than the underlying base tables. This strategy ensures that users can only query and see the data they are explicitly authorized for, based on the view's definition, providing a flexible way to enforce data segregation.
For more information, see Implement row-level security in RisingWave.
Iceberg source and sink on Azure Blob
Starting with v2.4, RisingWave introduces native support for Apache Iceberg source and sink connectors on Azure Blob Storage (Azblob). This enhancement enables seamless integration with Azure’s scalable, durable, and secure object storage, allowing users to read from and write Iceberg tables directly on Azblob.
To connect RisingWave with Azure Blob Storage, specific configuration parameters are required—such as storage paths and authentication credentials. For complete details on these parameters and their setup, see Configure Iceberg Source on Azure Blob Storage and Configure Iceberg Sink on Azure Blob Storage.
Exactly once delivery for Iceberg sink
RisingWave now supports exactly-once delivery semantics when writing to Apache Iceberg. This ensures that each data record is processed once and only once, even in the event of retries or failures. This eliminates data corruption and ensures accurate analytics when writing to Iceberg.
Powered by a two-phase commit protocol and Iceberg’s idempotent commits, this feature guarantees data integrity without duplicates. Enable it with a simple configuration option to build reliable, real-time pipelines—while staying aware of potential performance trade-offs.
For more information, see Exactly-once delivery.
Conclusion
These are some of the highlight features included in v2.4. To see the entire list of updates, which includes updates to source and sink connectors, please refer to the full release note.
Stay tuned for next month’s updates as we continue to enhance RisingWave with new features. Visit the RisingWave GitHub repository to explore the latest developments and planned releases.
Sign up for our monthly newsletter if you’d like to keep up to date on all the happenings with RisingWave. Follow us on Twitter and LinkedIn, and join our Slack community to talk to our engineers and hundreds of streaming enthusiasts worldwide.
