How to Use RisingWave: The Beginner's Guide (2026)

CodexFuse Team · 2026-11-02T11:03:35.565Z · 13 min read min read

RisingWave is a streaming SQL database you query with psql. This beginner guide covers install, your first streaming table and materialized view, the Kafka-source arc, sinks, CDC, and the RisingWave vs Flink choice.

How to Use RisingWave If You Already Know SQL

Learning how to use RisingWave is easier than learning any other streaming engine, because the tool meets you where you already are. If you can write a SQL query and you have used the psql command-line client, you can get a real streaming database running on your own machine in about five minutes. There is no cluster to configure, no Java virtual machine to tune, and no job to package and deploy. You connect with psql, you create tables and materialized views with ordinary SQL, and the system keeps your results fresh as new data arrives.

RisingWave is a PostgreSQL-compatible streaming database. The mental model is a database, not a pipeline: you connect with psql, write CREATE TABLE and CREATE MATERIALIZED VIEW statements, and the system handles everything else — ingestion, incremental computation, state management, and serving query results. That quote comes from the vendor's own developer-experience write-up, and it is the single sentence that makes the whole product click.

This RisingWave tutorial is the streaming database tutorial nobody else has published: install RisingWave one of three ways, connect with psql on port 4566, create your first streaming table and your first materialized view, connect a Kafka source, send results to a sink, and understand exactly where change-data-capture fits. The fastest install route uses Docker — if the container commands feel new, the Docker beginner guide covers them from zero.

What Is RisingWave, Exactly?

RisingWave is an open-source streaming SQL database that computes results continuously over live event streams and serves them through a PostgreSQL wire protocol, so any Postgres client can query them. You define sources that read from Kafka or your databases, you write materialized views in standard SQL, and RisingWave refreshes those views incrementally in real time instead of recomputing them from scratch. A SELECT against a materialized view returns the current answer instantly, no matter how fast the underlying stream moves.

The vendor's tagline as of late 2026 calls it an "event streaming platform for agentic AI" that continuously ingests, transforms, and serves event streams in real time — but underneath the marketing, the working reality is simpler: it is a database you SELECT from while the data keeps arriving.

RisingWave Is Not Kafka, and RisingWave Is Not Flink

Draw this line once and the rest of the guide makes sense. Kafka moves messages: it is a durable log that stores events and hands them to consumers. RisingWave is the database that computes on those events with SQL — it ingests the messages, joins and aggregates them continuously, and serves fresh answers. You would use both together: Kafka as the transport, RisingWave as the queryable brain.

The Flink comparison is just as important. Apache Flink is a full stream-processing framework that asks you to download a binary, configure the JVM, set up a cluster with a JobManager and TaskManagers, and package your job for deployment. RisingWave replaces that whole operational layer with a database you talk to in psql. If your job is "compute SQL results over live streams," RisingWave is the five-minute path; if your job is "run arbitrary JVM stream-processing programs at massive scale," Flink remains the incumbent.

How Do You Install RisingWave?

RisingWave ships a single-command playground mode that starts a one-node instance — meta service, compute nodes, and the SQL frontend — in a single process on your machine. It is designed for local development, and it is the right way to learn. There are three install routes; all three were verified against the vendor's current docs and release listings on 2026-11-02, and the RisingWave Docker command below mounts both ports your client will need.

The Docker route exposes two ports you should know by heart. Port 4566 is the PostgreSQL wire protocol port — this is how psql connects. Port 5691 serves the HTTP dashboard, where you can watch fragments and query plans. The current release as of this writing is v3.0.5, with 3.1.0-alpha on the main branch; the vendor blog's older screenshots show 2.8.0, so expect slightly newer version numbers than the five-minute write-up shows.

How Do You Connect to RisingWave with psql?

Once the playground is running, connect with the standard PostgreSQL client using this exact command:

psql -h localhost -p 4566 -U root -d dev

No password is needed for the local playground. That is the whole connection story — the same client you would use against Postgres works here, because RisingWave speaks the PostgreSQL wire protocol. Any driver, ORM, or BI tool that talks Postgres can talk to RisingWave, which is why the psql mental model carries so far.

If you have worked with an embedded analytics engine before, the contrast is worth one sentence: DuckDB queries data at rest in files, while RisingWave queries data in motion from streams — the DuckDB beginner guide covers that engine's side of the SQL world.

Table vs Source vs Materialized View vs Sink: The Four Objects

