Skip to main content
This page explains the main ways to read results from RisingWave, from simple SQL queries to integrations with existing tools.

​
Quick guide: choose an access method

If you want to…Use…
Explore data, build dashboards, or serve query APIsSQL over Postgres protocol (SELECT)
Query RisingWave from an existing PostgreSQL databasePostgreSQL FDW
Connect BI / visualization toolsVisualization tools (Postgres-compatible)
Build event-driven apps in PythonPython SDK
If you’re deciding what to persist before you serve it, see Storage overview and CREATE SOURCE vs. CREATE TABLE.

​
Query with SQL (SELECT)

RisingWave is PostgreSQL-compatible on the wire protocol, so you can connect using psql and standard Postgres drivers. You can run SELECT queries against:
  • Tables and materialized views (data stored in RisingWave)
  • Sources (reads from the external system; not stored in RisingWave)
For production dashboards and APIs, prefer querying materialized views (pre-computed results) over scanning raw streams repeatedly.

​
How queries are served

Queries are handled by RisingWave’s Serving Nodes, a Postgres-compatible frontend optimized for high concurrency and low latency. For a curated list of supported tool integrations, see Visualization tools.

​
Query from PostgreSQL via FDW

If your ecosystem is centered around PostgreSQL, you can use PostgreSQL’s foreign data wrapper to query RisingWave tables/MVs as if they were local to Postgres. Use FDW when:
  • You want a single query surface in PostgreSQL.
  • You need to join Postgres tables with continuously updated results in RisingWave.
Performance note: FDW is convenient but can add overhead; complex joins/aggregations may execute in Postgres after data is fetched. RisingWave pushes down filters in WHERE clauses where possible. See: Integrate with PostgreSQL via foreign data wrapper (FDW).

​
Connect visualization tools

Most visualization tools can connect to RisingWave using the Postgres protocol (host/port/user/db). Start here:

​
Access programmatically (SDK & client libraries)

  • Python SDK: Build event-driven apps with Python SDK (risingwave-py).
  • Client libraries: Use standard Postgres drivers; see Client Libraries.

​
Production guidance: isolate serving from streaming

By default, compute nodes can run both streaming jobs and ad-hoc queries. If you see resource contention (e.g., heavy dashboard queries impacting streaming latency), consider splitting the workloads:
  • Serving Nodes: handle ad-hoc queries
  • Streaming Nodes: handle stream processing
See: Set up a dedicated Compute Node.