Deploy and Host RisingWave on Railway

RisingWave

RisingWave is an open source streaming database. You write PostgreSQL-compatible SQL, and it keeps materialized views continuously up to date as data arrives from Kafka, Postgres CDC, MySQL CDC, webhooks and ten more sources. Any Postgres client, driver or BI tool connects to it. It does in one system what a Debezium plus Kafka plus Flink plus serving-database stack does in four, and you query the results with a plain SELECT.

Official intro video (click to watch on YouTube):

About Hosting RisingWave

This template runs the official RisingWave image in single-node mode: one process carrying the SQL frontend, compute, metadata and compaction, reachable over the Postgres wire protocol by any Postgres client, driver or BI tool. The password for the root, postgres and rwadmin users is generated for your deployment and applied on every deployment, so you copy DATABASE_PUBLIC_URL and connect with no setup step. Memory is set to the 8 GiB RisingWave expects; you can raise it for heavier workloads, but do not lower it below 8 GiB because that can cause issues like a crash-loop.

RisingWave's web dashboard can be accessed at your service URL, behind its own login. Normally it is not safe to expose the dashboard: it has no built-in authentication. This template fixes that by putting an authenticating proxy in front of it, with a second generated password, so you get the dashboard without compromising on safety.

Common Use Cases

Streaming ETL and live materialized views: joins, aggregations and time windows over Kafka topics, always current, queryable in SQL
Real-time Postgres or MySQL replicas: ingest CDC and serve fresh joins and rollups without loading your primary database
Feature serving and live dashboards: point any Postgres client, ORM or BI tool at results that maintain themselves instead of re-running batch jobs
Streaming into a lakehouse: continuously sink to Apache Iceberg, Postgres, ClickHouse, Elasticsearch, S3 and others

How to Use RisingWave After Deployment

Wait for the RisingWave service to go green. First boot takes about 15 seconds.
Open the RisingWave service, go to the Variables tab, and copy the DATABASE_PUBLIC_URL. It includes the credentials, so running psql "[DATABASE_PUBLIC_URL]" (or adding it to your BI tool) should allow you to connect to the database. Note: use the DATABASE_URL variable for connecting to other Railway services within the same project.
Create a table or a source, then define a materialized view over it. It maintains itself from there.
Run FLUSH; after an INSERT in order to read your own write immediately. RisingWave commits on a barrier interval, so a SELECT immediately after an INSERT can return zero rows.
For the dashboard, open the service's public URL in a browser and log in with the RW_DASHBOARD_USER and RW_DASHBOARD_PASSWORD variables from that same Variables tab.

📌 To change any of these later, edit RW_PASSWORD (database), RW_DASHBOARD_USER or RW_DASHBOARD_PASSWORD (dashboard) in the Variables tab and redeploy. The database and dashboard credentials are deliberately separate, and the database password is re-applied to all three users on every deployment, so change it there rather than by running ALTER USER yourself.

Learn more

This quickstart covers the basics in a few minutes (Step 3 onwards). The official tutorials go further, from materialized views and connectors through windows and watermarks to running it in production. And awesome-stream-processing has copy-paste demos for CDC, Kafka joins and live dashboards.

Is RisingWave Free?

RisingWave is Apache-2.0, and everything this template deploys runs without a license key: the SQL engine, all connectors, materialized views, Iceberg. RisingWave Labs fund the project through a handful of key-gated enterprise features and RisingWave Cloud, their managed service.

FAQ

Is single-node mode production-grade? RisingWave Labs position it for development, evaluation and small-scale production. It is one process with no failover. For large or fault-tolerant deployments they steer you to their Kubernetes operator or their cloud.

Do I need Kafka running on Railway too? No. RisingWave connects outward to brokers you already have with CREATE SOURCE, and it also ingests Postgres and MySQL CDC, S3, webhooks and more.

Is the dashboard safe to leave open? Yes, that is the point of the proxy. Nothing reaches RisingWave's dashboard without your RW_DASHBOARD_USER and RW_DASHBOARD_PASSWORD; the dashboard port is never published directly. The one path that answers without credentials is /api/version, which returns a version string and is what Railway's healthcheck uses.

Dependencies for Hosting RisingWave

RisingWave, one service in single-node mode: the SQL frontend, compute, metadata and compaction all run in a single process with an embedded SQLite metadata store.
A persistent volume at /var/lib/risingwave. The only stateful piece: metadata and table state both live there.

Deployment Dependencies

Implementation Details

Porting from PostgreSQL, three structural differences: materialized views maintain themselves and there is no REFRESH MATERIALIZED VIEW; sources are read-only, so use CREATE TABLE with a connector for data you also want to INSERT into; and event-time windows need a watermark or they never emit. See: SQL reference.

How to Upgrade: change the image tag in the service settings and redeploy. State and metadata live on the volume and are picked up by the new version. Railway can also do this for you: in the service Settings, under Source, "Configure Auto Updates" lets you take patches only, inside a maintenance window you choose.

Why Deploy RisingWave on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying RisingWave on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.