To build real-time data applications in RisingWave, you must understand four core objects: Table, Source, Materialized View (MV), and Sink. They represent storage, data ingress, real-time computation, and data egress. The vendor's docs state the relationships plainly: both Tables and MVs store data inside RisingWave, but a Table holds the current state of the data — populated internally or from an external source — whereas an MV is the persisted result of a computation.

The key sentence to memorize: a Source acts as a data entry point and does not store data, making it suitable for exploration and validation, while a Sink does not retain data inside RisingWave but continuously outputs results. And the Materialized View is the core of real-time computation in RisingWave — it is defined by a SQL query, and the system automatically maintains the result table, refreshing it in real time as the underlying data updates.

How Do You Create Your First Streaming Table and Materialized View?

Follow the docs' own quickstart arc — a credit-card fraud detector — and you will touch every core object in under five minutes:

1. Create the table. Run CREATE TABLE credit_card_transactions (card_id INT, amount DECIMAL, ts TIMESTAMP); and insert a few rows with plain INSERT statements.
2. Define the materialized view. Write the fraud rule as SQL to create your first RisingWave materialized view: CREATE MATERIALIZED VIEW fraud_alerts AS SELECT card_id, COUNT(*) FROM credit_card_transactions WHERE amount > 5000 AND ts > now() - interval '1 minute' GROUP BY card_id;
3. Query it like any table. Run SELECT * FROM fraud_alerts; — you get the current answer instantly.
4. Insert one more row. Add a transaction over $5,000 with a fresh timestamp.
5. Watch it update. Run the SELECT again: the new row is already reflected. Nothing recomputed the whole table — RisingWave updated the result incrementally.

The vendor's canonical example is even simpler, and it is worth quoting verbatim because it shows the syntax at its most distilled:

CREATE MATERIALIZED VIEW daily_sales AS
SELECT date_trunc('day', ts) d, SUM(amount) total
FROM sales
GROUP BY d;

That is the entire "program": a SELECT, given a name, maintained forever. When the underlying sales data changes, the view refreshes in real time with no polling, no cron job, and no cache invalidation code.

How Do You Stream Data from a Kafka Topic?

Real beginners' data does not arrive as hand-typed INSERTs — it arrives as a Kafka topic. The risingwave kafka connector makes that a CREATE SOURCE statement with the schema spelled out inline:

-- Create a source that reads from a Kafka topic
CREATE SOURCE pageviews (
  user_id INT,
  page_url VARCHAR,
  view_time TIMESTAMP
) WITH (
  connector = 'kafka',
  topic = 'pageviews',
  properties.bootstrap.server = 'broker:9092'
) FORMAT PLAIN ENCODE JSON;

Every piece of that statement is load-bearing: the connector names the system to read from, the topic names the stream, the properties line points at your broker, and FORMAT PLAIN ENCODE JSON declares that each Kafka message is a plain JSON object matching your column list. Change properties.bootstrap.server to your own broker address — broker:9092 is the docs' placeholder.

Then compute on it exactly like the table above. A materialized view over pageviews refreshes as events land in the topic, and a plain SELECT reads the latest results. This is the risingwave psql workflow at full power: connect with psql, declare the source, name the computation, read the answer.

Where Do the Results Go? Writing Sinks

Reading results in psql is perfect for development, but production pipelines push results somewhere else — back into Kafka for downstream services, into a warehouse for analysts, or into a database your app queries. That is the Sink object's job:

CREATE SINK kafka_sink
FROM fraud_alerts
WITH (
  connector = 'kafka',
  topic = 'fraud-alerts',
  properties.bootstrap.server = 'broker:9092'
) FORMAT PLAIN ENCODE JSON;

RisingWave supports three sink syntaxes: FROM an existing table or view, AS a SELECT query, and INTO — which writes results back into an internal RisingWave table instead of an external system. The moment the sink exists, every update to fraud_alerts flows out to the fraud-alerts Kafka topic as JSON, continuously, with no polling loop.

How Does CDC Fit In? Getting Database Changes into RisingWave

Change data capture — CDC — is how live rows from your existing Postgres or MySQL databases become a stream RisingWave can compute on. The RisingWave CDC story starts with a Debezium connector, which watches your database's write-ahead log, with a Kafka topic that carries every insert, update, and delete. RisingWave then reads that topic through the Kafka connector you just learned, so your materialized views stay in sync with your operational database within seconds.

