Deploy RisingWave

Deploy and Host RisingWave on Railway

RisingWave is an open-source streaming database that keeps SQL materialized views continuously up to date as events arrive. You write ordinary CREATE MATERIALIZED VIEW statements over Kafka topics, database change streams or tables you insert into, and it maintains the results incrementally rather than recomputing them per query. It speaks the PostgreSQL wire protocol, so any psql client, BI tool or driver can read those results — no new SDK, no Java operators.

Self-host RisingWave on Railway as a real distributed cluster rather than one all-in-one container. This template runs the four roles as separate services — meta, compute, compactor and frontend — alongside managed PostgreSQL for cluster metadata, an object storage bucket for streaming state, Prometheus scraping every role, and a Caddy gateway putting HTTP basic authentication in front of the dashboard. SQL clients reach the frontend over a TCP proxy; everything else stays private.

Getting Started with RisingWave on Railway

There are two entry points. The first is SQL: open the frontend service, copy its TCP proxy host and port from the Networking panel, and connect with any PostgreSQL client as root against database dev, using the password you set in RW_ROOT_PASSWORD. There are no default credentials to change — that password is applied on every boot, so the endpoint is never open.

The second is the dashboard: open the public URL of the dashboard service and sign in with DASHBOARD_USERNAME and DASHBOARD_PASSWORD for node health, live CPU and memory charts, the catalog of sources, tables and views, and a fragment graph per job.

Prove the engine end to end first. Connect with psql and run:

CREATE TABLE orders (id int PRIMARY KEY, region varchar, amount numeric);
CREATE MATERIALIZED VIEW revenue_by_region AS
  SELECT region, count(*) AS orders, sum(amount) AS revenue
  FROM orders GROUP BY region;
INSERT INTO orders VALUES (1,'emea',120.5),(2,'amer',310.25),(3,'apac',45.75);
FLUSH;
SELECT * FROM revenue_by_region ORDER BY revenue DESC;

Insert three more rows, run FLUSH and select again — the totals change without the view being rebuilt. From there point a real stream at it with CREATE SOURCE ... WITH (connector = 'kafka', ...) and build views on top. The dashboard's Materialized Views and Fragment Graph pages confirm the job is running.

About Hosting RisingWave

RisingWave separates compute from storage. Streaming state lives in object storage in a log-structured format called Hummock, cluster metadata lives in a SQL database, and the nodes doing the work hold only caches — which is why a node can be replaced without losing anything.

• PostgreSQL-compatible SQL surface, including psql, JDBC and most BI tools
• Incrementally maintained materialized views over streams and tables
• Connectors for Kafka, Redpanda, Pulsar, Kinesis, MySQL and PostgreSQL CDC, and S3
• Sinks back out to Kafka, Iceberg, PostgreSQL, Redis and object storage
• Sub-second freshness and second-scale recovery, since checkpoints sit in object storage
• A dashboard for cluster health, catalog browsing and job inspection

The role split matters when you scale. The meta node owns the catalog and schedules barriers. The compute node runs streaming operators and batch queries, and is where to add memory when views grow. The compactor merges storage files and scales with write volume. The frontend plans SQL and holds connections; stateless, so it is the safe place to add replicas.

Why Deploy RisingWave on Railway

Railway removes the infrastructure work that surrounds a streaming database.

• Managed PostgreSQL for cluster metadata, provisioned and wired up automatically
• A managed object storage bucket for state, credentials injected as references
• Private networking, so only the SQL endpoint and dashboard are exposed
• A TCP proxy giving the PostgreSQL wire protocol a public endpoint
• Per-service scaling, so compute and compactor grow independently

Common Use Cases

• Real-time dashboards reading pre-aggregated views instead of scanning raw events on every refresh
• Streaming ETL joining Kafka topics with database change streams and sinking the result into a warehouse or Iceberg table
• Operational monitoring built from windowed aggregations over application or IoT event streams
• Feature serving for machine learning, where features must reflect events from seconds ago

Dependencies for RisingWave

• risingwavelabs/risingwave:v3.0.3 — meta, compute and compactor, from risingwavelabs/risingwave
• A thin layer on the same image for the frontend, applying the superuser password at startup
• caddy:2-alpine — basic authentication in front of the dashboard, which ships none of its own
• prom/prometheus:v3 — scrapes all four roles so the dashboard's metric panels have data
• Railway PostgreSQL — metadata store holding the catalog and checkpoint bookkeeping
• Railway object storage — the Hummock state store for streaming state and checkpoints

Environment Variables Reference

Deployment Dependencies

• Source code: github.com/risingwavelabs/risingwave
• Image: hub.docker.com/r/risingwavelabs/risingwave
• Docs: docs.risingwave.com

Hardware Requirements for Self-Hosting RisingWave

Requirements are per service. Compute needs the headroom, since view state is cached in memory before spilling to object storage.

Every RisingWave binary reads its container's CPU and memory limits directly, so parallelism and memory budgets retune themselves when you resize a service. Override them with RW_PARALLELISM and RW_TOTAL_MEMORY_BYTES only when you must.

Self-Hosting RisingWave

For a local trial the single-node image needs only Docker:

docker run -it --pull=always -p 4566:4566 -p 5691:5691 \
  risingwavelabs/risingwave:v3.0.3 single_node
psql -h localhost -p 4566 -d dev -U root

A production cluster is the shape this template deploys: four processes sharing one metadata database and one bucket. Upstream ships a compose file:

git clone https://github.com/risingwavelabs/risingwave.git
cd risingwave/docker
docker compose -f docker-compose-distributed.yml up -d

Running that yourself means operating MinIO or S3, a PostgreSQL instance and the networking between the roles.

Is RisingWave Free to Self-Host?

RisingWave Community Edition is open source under the Apache 2.0 licence, and the version this template deploys costs nothing to run. Some premium features — certain enterprise connectors, elastic disk caching — need a licence key from RisingWave Labs, and the cluster logs a clear message when one is gated. On Railway you pay only for the resources the services consume.

FAQ

What is RisingWave? A distributed SQL streaming database. It ingests event streams and change data, maintains materialized views over them incrementally, and serves the results over the PostgreSQL wire protocol.

What does this Railway template deploy? Seven services — RisingWave meta, compute, compactor and frontend, Prometheus, a Caddy authentication gateway for the dashboard, and managed PostgreSQL — plus an object storage bucket.

Why does the template include PostgreSQL and object storage? RisingWave stores cluster metadata in a SQL database and streaming state in object storage. That separation is what lets a node be replaced without data loss, and is not optional in a multi-node cluster.

How do I connect to self-hosted RisingWave with psql? Use the frontend service's TCP proxy host and port, database dev, user root, and the password from RW_ROOT_PASSWORD. Any PostgreSQL 13-compatible client works.

Is RisingWave a replacement for Apache Flink? For SQL-shaped streaming work it usually is, with far less operational overhead. Flink stays the better fit when you need custom Java operators or event-processing patterns RisingWave's SQL cannot express.

Can I scale RisingWave on Railway? Yes. The frontend is stateless and safe to replicate, the compactor scales with write volume, and compute is where to add CPU and memory as view state grows.