A comprehensive comparison of features between RisingWave and Apache Flink, covering SQL capabilities, data types, streaming operations, and system functionalities.
This document provides a detailed feature-by-feature comparison between RisingWave (targeting v2.0) and Apache Flink (targeting v1.20). While both systems excel at stream processing, they have different architectural approaches and feature sets resulting from their different designs: RisingWave as a streaming database (offering an integrated, SQL-centric experience) and Flink as a stream processing framework (providing flexibility through integration with external components). This comparison helps you understand their similarities and differences across various features.
Features noted as “RisingWave-specific” highlight capabilities tied to its database architecture, while “Flink-specific” features reflect its framework nature. Version numbers (RW 2.0, Flink 1.20) are targets; some features might have evolved slightly around these versions. For definitive support details, always consult the official Flink and RisingWave documentation.
RisingWave and Flink share the following core stream processing concepts:
While sharing these fundamentals, their architectures differ: RisingWave stores state internally within its database storage layer, treating streams and materialized views as first-class database objects. Flink typically uses pluggable state backends (such as RocksDB or filesystems), and its connectors manage external storage. This integrated approach in RisingWave simplifies state management compared to Flink’s requirement of configuring and managing external state backends.
Both systems support a wide range of standard SQL data types. The following table highlights common types and key differences.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Fixed-Length | |||
Fixed-Length Char | CHAR | Not Supported | Fixed-length character string. |
Fixed-Length Binary | BINARY | Not Supported | Fixed-length binary string. |
Variable-Length | |||
Variable-Length Char | VARCHAR /STRING | VARCHAR /STRING | Flink allows specifying a maximum length; RisingWave does not allow a maximum length specification. |
Variable-Length Binary | VARBINARY /BYTES | BYTEA | Flink uses VARBINARY or BYTES . RisingWave uses the PostgreSQL-compatible BYTEA . |
Numeric | |||
Arbitrary Precision Decimal | DECIMAL | DECIMAL /NUMERIC | Both support arbitrary precision numbers. Flink uses DECIMAL . RisingWave uses the PostgreSQL-compatible DECIMAL or NUMERIC . |
1-Byte Integer | TINYINT | Not Supported | |
2-Byte Integer | SMALLINT | SMALLINT | |
4-Byte Integer | INT | INT | |
8-Byte Integer | BIGINT | BIGINT | |
32-Byte Integer | Not Supported | RW_INT256 | RisingWave-specific large integer. |
Single-Precision Float | FLOAT | REAL | Flink uses FLOAT . RisingWave uses the PostgreSQL-compatible REAL . |
Double-Precision Float | DOUBLE | DOUBLE PRECISION | Flink uses DOUBLE . RisingWave uses the PostgreSQL-compatible DOUBLE PRECISION . |
Temporal | |||
Date | DATE | DATE | Calendar date. |
Time (no timezone) | TIME | TIME | Time of day without timezone. |
Timestamp (no timezone) | TIMESTAMP | TIMESTAMP | Timestamp without timezone. |
Timestamp (with timezone) | TIMESTAMP_LTZ | TIMESTAMPTZ | Flink uses TIMESTAMP_LTZ (local timezone interpretation). RisingWave uses the PostgreSQL-compatible TIMESTAMPTZ (stored as UTC). |
Interval | INTERVAL | INTERVAL | Time interval. |
Structured | |||
Structured Row | STRUCT | STRUCT | |
Array | ARRAY | ARRAY | Ordered collection of elements. |
Map | MAP | MAP | Key-value pairs. |
Multiset | MULTISET | Not Supported | Unordered collection allowing duplicates (Flink). |
JSON Handling | Via Functions | Native JSONB Type | Flink processes JSON primarily using string functions. RisingWave offers a native JSONB type (binary JSON), enabling efficient storage and indexed querying directly via SQL, similar to PostgreSQL. |
Other | |||
Boolean | BOOLEAN | BOOLEAN | True/False. |
Summary: Flink offers fixed-length types and MULTISET
. RisingWave provides native JSONB
, a large integer type (RW_INT256
), and several PostgreSQL-compatible types (REAL
, TIMESTAMPTZ
, BYTEA
, NUMERIC
). Both support the core data types required for streaming analytics. Timezone handling differs: Flink uses TIMESTAMP_LTZ
for local timezone interpretation, while RisingWave uses the PostgreSQL-standard TIMESTAMPTZ
. RisingWave’s native JSONB
support offers significant advantages for handling semi-structured data compared to Flink’s function-based approach.
Flink SQL and RisingWave both support the standard clauses of a SELECT
query:
WITH
(Common Table Expressions)SELECT
(including DISTINCT
)FROM
WHERE
GROUP BY
(including GROUPING SETS
, ROLLUP
, and CUBE
)HAVING
ORDER BY
LIMIT
DISTINCT ON
: RisingWave supports the PostgreSQL SELECT DISTINCT ON (...)
syntax. Flink 1.20 has limited or no support for this specific syntax.WHERE IN (...)
, WHERE EXISTS (...)
, derived tables in FROM
). Flink’s SQL planner might optimize certain complex or correlated subquery patterns more effectively.MATCH_RECOGNIZE
clause for Complex Event Processing (CEP) directly within SQL. RisingWave does not support MATCH_RECOGNIZE
.Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
DISTINCT ON | Limited/No | Supported | PostgreSQL-style unique row selection, offering a concise way to get the first row per group, a common requirement not directly supported by standard SQL or Flink’s MATCH_RECOGNIZE . |
MATCH_RECOGNIZE | Supported | Not Supported | SQL standard for Complex Event Processing. |
Both systems provide essential windowing capabilities for analyzing data over time or rows.
Flink uses Table Value Functions (TVFs) like TUMBLE
, HOP
, SESSION
, CUMULATE
for windowing aggregations. RisingWave primarily uses standard SQL GROUP BY
with time functions or dedicated window syntax where applicable. Support for TVFs is also being added to RisingWave.
Window Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Tumbling Window | Supported (TVF) | Supported | Fixed-size, non-overlapping windows. |
Sliding Window (Hop) | Supported (TVF) | Supported | Fixed-size, overlapping windows. |
Session Window | Supported (TVF) | Supported | Windows defined by gaps of inactivity. |
Cumulative Window | Supported (TVF) | Not Supported | Windows expanding from a start time to window_end . |
Late Data Handling | Supported | Supported | Mechanisms to handle data arriving after window close. |
Window Offset | Supported | Supported | Adjusting window start/end times. |
Both support standard SQL window functions using the OVER
clause for calculations across sets of table rows.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
OVER (...) | Supported | Supported | Defines the window specification. |
Ranking | Supported | Supported | RANK , DENSE_RANK , ROW_NUMBER , NTILE . |
Navigation | Supported | Supported | LEAD , LAG . |
Value | Supported | Supported | FIRST_VALUE , LAST_VALUE . |
Note: Flink’s NTILE
is a window function, not directly related to percentile aggregates.
Both systems support various SQL join types for combining data from multiple streams or tables.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Regular Joins | |||
INNER JOIN | Supported | Supported | |
LEFT JOIN | Supported | Supported | |
RIGHT JOIN | Supported | Supported | |
FULL JOIN | Supported | Supported | |
State Handling Note | Configurable TTL | Internal Storage with temporal filters and configurable TTL | Flink requires manual configuration of Time-To-Live (TTL) for join state. RisingWave simplifies state management: it uses temporal filters to automatically prune state outside the required time range, and supports configurable TTL for append-only sources, both saving storage space with straightforward configuration. |
Interval Join | Supported | Supported | Joins streams based on time proximity (e.g., t1.time BETWEEN t2.time - INTERVAL '5' SECOND AND t2.time + INTERVAL '5' SECOND ). |
Temporal Join | Joins a stream against a versioned table/changelog source. | ||
Event Time Temporal Join | Supported (FOR ... AS OF ) | Supported (Implicit / TEMPORAL JOIN ) | Flink requires explicit syntax. RisingWave support depends on the source type and query structure. |
Processing Time Temporal Join | Supported (FOR ... AS OF ) | Supported (Lookup Joins) | Flink requires explicit syntax. RisingWave typically achieves this using lookup joins against external tables. |
Window Join | Supported | Supported | Joins aggregated results from windows. |
Lookup Join | Supported | Supported | Joins a stream against an external dimension table (often async). |
Both support standard SQL set operations to combine or compare result sets.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
UNION | Supported | Supported | Combines results, removes duplicates. |
UNION ALL | Supported | Supported | Combines results, keeps duplicates. |
INTERSECT | Supported | Supported | Returns common rows, removes duplicates. |
INTERSECT ALL | Supported | Not Supported | Returns common rows, keeps duplicates. |
EXCEPT | Supported | Supported | Returns unique rows from first set not in second. |
EXCEPT ALL | Supported | Not Supported | Returns rows from first set not in second, keeps duplicates. |
IN (Subquery) | Supported | Supported | Checks for membership in a subquery result. |
EXISTS (Subquery) | Supported | Supported | Checks if a subquery returns any rows. |
CORRESPONDING | Not Supported | Supported | Performs set ops on specified columns by name (RisingWave-specific), simplifying queries when column orders differ but names match. |
As a streaming database, RisingWave has a broader set of Data Definition Language (DDL) commands, especially for managing sources, sinks, users, and connections.
Operation | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
CREATE/DROP DATABASE | Supported | Supported | Logical grouping of objects. |
CREATE/DROP VIEW | Supported | Supported | Defines a logical view based on a query. |
CREATE/DROP FUNCTION | Supported | Supported | Defines user-defined functions. |
CREATE/DROP TABLE | Supported | Supported | Flink: Defines schema/connector. RW: Defines schema for source/table. |
CREATE MATERIALIZED VIEW | Supported | Supported | Defines a query whose results are stored. Core concept in RisingWave. |
DROP MATERIALIZED VIEW | Supported | Supported | Removes a materialized view. |
ALTER MATERIALIZED VIEW | Limited/No | Supported | Modifies a materialized view (e.g., rename, set parallelism). Flink support may vary. |
ALTER DATABASE/VIEW/FUNCTION | Supported | Supported | Modifies existing objects (scope varies). |
RisingWave includes the following DDL commands to manage its database-specific entities:
CREATE/DROP/ALTER SOURCE
: Define connections to external data sources (e.g., Kafka, Kinesis).CREATE/DROP/ALTER SINK
: Define destinations for outputting data.CREATE/DROP/ALTER CONNECTION
: Reusable connection configurations for sources/sinks.CREATE/DROP/ALTER SCHEMA
: Organize objects within a database.CREATE/DROP/ALTER USER
: Manage database users.CREATE/DROP SECRET
: Securely store credentials.CREATE/DROP/ALTER INDEX
: Create indexes on materialized views/tables for faster lookups.CREATE/DROP AGGREGATE
: Define custom aggregate functions.ALTER SYSTEM SET
: Modify system-level configuration parameters.This integrated DDL allows managing the entire data flow (sources, processing, sinks, access) directly through SQL, a key advantage of the streaming database approach.
CREATE OR REPLACE TABLE
: Flink supports this atomic replacement syntax.ALTER TABLE
: Both systems support ALTER TABLE
, but capabilities differ. Flink’s focus is often on schema evolution via connectors/formats. RisingWave supports various alterations like ADD/DROP COLUMN
, RENAME TO
, OWNER TO
, SET SCHEMA
, SET PARALLELISM
, SET SOURCE_RATE_LIMIT
, and REFRESH SCHEMA
(see RW docs for specifics), providing significant table management via SQL.As a database, RisingWave allows standard DML statements to interact with tables and trigger materialized view updates directly, offering a familiar pattern for database users. Data Manipulation Language (DML) statements interact with data in tables or trigger updates to materialized views.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
INSERT INTO ... SELECT ... | Supported | Supported | Inserts data from a query result. Triggers MV updates. |
INSERT INTO ... VALUES ... | Supported | Supported | Inserts explicit rows. Triggers MV updates. |
UPDATE ... SET ... WHERE ... | Supported | Supported | Updates existing rows based on conditions. Triggers MV updates. |
DELETE FROM ... WHERE ... | Supported | Supported | Deletes rows based on conditions. Triggers MV updates. |
Multi-table INSERT | Supported | Not Supported | Flink can insert into multiple tables from a single source query. |
FLUSH | Not Supported | Supported | RisingWave-specific: Ensures visibility of preceding DML changes in subsequent queries within a session (mainly for sinks). |
SET [key = value] | Not Supported | Supported | Modifies session configuration settings. |
Commands for exploring metadata, explaining queries, and managing sessions.
SHOW DATABASES | TABLES | VIEWS | FUNCTIONS | JOBS
: List common objects or entities (supported by both).DESCRIBE <object>
: Shows object metadata (e.g., columns, types). In Flink, <object>
can be a table, view, or catalog. In RisingWave, <object>
can be a table, source, view, sink, or materialized view.EXPLAIN [statement]
: Shows the logical and physical execution plan for a query.USE [database/catalog]
: Sets the current context for queries.SET [key = value]
: Modifies session configuration settings.Reflecting its database architecture, RisingWave offers significantly more comprehensive SQL commands for system introspection compared to Flink:
SHOW CLUSTER
, SHOW PROCESSLIST
, SHOW PARAMETERS
SHOW CONNECTIONS
, SHOW SOURCES
, SHOW SINKS
, SHOW SCHEMAS
SHOW INDEX
, SHOW MATERIALIZED VIEWS
, SHOW INTERNAL TABLES
SHOW CREATE ...
for various RW objects (Sources, Sinks, MVs, etc.)SHOW CURSORS
, SHOW SUBSCRIPTION CURSORS
SHOW JARS
: Lists user-uploaded JAR files (relevant for Java UDFs).SHOW PARTITIONS
: Shows partitions for partitioned tables (common in batch/Hive integration).SHOW CURRENT DATABASE
: Flink command. RW uses SELECT current_database()
.Both systems allow managing running streaming queries/jobs.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
SHOW JOBS | Supported | Supported | Lists active streaming jobs/pipelines. |
CANCEL JOB [id] | Supported | Supported | Stops a specific running job/pipeline. |
A key difference lies in how users interact with the system for management and monitoring tasks.
RisingWave (SQL-centric): Leverages its database architecture to provide a unified SQL interface for many operational tasks:
SET
/SHOW
) and persistent system-wide parameters (ALTER SYSTEM SET
/SHOW PARAMETERS
) are managed via SQL.SHOW JOBS
), active processes (SHOW PROCESSLIST
), DDL progress, and detailed internal states (via system catalogs) are accessible through SQL commands.ALTER ... SET PARALLELISM
) and stopping jobs (CANCEL JOBS
) are done directly with SQL.Flink (API/UI/Config File-centric): As a framework, Flink relies on a combination of interfaces:
flink-conf.yaml
) or command-line options. Flink SQL SET
affects session-specific query behavior.flink cancel/stop
) and modifying aspects like parallelism typically involve the CLI, REST API, or UI, often requiring a job restart (potentially with savepoints).While both support the concept, their role differs significantly.
As a database system, RisingWave provides standard SQL access control.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
GRANT | Not Supported | Supported | Grants privileges on objects. Provides standard, granular SQL-based security within the system. |
REVOKE | Not Supported | Supported | Revokes privileges from users. Provides standard, granular SQL-based security within the system. |
Flink typically relies on external systems (like cluster managers or catalog providers) for access control.
Both systems allow you to extend SQL with custom logic using User-defined Functions (UDFs).
Summary: Both offer extensibility, but RisingWave provides native SQL UDFs and uses WASM/FFI for several embedded languages, while Flink primarily uses JVM languages and an RPC mechanism for Python.
Both Flink and RisingWave provide a rich library of built-in functions covering standard SQL categories. Listing every function is impractical here; instead, we highlight general coverage and key differences.
Common Coverage: Both systems offer extensive support for:
=
, >
, <
, etc.) and predicates (IS NULL
, BETWEEN
).AND
, OR
, NOT
).+
, -
, *
, /
, %
) and functions (POWER
, SQRT
, ABS
, ROUND
, CEIL
, FLOOR
).CONCAT
, SUBSTRING
, UPPER
, LOWER
, TRIM
, REPLACE
, LENGTH
, POSITION
, LIKE
).EXTRACT
, DATE_FORMAT
/TO_CHAR
, casting between date/time types).COUNT
, SUM
, AVG
, MAX
, MIN
, ARRAY_AGG
, STRING_AGG
).CASE WHEN ... END
, COALESCE
, NULLIF
).CAST
).generate_series
.Key Differences & Specific Functions:
PARSE_URL
function.TRY_CAST
(returns NULL on failure instead of error).LOCALTIME
, CURRENT_TIME
, etc.ARRAY_TRANSFORM
).MATCH_RECOGNIZE
.JSONB
operators (->
, ->>
, #>
, etc.) and functions.pg_typeof
, pg_sleep
).encrypt()
, decrypt()
.TIMESTAMPTZ
handling functions.CAST
function, which typically errors on failure during query execution (though behavior within materialized view updates might differ).Recommendation: Always consult the official Flink SQL and RisingWave SQL documentation for the most current and comprehensive list of supported built-in functions.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Catalogs | Supported | Supported | Manage metadata namespaces (e.g., connecting to external catalogs). |
SQL Client | Supported | Supported | Interactive command-line interface for SQL execution. RisingWave supports psql and any Postgres-compatible SQL client. |
SQL Gateway | Supported | Supported | Service for accepting remote SQL submissions (e.g., via REST/JDBC). |
RisingWave and Flink SQL, while both powerful stream processing tools, cater to slightly different needs and design philosophies, which are reflected in their SQL dialects and features.
MATCH_RECOGNIZE
for CEP, and specific features like TRY_CAST
.JSONB
handling, unified SQL DDL/DML for managing sources, sinks, and access control, and automatic internal state management.Your choice between them depends on whether you need a standalone, easy-to-manage streaming database (RisingWave) or a flexible stream processing framework requiring integration with external systems for state, storage, and management (Flink).
A comprehensive comparison of features between RisingWave and Apache Flink, covering SQL capabilities, data types, streaming operations, and system functionalities.
This document provides a detailed feature-by-feature comparison between RisingWave (targeting v2.0) and Apache Flink (targeting v1.20). While both systems excel at stream processing, they have different architectural approaches and feature sets resulting from their different designs: RisingWave as a streaming database (offering an integrated, SQL-centric experience) and Flink as a stream processing framework (providing flexibility through integration with external components). This comparison helps you understand their similarities and differences across various features.
Features noted as “RisingWave-specific” highlight capabilities tied to its database architecture, while “Flink-specific” features reflect its framework nature. Version numbers (RW 2.0, Flink 1.20) are targets; some features might have evolved slightly around these versions. For definitive support details, always consult the official Flink and RisingWave documentation.
RisingWave and Flink share the following core stream processing concepts:
While sharing these fundamentals, their architectures differ: RisingWave stores state internally within its database storage layer, treating streams and materialized views as first-class database objects. Flink typically uses pluggable state backends (such as RocksDB or filesystems), and its connectors manage external storage. This integrated approach in RisingWave simplifies state management compared to Flink’s requirement of configuring and managing external state backends.
Both systems support a wide range of standard SQL data types. The following table highlights common types and key differences.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Fixed-Length | |||
Fixed-Length Char | CHAR | Not Supported | Fixed-length character string. |
Fixed-Length Binary | BINARY | Not Supported | Fixed-length binary string. |
Variable-Length | |||
Variable-Length Char | VARCHAR /STRING | VARCHAR /STRING | Flink allows specifying a maximum length; RisingWave does not allow a maximum length specification. |
Variable-Length Binary | VARBINARY /BYTES | BYTEA | Flink uses VARBINARY or BYTES . RisingWave uses the PostgreSQL-compatible BYTEA . |
Numeric | |||
Arbitrary Precision Decimal | DECIMAL | DECIMAL /NUMERIC | Both support arbitrary precision numbers. Flink uses DECIMAL . RisingWave uses the PostgreSQL-compatible DECIMAL or NUMERIC . |
1-Byte Integer | TINYINT | Not Supported | |
2-Byte Integer | SMALLINT | SMALLINT | |
4-Byte Integer | INT | INT | |
8-Byte Integer | BIGINT | BIGINT | |
32-Byte Integer | Not Supported | RW_INT256 | RisingWave-specific large integer. |
Single-Precision Float | FLOAT | REAL | Flink uses FLOAT . RisingWave uses the PostgreSQL-compatible REAL . |
Double-Precision Float | DOUBLE | DOUBLE PRECISION | Flink uses DOUBLE . RisingWave uses the PostgreSQL-compatible DOUBLE PRECISION . |
Temporal | |||
Date | DATE | DATE | Calendar date. |
Time (no timezone) | TIME | TIME | Time of day without timezone. |
Timestamp (no timezone) | TIMESTAMP | TIMESTAMP | Timestamp without timezone. |
Timestamp (with timezone) | TIMESTAMP_LTZ | TIMESTAMPTZ | Flink uses TIMESTAMP_LTZ (local timezone interpretation). RisingWave uses the PostgreSQL-compatible TIMESTAMPTZ (stored as UTC). |
Interval | INTERVAL | INTERVAL | Time interval. |
Structured | |||
Structured Row | STRUCT | STRUCT | |
Array | ARRAY | ARRAY | Ordered collection of elements. |
Map | MAP | MAP | Key-value pairs. |
Multiset | MULTISET | Not Supported | Unordered collection allowing duplicates (Flink). |
JSON Handling | Via Functions | Native JSONB Type | Flink processes JSON primarily using string functions. RisingWave offers a native JSONB type (binary JSON), enabling efficient storage and indexed querying directly via SQL, similar to PostgreSQL. |
Other | |||
Boolean | BOOLEAN | BOOLEAN | True/False. |
Summary: Flink offers fixed-length types and MULTISET
. RisingWave provides native JSONB
, a large integer type (RW_INT256
), and several PostgreSQL-compatible types (REAL
, TIMESTAMPTZ
, BYTEA
, NUMERIC
). Both support the core data types required for streaming analytics. Timezone handling differs: Flink uses TIMESTAMP_LTZ
for local timezone interpretation, while RisingWave uses the PostgreSQL-standard TIMESTAMPTZ
. RisingWave’s native JSONB
support offers significant advantages for handling semi-structured data compared to Flink’s function-based approach.
Flink SQL and RisingWave both support the standard clauses of a SELECT
query:
WITH
(Common Table Expressions)SELECT
(including DISTINCT
)FROM
WHERE
GROUP BY
(including GROUPING SETS
, ROLLUP
, and CUBE
)HAVING
ORDER BY
LIMIT
DISTINCT ON
: RisingWave supports the PostgreSQL SELECT DISTINCT ON (...)
syntax. Flink 1.20 has limited or no support for this specific syntax.WHERE IN (...)
, WHERE EXISTS (...)
, derived tables in FROM
). Flink’s SQL planner might optimize certain complex or correlated subquery patterns more effectively.MATCH_RECOGNIZE
clause for Complex Event Processing (CEP) directly within SQL. RisingWave does not support MATCH_RECOGNIZE
.Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
DISTINCT ON | Limited/No | Supported | PostgreSQL-style unique row selection, offering a concise way to get the first row per group, a common requirement not directly supported by standard SQL or Flink’s MATCH_RECOGNIZE . |
MATCH_RECOGNIZE | Supported | Not Supported | SQL standard for Complex Event Processing. |
Both systems provide essential windowing capabilities for analyzing data over time or rows.
Flink uses Table Value Functions (TVFs) like TUMBLE
, HOP
, SESSION
, CUMULATE
for windowing aggregations. RisingWave primarily uses standard SQL GROUP BY
with time functions or dedicated window syntax where applicable. Support for TVFs is also being added to RisingWave.
Window Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Tumbling Window | Supported (TVF) | Supported | Fixed-size, non-overlapping windows. |
Sliding Window (Hop) | Supported (TVF) | Supported | Fixed-size, overlapping windows. |
Session Window | Supported (TVF) | Supported | Windows defined by gaps of inactivity. |
Cumulative Window | Supported (TVF) | Not Supported | Windows expanding from a start time to window_end . |
Late Data Handling | Supported | Supported | Mechanisms to handle data arriving after window close. |
Window Offset | Supported | Supported | Adjusting window start/end times. |
Both support standard SQL window functions using the OVER
clause for calculations across sets of table rows.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
OVER (...) | Supported | Supported | Defines the window specification. |
Ranking | Supported | Supported | RANK , DENSE_RANK , ROW_NUMBER , NTILE . |
Navigation | Supported | Supported | LEAD , LAG . |
Value | Supported | Supported | FIRST_VALUE , LAST_VALUE . |
Note: Flink’s NTILE
is a window function, not directly related to percentile aggregates.
Both systems support various SQL join types for combining data from multiple streams or tables.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Regular Joins | |||
INNER JOIN | Supported | Supported | |
LEFT JOIN | Supported | Supported | |
RIGHT JOIN | Supported | Supported | |
FULL JOIN | Supported | Supported | |
State Handling Note | Configurable TTL | Internal Storage with temporal filters and configurable TTL | Flink requires manual configuration of Time-To-Live (TTL) for join state. RisingWave simplifies state management: it uses temporal filters to automatically prune state outside the required time range, and supports configurable TTL for append-only sources, both saving storage space with straightforward configuration. |
Interval Join | Supported | Supported | Joins streams based on time proximity (e.g., t1.time BETWEEN t2.time - INTERVAL '5' SECOND AND t2.time + INTERVAL '5' SECOND ). |
Temporal Join | Joins a stream against a versioned table/changelog source. | ||
Event Time Temporal Join | Supported (FOR ... AS OF ) | Supported (Implicit / TEMPORAL JOIN ) | Flink requires explicit syntax. RisingWave support depends on the source type and query structure. |
Processing Time Temporal Join | Supported (FOR ... AS OF ) | Supported (Lookup Joins) | Flink requires explicit syntax. RisingWave typically achieves this using lookup joins against external tables. |
Window Join | Supported | Supported | Joins aggregated results from windows. |
Lookup Join | Supported | Supported | Joins a stream against an external dimension table (often async). |
Both support standard SQL set operations to combine or compare result sets.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
UNION | Supported | Supported | Combines results, removes duplicates. |
UNION ALL | Supported | Supported | Combines results, keeps duplicates. |
INTERSECT | Supported | Supported | Returns common rows, removes duplicates. |
INTERSECT ALL | Supported | Not Supported | Returns common rows, keeps duplicates. |
EXCEPT | Supported | Supported | Returns unique rows from first set not in second. |
EXCEPT ALL | Supported | Not Supported | Returns rows from first set not in second, keeps duplicates. |
IN (Subquery) | Supported | Supported | Checks for membership in a subquery result. |
EXISTS (Subquery) | Supported | Supported | Checks if a subquery returns any rows. |
CORRESPONDING | Not Supported | Supported | Performs set ops on specified columns by name (RisingWave-specific), simplifying queries when column orders differ but names match. |
As a streaming database, RisingWave has a broader set of Data Definition Language (DDL) commands, especially for managing sources, sinks, users, and connections.
Operation | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
CREATE/DROP DATABASE | Supported | Supported | Logical grouping of objects. |
CREATE/DROP VIEW | Supported | Supported | Defines a logical view based on a query. |
CREATE/DROP FUNCTION | Supported | Supported | Defines user-defined functions. |
CREATE/DROP TABLE | Supported | Supported | Flink: Defines schema/connector. RW: Defines schema for source/table. |
CREATE MATERIALIZED VIEW | Supported | Supported | Defines a query whose results are stored. Core concept in RisingWave. |
DROP MATERIALIZED VIEW | Supported | Supported | Removes a materialized view. |
ALTER MATERIALIZED VIEW | Limited/No | Supported | Modifies a materialized view (e.g., rename, set parallelism). Flink support may vary. |
ALTER DATABASE/VIEW/FUNCTION | Supported | Supported | Modifies existing objects (scope varies). |
RisingWave includes the following DDL commands to manage its database-specific entities:
CREATE/DROP/ALTER SOURCE
: Define connections to external data sources (e.g., Kafka, Kinesis).CREATE/DROP/ALTER SINK
: Define destinations for outputting data.CREATE/DROP/ALTER CONNECTION
: Reusable connection configurations for sources/sinks.CREATE/DROP/ALTER SCHEMA
: Organize objects within a database.CREATE/DROP/ALTER USER
: Manage database users.CREATE/DROP SECRET
: Securely store credentials.CREATE/DROP/ALTER INDEX
: Create indexes on materialized views/tables for faster lookups.CREATE/DROP AGGREGATE
: Define custom aggregate functions.ALTER SYSTEM SET
: Modify system-level configuration parameters.This integrated DDL allows managing the entire data flow (sources, processing, sinks, access) directly through SQL, a key advantage of the streaming database approach.
CREATE OR REPLACE TABLE
: Flink supports this atomic replacement syntax.ALTER TABLE
: Both systems support ALTER TABLE
, but capabilities differ. Flink’s focus is often on schema evolution via connectors/formats. RisingWave supports various alterations like ADD/DROP COLUMN
, RENAME TO
, OWNER TO
, SET SCHEMA
, SET PARALLELISM
, SET SOURCE_RATE_LIMIT
, and REFRESH SCHEMA
(see RW docs for specifics), providing significant table management via SQL.As a database, RisingWave allows standard DML statements to interact with tables and trigger materialized view updates directly, offering a familiar pattern for database users. Data Manipulation Language (DML) statements interact with data in tables or trigger updates to materialized views.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
INSERT INTO ... SELECT ... | Supported | Supported | Inserts data from a query result. Triggers MV updates. |
INSERT INTO ... VALUES ... | Supported | Supported | Inserts explicit rows. Triggers MV updates. |
UPDATE ... SET ... WHERE ... | Supported | Supported | Updates existing rows based on conditions. Triggers MV updates. |
DELETE FROM ... WHERE ... | Supported | Supported | Deletes rows based on conditions. Triggers MV updates. |
Multi-table INSERT | Supported | Not Supported | Flink can insert into multiple tables from a single source query. |
FLUSH | Not Supported | Supported | RisingWave-specific: Ensures visibility of preceding DML changes in subsequent queries within a session (mainly for sinks). |
SET [key = value] | Not Supported | Supported | Modifies session configuration settings. |
Commands for exploring metadata, explaining queries, and managing sessions.
SHOW DATABASES | TABLES | VIEWS | FUNCTIONS | JOBS
: List common objects or entities (supported by both).DESCRIBE <object>
: Shows object metadata (e.g., columns, types). In Flink, <object>
can be a table, view, or catalog. In RisingWave, <object>
can be a table, source, view, sink, or materialized view.EXPLAIN [statement]
: Shows the logical and physical execution plan for a query.USE [database/catalog]
: Sets the current context for queries.SET [key = value]
: Modifies session configuration settings.Reflecting its database architecture, RisingWave offers significantly more comprehensive SQL commands for system introspection compared to Flink:
SHOW CLUSTER
, SHOW PROCESSLIST
, SHOW PARAMETERS
SHOW CONNECTIONS
, SHOW SOURCES
, SHOW SINKS
, SHOW SCHEMAS
SHOW INDEX
, SHOW MATERIALIZED VIEWS
, SHOW INTERNAL TABLES
SHOW CREATE ...
for various RW objects (Sources, Sinks, MVs, etc.)SHOW CURSORS
, SHOW SUBSCRIPTION CURSORS
SHOW JARS
: Lists user-uploaded JAR files (relevant for Java UDFs).SHOW PARTITIONS
: Shows partitions for partitioned tables (common in batch/Hive integration).SHOW CURRENT DATABASE
: Flink command. RW uses SELECT current_database()
.Both systems allow managing running streaming queries/jobs.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
SHOW JOBS | Supported | Supported | Lists active streaming jobs/pipelines. |
CANCEL JOB [id] | Supported | Supported | Stops a specific running job/pipeline. |
A key difference lies in how users interact with the system for management and monitoring tasks.
RisingWave (SQL-centric): Leverages its database architecture to provide a unified SQL interface for many operational tasks:
SET
/SHOW
) and persistent system-wide parameters (ALTER SYSTEM SET
/SHOW PARAMETERS
) are managed via SQL.SHOW JOBS
), active processes (SHOW PROCESSLIST
), DDL progress, and detailed internal states (via system catalogs) are accessible through SQL commands.ALTER ... SET PARALLELISM
) and stopping jobs (CANCEL JOBS
) are done directly with SQL.Flink (API/UI/Config File-centric): As a framework, Flink relies on a combination of interfaces:
flink-conf.yaml
) or command-line options. Flink SQL SET
affects session-specific query behavior.flink cancel/stop
) and modifying aspects like parallelism typically involve the CLI, REST API, or UI, often requiring a job restart (potentially with savepoints).While both support the concept, their role differs significantly.
As a database system, RisingWave provides standard SQL access control.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
GRANT | Not Supported | Supported | Grants privileges on objects. Provides standard, granular SQL-based security within the system. |
REVOKE | Not Supported | Supported | Revokes privileges from users. Provides standard, granular SQL-based security within the system. |
Flink typically relies on external systems (like cluster managers or catalog providers) for access control.
Both systems allow you to extend SQL with custom logic using User-defined Functions (UDFs).
Summary: Both offer extensibility, but RisingWave provides native SQL UDFs and uses WASM/FFI for several embedded languages, while Flink primarily uses JVM languages and an RPC mechanism for Python.
Both Flink and RisingWave provide a rich library of built-in functions covering standard SQL categories. Listing every function is impractical here; instead, we highlight general coverage and key differences.
Common Coverage: Both systems offer extensive support for:
=
, >
, <
, etc.) and predicates (IS NULL
, BETWEEN
).AND
, OR
, NOT
).+
, -
, *
, /
, %
) and functions (POWER
, SQRT
, ABS
, ROUND
, CEIL
, FLOOR
).CONCAT
, SUBSTRING
, UPPER
, LOWER
, TRIM
, REPLACE
, LENGTH
, POSITION
, LIKE
).EXTRACT
, DATE_FORMAT
/TO_CHAR
, casting between date/time types).COUNT
, SUM
, AVG
, MAX
, MIN
, ARRAY_AGG
, STRING_AGG
).CASE WHEN ... END
, COALESCE
, NULLIF
).CAST
).generate_series
.Key Differences & Specific Functions:
PARSE_URL
function.TRY_CAST
(returns NULL on failure instead of error).LOCALTIME
, CURRENT_TIME
, etc.ARRAY_TRANSFORM
).MATCH_RECOGNIZE
.JSONB
operators (->
, ->>
, #>
, etc.) and functions.pg_typeof
, pg_sleep
).encrypt()
, decrypt()
.TIMESTAMPTZ
handling functions.CAST
function, which typically errors on failure during query execution (though behavior within materialized view updates might differ).Recommendation: Always consult the official Flink SQL and RisingWave SQL documentation for the most current and comprehensive list of supported built-in functions.
Feature | Flink (v1.20) | RisingWave (v2.0) | Notes |
---|---|---|---|
Catalogs | Supported | Supported | Manage metadata namespaces (e.g., connecting to external catalogs). |
SQL Client | Supported | Supported | Interactive command-line interface for SQL execution. RisingWave supports psql and any Postgres-compatible SQL client. |
SQL Gateway | Supported | Supported | Service for accepting remote SQL submissions (e.g., via REST/JDBC). |
RisingWave and Flink SQL, while both powerful stream processing tools, cater to slightly different needs and design philosophies, which are reflected in their SQL dialects and features.
MATCH_RECOGNIZE
for CEP, and specific features like TRY_CAST
.JSONB
handling, unified SQL DDL/DML for managing sources, sinks, and access control, and automatic internal state management.Your choice between them depends on whether you need a standalone, easy-to-manage streaming database (RisingWave) or a flexible stream processing framework requiring integration with external systems for state, storage, and management (Flink).