The vendor's own positioning names this explicitly: RisingWave replaces the Debezium-plus-Kafka-plus-Flink-plus-serving-database stack with one system that ingests, processes, serves, and stores. For a beginner, the honest takeaway is simpler: if your events already live in Kafka — whether from Debezium CDC, application logs, or IoT sensors — you are one CREATE SOURCE away from querying them. If you are running the playground on your own machine rather than a laptop, review what VPS hosting is before exposing any ports.

RisingWave vs Flink: Which One Fits Your Job?

The vendor's developer-experience post frames the choice as a side-by-side table, and it is the fairest way to see the trade-off:

Read the table as a decision rule, not a verdict. Choose RisingWave when your streaming work is SQL-shaped — filters, joins, aggregations, and alert rules that analysts can read and own. Choose Flink when you need custom DataStream programs, complex event processing with hand-rolled state, or the ecosystem of Flink connectors your platform team already runs. The two are not enemies: many teams prototype the SQL layer in RisingWave first and keep Flink for the jobs SQL cannot express.

One related lane worth naming: if your workload is analytics over historical data rather than live streams, a columnar OLAP engine is the other half of the story — the ClickHouse beginner guide covers that world.

7 Beginner Mistakes to Avoid with RisingWave

Sources

Every command, quote, and number in this guide was fetched from the source below on 2026-11-02 (UTC); star and version figures are moving snapshots, not fixed claims. A local CLI run was not possible in this environment (no Docker, psql, or Homebrew available), so install flows are presented as vendor-documented and verified against current docs, not as locally executed.

• RisingWave developer-experience blog — install routes, psql command, playground description, Flink comparison table, "PostgreSQL-compatible streaming database" framing: https://risingwave.com/blog/risingwave-developer-experience-install-to-first-query/
• RisingWave docs quickstart — five-minute arc (install → psql → credit_card_transactions → fraud_alerts MV): https://docs.risingwave.com/get-started/quickstart
• RisingWave docs "What is a Source in RisingWave" — CREATE SOURCE Kafka/JSON verbatim: https://docs.risingwave.com/reference/what-is-source.md
• RisingWave docs "Table, Source, Materialized View, Sink" — four-object mental model and MV example verbatim: https://docs.risingwave.com/get-started/source-table-mv-sink.md
• RisingWave docs "Sink to Kafka" — CREATE SINK syntax: https://docs.risingwave.com/delivery/supported-sink-connectors
• RisingWave GitHub README — install script, "replaces the whole stack" positioning: https://github.com/risingwavelabs/risingwave
• RisingWave GitHub releases — v3.0.5 current release (snapshot 2026-11-02)
• GitHub repository page — 9,397 stars, 862 forks (snapshot 2026-11-02)
• Apache Iceberg docs — RisingWave connector page: https://iceberg.apache.org/docs/1.8.1/risingwave/
• CrateDB integration guide — RisingWave integration reference: https://cratedb.com/docs/guide/integrate/risingwave/
• exakat.io — "RisingWave, PHP, and the Streaming Database Idea" (independent, ~49 days): https://www.exakat.io/risingwave-php-and-the-streaming-database-idea/

Frequently Asked Questions

Is RisingWave a replacement for Kafka?

No. Kafka is a message transport — a durable log that stores events and delivers them to consumers. RisingWave is a streaming SQL database that computes on those events: it reads Kafka topics as sources, maintains materialized views over them in real time, and serves results through psql. The standard architecture uses both together.

Do I need to know Flink to use RisingWave?

No, and that is the point. RisingWave has no JVM to tune and no cluster to configure: you connect with psql and write CREATE TABLE, CREATE SOURCE, and CREATE MATERIALIZED VIEW statements. Flink remains the right choice for custom DataStream programs and complex event processing that SQL cannot express.

How do I connect to RisingWave with psql?

Start the playground, then run psql -h localhost -p 4566 -U root -d dev — no password is needed locally. Port 4566 is the PostgreSQL wire protocol port; port 5691 serves the HTTP dashboard. Any Postgres-compatible client works the same way.

What is the difference between a source and a table in RisingWave?

A source is a data entry point that does not store data — it is for exploration and validation of a live stream. A table holds the current state of data, populated by inserts or an external source. A materialized view is the persisted result of a SQL computation, refreshed automatically as data arrives.

Can RisingWave read change data capture (CDC) from my database?

Yes, through Kafka. A Debezium connector watches your database's write-ahead log and publishes every insert, update, and delete to a Kafka topic; RisingWave reads that topic as a source and keeps materialized views in sync with your operational database within seconds.