> ## Documentation Index
> Fetch the complete documentation index at: https://docs.risingwave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Query & serve data from RisingWave

> Query RisingWave via PostgreSQL-compatible SQL, integrate with BI tools like Grafana and Metabase, use PostgreSQL FDW for cross-database queries, and build apps with Python SDK and client libraries.

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 APIs   | **SQL over Postgres protocol** (`SELECT`)     |
| Query RisingWave from an existing PostgreSQL database | **PostgreSQL FDW**                            |
| Connect BI / visualization tools                      | **Visualization tools** (Postgres-compatible) |
| Build event-driven apps in Python                     | **Python SDK**                                |

<Tip>
  If you’re deciding what to persist before you serve it, see [Storage overview](/store/overview) and [CREATE SOURCE vs. CREATE TABLE](/ingestion/create-source-vs-create-table).
</Tip>

## 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)

<Note>
  For production dashboards and APIs, prefer querying **materialized views** (pre-computed results) over scanning raw streams repeatedly.
</Note>

### 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](/integrations/visualization/overview).

## 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)](/serve/risingwave-as-postgres-fdw).

## Connect visualization tools

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

* [Visualization tools overview](/integrations/visualization/overview)

## Access programmatically (SDK & client libraries)

* **Python SDK**: Build event-driven apps with [Python SDK](/python-sdk/intro) (`risingwave-py`).
* **Client libraries**: Use standard Postgres drivers; see [Client Libraries](/client-libraries/overview).

## 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](/operate/dedicated-compute-node).