​
Step 1: Start RisingWave

The following options start RisingWave in the standalone mode. In this mode, data is stored in the file system and the metadata is stored in the embedded SQLite database. See About RisingWave standalone mode for more details. For extensive testing or single-machine deployment, consider starting RisingWave via Docker Compose. For production environments, consider RisingWave Cloud, our fully managed service, or deployment on Kubernetes using the Operator or Helm Chart.

​
Script installation

Open a terminal and run the following curl command. 
curl -L https://risingwave.com/sh | sh
To start a RisingWave instance, run the following command. 
risingwave

​
Docker

Ensure Docker Desktop is installed and running in your environment. 
docker run -it --pull=always -p 4566:4566 -p 5691:5691 risingwavelabs/risingwave:latest single_node
Ensure your hardware supports the required SIMD extensions (AVX2 for x86_64, NEON for ARM64). See SIMD requirements for Docker images for details.

​
Homebrew

Ensure Homebrew is installed, and run the following commands: 
brew tap risingwavelabs/risingwave
brew install risingwave
risingwave

​
Step 2: Connect to RisingWave

Ensure you have psql installed in your environment. To learn about how to install it, see Install psql without PostgreSQL. Open a new terminal window and run: 
psql -h localhost -p 4566 -d dev -U root
Alternative: Use RisingWave Console Instead of using the command line, you can also use the RisingWave Console, a web-based interface for managing and querying your RisingWave cluster. The console provides a visual way to run SQL queries, monitor cluster health, explore database schemas, and execute operational commands through an intuitive web interface.

​
Step 3: Insert some data

RisingWave supports both direct data insertion and streaming data ingestion from sources like message queues and database change streams. To keep things simple, we’ll demonstrate the approach of direct data insertion. Let’s create a table and insert some data. For instance, we can create a table named credit_card_transactions to store information about credit card usage.
Create the table
CREATE TABLE credit_card_transactions (
  card_id VARCHAR,
  amount DECIMAL,
  ts TIMESTAMP
);
Insert five rows of data
INSERT INTO credit_card_transactions (card_id, amount, ts)
VALUES
  ('card_123', 1200.00, '2022-01-01 10:00:00'),
  ('card_123', 1800.00, '2022-01-01 10:00:20'),
  ('card_123', 1900.00, '2022-01-01 10:00:40'),
  ('card_456', 4000.00, '2022-01-01 10:01:00'),
  ('card_456', 950.00,  '2022-01-01 10:01:30');

​
Step 4: Analyze and query data

Next, we will detect potentially fraudulent behavior by identifying any card that spends more than $5000 within a one-minute window. To do this, we’ll use a materialized view. A materialized view in RisingWave is not a static snapshot or a one-time query. Instead, it’s a continuously maintained result that automatically stays up to date as new data arrives. You can think of it as a live dashboard behind a SQL query.
Create a materialized view that detects high-spending cards in 1-minute windows
CREATE MATERIALIZED VIEW fraud_alerts AS
SELECT
  card_id,
  window_start,
  window_end,
  SUM(amount) AS total_amount
FROM
  TUMBLE(
    credit_card_transactions,  -- the source table
    ts,                        -- the event timestamp column
    INTERVAL '1 minute'        -- window size
  )
GROUP BY
  card_id, window_start, window_end
HAVING
  SUM(amount) > 5000;          -- only alert if total spend exceeds $5000
When this materialized view (MV) is created, RisingWave starts tracking it immediately. You don’t need to refresh or re-run the query manually. Any future insertion into credit_card_transactions will automatically update fraud_alerts.
Query the current result
SELECT * FROM fraud_alerts;
------
 card_id  |     window_start     |     window_end       | total_amount
----------+----------------------+----------------------+--------------
(0 rows)
At this point, no fraud alert is triggered yet. Let’s insert one more transaction to push card_123 over the $5000 threshold.
Insert additional data to trigger fraud alert
INSERT INTO credit_card_transactions (card_id, amount, ts)
VALUES ('card_123', 600.00, '2022-01-01 10:00:50');
Query the updated result
SELECT * FROM fraud_alerts;
------
 card_id  |     window_start     |     window_end       | total_amount
----------+----------------------+----------------------+--------------
 card_123 | 2022-01-01 10:00:00  | 2022-01-01 10:01:00  | 5500.00
(1 row)
As you can see, the MV is automatically updated when new data is inserted. You don’t need to manage any refresh logic or manual updates. RisingWave handles the incremental computation for you in the background.

​
About RisingWave standalone mode

RisingWave standalone mode is a simplified deployment mode for RisingWave. It is designed to be minimal, easy to install, and configure. Unlike other deployment modes, for instance Docker Compose or Kubernetes, RisingWave standalone mode starts the cluster as a single process. This means that services like compactor, frontend, compute and meta are all embedded in this process. For state store, we will use the embedded LocalFs Object Store, eliminating the need for an external service like minio or s3; for meta store, we will use the embedded SQLite database, eliminating the need for an external service like etcd. By default, the RisingWave standalone mode will store its data in ~/.risingwave, which includes both Metadata and State Data. For a batteries-included setup, with monitoring tools and external services like kafka fully included, you can use Docker Compose instead. If you would like to set up these external services manually, you may check out RisingWave’s Docker Compose, and run these services using the same configurations.

​
Configure RisingWave standalone mode

The instance of RisingWave standalone mode can run without any configuration. However, there are some options available to customize the instance. The main options which new users may require would be the state store directory (--state-store-directory) and in-memory mode (--in-memory). --state-store-directory specifies the new directory where the cluster’s Metadata and State Data will reside. The default is to store it in the ~/.risingwave folder. 
# Reconfigure RisingWave to be stored under 'projects' folder instead.
risingwave --state-store-directory ~/projects/risingwave
--in-memory will run an in-memory instance of RisingWave, both Metadata and State Data will not be persisted. 
risingwave --in-memory
You can view other options with: 
risingwave single --help

​
Monitor RisingWave standalone mode with Grafana and Prometheus

To monitor your standalone cluster, you may wish to integrate metrics monitoring with Grafana and Prometheus. First install Grafana and Prometheus. Next, clone the RisingWave repository, it contains various configuration files. Start the RisingWave standalone cluster. Make sure you’re in the RisingWave directory. Start your prometheus instance: 
prometheus --config.file=./standalone/prometheus.yml --web.listen-address=0.0.0.0:9500
Then start the Grafana instance: 
grafana server --config ./standalone/grafana.ini
Next, add the Prometheus Data Source on the Grafana Dashboard: http://localhost:3001/connections/datasources/prometheus. 
name: risedev-prometheus
Prometheus Server URL: http://localhost:9500
Finally, add the User and Dev Dashboard: http://localhost:3001/dashboard/import. The file paths are grafana/risingwave-dev-dashboard.json, grafana/risingwave-user-dashboard.json. With that you can now monitor your standalone cluster with Grafana and Prometheus.

​
What’s next?

Congratulations! You’ve successfully started RisingWave and conducted some initial data analysis. To explore further, you may want to: