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

# Using RisingWave FAQ

> Answers to frequently asked questions about using the RisingWave streaming database, including memory management, reserved memory configuration, CREATE MATERIALIZED VIEW performance, and resource usage breakdown.

This page answers common operational questions about running RisingWave in production, including memory management, materialized view creation performance, and resource usage.

## Why is the memory usage so high?

This is by design. RisingWave uses memory for in-memory caching of streaming query state — data structures like hash tables, aggregation buffers, and join state — to optimize streaming computation performance.

By default, RisingWave utilizes all available memory unless specifically configured through `RW_TOTAL_MEMORY_BYTES` or `--total-memory-bytes`. This is why **setting memory limits is required** in Kubernetes and Docker deployments.

During operation, RisingWave keeps memory usage below the configured limit. If you encounter unexpected out-of-memory (OOM) issues, see [Troubleshoot out-of-memory](/troubleshoot/troubleshoot-oom).

## Why is the memory for a Serving or Streaming Node not fully utilized?

RisingWave allocates a portion of total memory as **reserved memory** for system usage, including the process stack, code segments, allocation overhead, and network buffers.

### Reserved memory calculation (v1.10+)

Starting from version 1.10, RisingWave calculates reserved memory using a gradient formula:

* **30%** of the first 16 GB
* **20%** of the remaining memory

**Example**: For a Streaming Node with 32 GB of total memory:

* 30% of the first 16 GB = 4.8 GB
* 20% of the remaining 16 GB = 3.2 GB
* **Total reserved memory = 8 GB**

This gradient approach ensures more memory is reserved on smaller instances (where system overhead is proportionally larger) while leaving more memory available for computation on larger instances.

### Custom reserved memory configuration

You can override the default calculation using:

* **Environment variable**: `RW_RESERVED_MEMORY_BYTES=8589934592` (8 GB)
* **Startup option**: `--reserved-memory-bytes=8589934592`

<Note>
  The reserved memory must be at least 512 MB.
</Note>

**Example**: On a 64 GB Streaming Node, the default reserved memory would be 14.4 GB (30% of 16 GB + 20% of 48 GB). If this is excessive for your workload, set `RW_RESERVED_MEMORY_BYTES=8589934592` to allocate only 8 GB.

### Version history of reserved memory

| Version     | Behavior                                                            |
| ----------- | ------------------------------------------------------------------- |
| Before v1.9 | Fixed 30% of total memory as reserved                               |
| v1.9        | Introduced customizable reserved memory (`--reserved-memory-bytes`) |
| v1.10+      | Changed to gradient calculation (30% of first 16 GB + 20% of rest)  |

## Why does CREATE MATERIALIZED VIEW take a long time?

The execution time for `CREATE MATERIALIZED VIEW` depends on two main factors:

### 1. Backfilling historical data

When a new materialized view is created, RisingWave **backfills all historical data** from the referenced tables and materialized views to ensure a consistent snapshot. The `CREATE` statement blocks until backfilling completes.

**How to check progress**:

```sql theme={null}
SHOW JOBS;
```

**How to run in background** (non-blocking):

```sql theme={null}
SET BACKGROUND_DDL = true;
CREATE MATERIALIZED VIEW my_mv AS SELECT ...;
```

<Note>
  When `BACKGROUND_DDL=true`, the new materialized view remains invisible in the catalog until backfilling completes. See [SET BACKGROUND\_DDL](/sql/commands/sql-set-background-ddl) for details.
</Note>

### 2. High cluster latency

If the `Progress` column in `SHOW JOBS` stays at `0.0%`, the cluster may be experiencing high latency that slows down streaming graph changes. See [Troubleshoot high latency](/performance/troubleshoot-high-latency) for diagnostic steps.

## What does the memory and disk usage consist of?

RisingWave memory usage on a Serving or Streaming Node is divided into three components:

| Component           | Description                                                                         |
| ------------------- | ----------------------------------------------------------------------------------- |
| **Storage memory**  | Caching data blocks, metadata, and shared buffers to improve read/write performance |
| **Compute memory**  | Memory allocated for streaming computation and ad-hoc query execution               |
| **Reserved memory** | System overhead: process stack, code segments, allocation, and network buffers      |

**Example breakdown** for a Streaming Node with 8 GB total memory:

```
total_memory: 8.00 GiB
    storage_memory: 2.13 GiB
        block_cache_capacity: 688.00 MiB
        meta_cache_capacity: 802.00 MiB
        shared_buffer_capacity: 688.00 MiB
    compute_memory: 3.47 GiB
    reserved_memory: 2.40 GiB
```

For guidance on tuning memory allocation, see [Tune reserved memory](/operate/tune-reserved-memory).

<head>
  <script type="application/ld+json">
    {`
          {
            "@context": "https://schema.org",
            "@type": "FAQPage",
            "mainEntity": [
              {
                "@type": "Question",
                "name": "Why is RisingWave memory usage so high?",
                "acceptedAnswer": {
                  "@type": "Answer",
                  "text": "This is by design. RisingWave uses memory for in-memory caching of streaming query state to optimize performance. By default, it utilizes all available memory unless configured via RW_TOTAL_MEMORY_BYTES. Setting memory limits is required in Kubernetes and Docker deployments."
                }
              },
              {
                "@type": "Question",
                "name": "Why is the memory for a RisingWave Serving or Streaming Node not fully utilized?",
                "acceptedAnswer": {
                  "@type": "Answer",
                  "text": "RisingWave reserves a portion of total memory for system usage. Starting from v1.10, it uses a gradient formula: 30% of the first 16GB plus 20% of the remaining memory. You can override this with the RW_RESERVED_MEMORY_BYTES environment variable or --reserved-memory-bytes startup option (minimum 512MB)."
                }
              },
              {
                "@type": "Question",
                "name": "Why does CREATE MATERIALIZED VIEW take a long time in RisingWave?",
                "acceptedAnswer": {
                  "@type": "Answer",
                  "text": "CREATE MATERIALIZED VIEW backfills all historical data from referenced tables to ensure a consistent snapshot. Use SHOW JOBS to check progress. To run non-blocking, set BACKGROUND_DDL=true before the CREATE statement. If progress stays at 0%, the cluster may be experiencing high latency."
                }
              },
              {
                "@type": "Question",
                "name": "What does RisingWave memory usage consist of?",
                "acceptedAnswer": {
                  "@type": "Answer",
                  "text": "RisingWave memory is divided into storage memory (block cache, meta cache, shared buffer), compute memory (streaming computation and queries), and reserved memory (system overhead). For example, an 8GB node uses approximately 2.13GB for storage, 3.47GB for compute, and 2.40GB reserved."
                }
              }
            ]
          }
          `}
  </script>
</head>