RisingWave on AWS User Guide

Overview

RisingWave is a Postgres-compatible streaming database. It speaks the PostgreSQL wire protocol on port 4566, so any psql client or PostgreSQL driver can run streaming SQL against it: sources, materialized views over streams, and continuous queries whose results are kept incrementally up to date. The cloudimg image installs RisingWave 3.0.0 (the official self-contained risingwave binary from RisingWave Labs) and runs it in standalone single-node mode, where one process hosts the meta, compute, frontend and compactor components. State and metadata are stored on a dedicated EBS data volume, and a unique password is generated on the instance's first boot.

What is included:

• RisingWave 3.0.0 (the single all-in-one risingwave binary) from the official GitHub release
• Standalone single-node mode (risingwave single-node): meta, compute, frontend and compactor in one process
• A unique per-instance password generated on first boot (no shared default credential)
• Standalone state and metadata on a dedicated 40 GiB EBS data volume at /var/lib/risingwave
• The PostgreSQL wire protocol bound to loopback (127.0.0.1:4566) with password authentication
• 24/7 cloudimg support

This is a streaming-database product: the PostgreSQL wire protocol listens on 127.0.0.1:4566 only. The port is not opened to the internet - connect locally on the instance or over an SSH tunnel.

Connecting to your instance

Connect over SSH on port 22 as the default login user for your OS variant, using the key pair you selected at launch:

ssh -i <your-key.pem> ubuntu@<instance-public-ip>

Prerequisites

An AWS account, an EC2 key pair in the target region, a VPC + subnet, and a security group that allows inbound 22/tcp from your management network. m5.large (2 vCPU / 8 GiB RAM) is a good starting point. No inbound application ports are needed because RisingWave is reached over the SSH tunnel.

Step 1 - Launch from the AWS Marketplace

In the AWS Marketplace, search for RisingWave by cloudimg, choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Pick your region, the m5.large instance type, your VPC/subnet, and a security group that allows SSH (22) from your management network. Select your key pair and launch.

Step 2 - Launch from the AWS CLI

aws ec2 run-instances \
  --image-id <risingwave-ami-id> \
  --instance-type m5.large \
  --key-name <your-key> \
  --security-group-ids <sg-allowing-22> \
  --subnet-id <your-subnet> \
  --metadata-options "HttpTokens=required" \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=risingwave}]'

The AMI id for your region is shown on the Marketplace listing's Launch page.

Step 3 - Confirm RisingWave is installed and running

risingwave --version
systemctl is-active risingwave.service risingwave-firstboot.service
ss -tln | grep -E ":4566|:5691"
curl -s -o /dev/null -w "HTTP %{http_code}\n" http://127.0.0.1:5691/

You should see RisingWave 3.0.0, both services active, the Postgres wire bound to loopback on 4566, and the meta dashboard health returning HTTP 200:

127.0.0.1:4566 is the PostgreSQL wire protocol - the data plane and authentication - and is bound to loopback only. 5691 is the read-only meta dashboard; it carries no data and is not opened on the security group by default.

Step 4 - Retrieve your per-instance password

Each instance generates its own unique RisingWave password on first boot and writes it to a root-only credentials file:

sudo cat /root/risingwave-credentials.txt

The file contains RISINGWAVE_PASSWORD, the connection details and the SSH-tunnel instructions. Store the password in your secrets manager. When working on the instance itself you can load it into a shell variable so it never appears on your command line - the examples below do this with PW:

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)

Step 5 - Run streaming SQL with psql

RisingWave is Postgres-compatible, so you connect with the standard psql client. The example below creates a table, defines a materialized view that aggregates over it, inserts rows, and reads the incrementally-maintained result. The default database is dev and the default user is root.

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)
PGPASSWORD="$PW" psql -h 127.0.0.1 -p 4566 -U root -d dev <<'SQL'
CREATE TABLE sales (region varchar, amount int);
CREATE MATERIALIZED VIEW sales_by_region AS
  SELECT region, sum(amount) AS total FROM sales GROUP BY region;
INSERT INTO sales VALUES ('emea', 100), ('emea', 250), ('amer', 400);
FLUSH;
SELECT * FROM sales_by_region ORDER BY region;
SQL

The sales_by_region materialized view is kept up to date automatically as new rows arrive in sales - this is the core of streaming SQL.

Step 6 - Verify the authentication wall

The per-instance password is enforced on the root user: the correct password is accepted, and a wrong password is rejected with FATAL: Invalid password, proving the datastore is never open without the credential.

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)
# Wrong password is rejected (RisingWave answers FATAL: Invalid password):
if PGPASSWORD=wrongpw psql -h 127.0.0.1 -p 4566 -U root -d dev -c 'SELECT 1' >/dev/null 2>&1; then
  echo "UNEXPECTED: wrong password was accepted"
else
  echo "wrong password correctly rejected"
fi
# Correct password authenticates:
PGPASSWORD="$PW" psql -h 127.0.0.1 -p 4566 -U root -d dev \
  -c 'SELECT current_user, version();'

Step 7 - Confirm persistence on the dedicated data volume

RisingWave's standalone state and metadata live on the dedicated EBS data volume at /var/lib/risingwave, so streams, tables and materialized views survive restarts and the volume is independently resizable:

PW=$(sudo grep '^RISINGWAVE_PASSWORD=' /root/risingwave-credentials.txt | cut -d= -f2-)
findmnt /var/lib/risingwave
PGPASSWORD="$PW" psql -h 127.0.0.1 -p 4566 -U root -d dev \
  -c "SELECT name FROM rw_catalog.rw_materialized_views;"

The mount confirms state is on the dedicated data volume rather than the OS root disk.

Step 8 - Connect remotely over an SSH tunnel

RisingWave's PostgreSQL wire protocol listens on 127.0.0.1:4566 only and is not exposed publicly - this is the secure default. To reach it from your workstation, open an SSH tunnel and point a local psql client at localhost:4566:

# On your workstation:
ssh -i <your-key.pem> -L 4566:127.0.0.1:4566 ubuntu@<instance-public-ip>

# In another terminal, with a local psql:
PGPASSWORD=<RISINGWAVE_PASSWORD> psql -h 127.0.0.1 -p 4566 -U root -d dev -c "SELECT 1;"

For production remote access without a tunnel, front RisingWave with TLS, or open 4566 in your own security group restricted to known source ranges. Never expose 4566 to the internet without transport encryption and source restrictions.

Maintenance

• Persistence: standalone state and metadata live on the dedicated EBS data volume at /var/lib/risingwave, so your streams and materialized views survive reboots and the volume is independently resizable.
• Password: the per-instance password is set on the root user on first boot. To change it, run ALTER USER root WITH PASSWORD '<new>'; over psql and update your secrets manager.
• Service: RisingWave runs as risingwave.service under a dedicated risingwave system user. Restart with sudo systemctl restart risingwave.service.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.
• Compatibility: RisingWave speaks the PostgreSQL wire protocol - existing Postgres clients, drivers and tooling connect to 4566 unchanged.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.

RisingWave is a trademark of RisingWave Labs. This image is provided by cloudimg and is not affiliated with or endorsed by RisingWave Labs. RisingWave is licensed under the Apache License 2.0.