Continuous Queries

Continuous Queries — Always-On SQL

Write SQL queries that run continuously, updating results as new data arrives. RisingWave turns standard SQL into persistent, always-on computations — delivering fresh answers in milliseconds instead of waiting for batch refreshes.

Start Free vs Flink

Always-On

Persistent Queries

SQL queries run continuously as long-lived computations, not one-shot executions.

Incremental

Delta Processing

Only changed rows are processed — no full table scans, no wasted compute on unchanged data.

1000s

Concurrent Queries

Run thousands of continuous queries simultaneously with shared-nothing distributed execution.

Event-Driven

Zero Idle Cost

Queries consume resources only when processing actual data changes. No polling or scheduled runs.

How They Differ

What are continuous queries and how do they differ from batch queries?

Continuous queries are SQL statements that run persistently, incrementally updating their results as new data streams in. Unlike batch queries that scan entire datasets on demand, continuous queries process only changed data and maintain always-fresh results — turning minutes or hours of latency into milliseconds.

Aspect	Batch Query	Continuous Query
Execution	Runs once on demand	Runs persistently
Freshness	Stale until re-run	Always up-to-date
Processing	Full dataset scan	Incremental updates only
Latency	Minutes to hours	Milliseconds
Resource Use	Spikes during execution	Steady, proportional to change rate
Trigger	Manual or scheduled	Automatic on data arrival

How It Works

How does RisingWave execute continuous queries with standard SQL?

RisingWave accepts standard PostgreSQL-compatible SQL and converts it into a distributed streaming dataflow. Each CREATE MATERIALIZED VIEW statement becomes a continuous query that incrementally maintains its results. Engineers use familiar SQL syntax while RisingWave handles the complexity of distributed incremental computation.

Incremental Computation

Only processes changed rows instead of rescanning entire tables, delivering sub-second freshness at minimal cost.

Distributed Execution

Queries are automatically parallelized across nodes with shared-nothing architecture for horizontal scalability.

Queryable Results

Materialized view results are stored and directly queryable via standard SQL — no separate serving layer needed.

Full SQL Support

JOINs, aggregations, window functions, subqueries, and CTEs all work as continuous queries out of the box.

Patterns

What patterns work best with continuous queries?

Continuous queries excel at real-time aggregations, streaming joins, live dashboards, and event-driven alerts. Any workload where freshness matters and data arrives continuously benefits from the always-on computation model. RisingWave makes these patterns accessible through standard SQL without specialized streaming APIs.

→Real-time dashboards that update without manual refresh or scheduled batch jobs
→Streaming aggregations for metrics, KPIs, and operational analytics updated in milliseconds
→Multi-stream JOINs that enrich events with dimension data or correlate across sources
→Continuous anomaly detection using window functions and statistical aggregations
→Live leaderboards, rankings, and top-N computations maintained incrementally

Frequently Asked Questions

Are continuous queries the same as materialized views?

How many continuous queries can RisingWave handle simultaneously?

Can I use JOINs and aggregations in continuous queries?

Do continuous queries consume resources when there is no new data?

Ready to build continuous queries?

Start writing always-on SQL queries in minutes.

Start Building Continuous Queries

Incremental Materialized Views →What Is a Streaming Database? →