GUIDE

Streaming SQL — The Complete Guide

Q: Is streaming SQL the same as standard SQL?

Streaming SQL builds on standard SQL syntax and semantics. The core language — SELECT, JOIN, GROUP BY, WHERE — is identical. Streaming SQL adds concepts like continuous queries, event-time processing, watermarks, and windowing functions that handle the unbounded nature of data streams.

Q: Do I need to learn a new language to use streaming SQL?

No. If you know PostgreSQL SQL, you already know most of streaming SQL. RisingWave uses PostgreSQL-compatible syntax, so existing queries, JOINs, aggregations, and window functions work as expected. The main new concepts are sources, sinks, and materialized views as continuous queries.

Q: Can streaming SQL handle complex event processing (CEP)?

Yes. Streaming SQL supports pattern matching with temporal joins, window functions, and conditional logic that enables complex event processing. RisingWave can detect sequences of events, temporal correlations, and anomalies using standard SQL constructs.

Q: How does streaming SQL handle backpressure?

RisingWave manages backpressure automatically. When downstream processing cannot keep up with incoming data rates, the system slows upstream ingestion to prevent data loss or memory overflow — without any manual configuration or custom code.

Streaming SQL extends standard SQL to process continuous data streams. Learn how to write streaming queries, create materialized views, handle time windows, and build real-time pipelines — all using PostgreSQL-compatible SQL in RisingWave.

Try RisingWave Free Materialized Views Guide

PostgreSQL

Compatible Syntax

Use the same SQL you already know — SELECT, JOIN, GROUP BY, window functions all work over streams

Continuous

Query Execution

Queries run indefinitely, emitting updates every time the underlying data changes

Event-Time

Semantics

Process data based on when events occurred, not when they arrived — watermarks handle late data

Incremental

Computation

Only changed rows are recomputed — a GROUP BY over billions of events processes just the new arrivals

Core Concept

What is streaming SQL and how does it extend standard SQL?

Streaming SQL applies the declarative power of SQL to continuous, unbounded data streams. Standard SQL operates on finite tables — you run a query, get a result, and the query terminates. Streaming SQL runs queries that never terminate: they process each incoming event and continuously update their results as new data arrives.

Dimension	Standard SQL	Streaming SQL
Execution	Runs once, returns result	Runs forever, updates continuously
Data Model	Finite table (bounded)	Continuous stream (unbounded)
Result	Snapshot at query time	Always-current materialized view
Freshness	Stale until re-queried	Sub-second, event-driven

→Standard SQL: SELECT count(*) FROM orders — runs once, scans entire table, returns a number
→Streaming SQL: CREATE MATERIALIZED VIEW order_count AS SELECT count(*) FROM orders_stream — runs forever, updates on each new order
→Both use identical SQL syntax. The difference is the execution model: bounded vs. unbounded data
→CREATE SOURCE connects to Kafka, Pulsar, Kinesis, or CDC sources using standard SQL DDL

Capabilities

What SQL constructs work with streaming data in RisingWave?

RisingWave supports the full range of PostgreSQL-compatible SQL constructs for streaming: SELECT, JOIN (inner, left, right, full), GROUP BY, HAVING, window functions (ROW_NUMBER, RANK, LAG, LEAD), subqueries, CTEs, CASE expressions, and aggregate functions (COUNT, SUM, AVG, MIN, MAX). All of these work continuously over streams.

Streaming JOINs

Join two or more streams in real-time. RisingWave handles temporal alignment, state management, and output updates across all join types.

Aggregations

COUNT, SUM, AVG, MIN, MAX, and custom aggregations run incrementally. Results update in milliseconds as new events arrive.

Window Functions

ROW_NUMBER, RANK, DENSE_RANK, LAG, LEAD, FIRST_VALUE, LAST_VALUE — all work over streaming data with partition and order clauses.

Subqueries and CTEs

Nest queries and use WITH clauses for readable, composable streaming logic. Common table expressions simplify complex pipelines.

Time & Windows

How do you handle time, windows, and late data in streaming SQL?

Streaming SQL introduces time-based windowing to partition unbounded streams into finite, processable chunks. RisingWave supports tumbling windows (fixed, non-overlapping intervals), hopping windows (fixed, overlapping intervals), and session windows (gap-based grouping) — all expressed in standard SQL syntax with event-time semantics.

→Tumbling window: non-overlapping, fixed-size intervals (e.g., every 5 minutes). Each event belongs to exactly one window.
→Hopping window: overlapping intervals with a fixed size and slide (e.g., 10-minute windows sliding every 2 minutes). Events can belong to multiple windows.
→Session window: dynamic windows that close after a period of inactivity (e.g., a user session ends after 30 minutes of no events).
→Watermarks: RisingWave uses watermarks to track event-time progress and determine when a window is complete, handling out-of-order and late-arriving events.
→Late data: events arriving after the watermark has passed can be handled via configurable policies — either discarded or incorporated into updated results.

Frequently Asked Questions

Is streaming SQL the same as standard SQL?

Do I need to learn a new language to use streaming SQL?

Can streaming SQL handle complex event processing (CEP)?

How does streaming SQL handle backpressure?

Ready to write streaming SQL?

Start building real-time streaming pipelines with PostgreSQL-compatible SQL.

Start Writing Streaming SQL

Materialized Views →CDC Guide →