RisingWave

Editor’s note: This RisingWave review evaluates documented capabilities and pricing, not firsthand product testing or measured performance.

Quick verdict: I recommend RisingWave for SQL-capable engineering teams that repeatedly serve fresh joins and aggregates from changing data. Its appeal is continuously maintained results, but I would treat it as a streaming computation and serving layer, not a replacement for a transactional application database.

RisingWave sits in the streaming database category, alongside tools that turn database changes and event streams into queryable results. That makes it relevant when scheduled transformations leave application data stale or when repeated queries keep recalculating the same answer.

My buying question is simple: does the application need continuously updated results, or would periodic refreshes do? Streaming adds operational commitments even when SQL makes the processing logic familiar. In this review, I’ll take a closer look at pricing, setup, CDC semantics, and deployment ownership.

Key Takeaways

• SQL-driven computation: Materialized views incrementally maintain query results as underlying data changes.
• Familiar connectivity: PostgreSQL-compatible clients provide a familiar route into the database.
• Deployment choice: The Apache 2.0 core provides a self-hosted path alongside commercial offerings.
• Compatibility caveat: PostgreSQL wire compatibility does not mean full PostgreSQL application compatibility.
• Budget caveat: The advertised resource-unit rate is not a complete monthly cluster price.

Pros and Cons

I like RisingWave’s fit for reusable SQL transformations. My reservations concern compatibility and the lifecycle of persistent streaming jobs, rather than a lack of SQL functionality.

The source-only behavior is not inherently a flaw. I consider it a consequential design choice: avoiding another retained copy is attractive until a changed query needs history that the upstream system has already discarded.

How Much Does RisingWave Cost?

RisingWave pricing starts at $0.227 per RWU-hour.

• Basic: Usage billing and a seven-day trial. My starting choice for a hosted evaluation.
• Pro: No fixed public price. My choice for deployment requirements beyond Basic.
• Commercial Self-managed: No fixed public price. For teams operating their own infrastructure.

Plan	Billing	Deployment	Published resource boundary
Basic	Pay as you go	Fully hosted on AWS, GCP, or Azure	Up to 64 cores
Pro	Pay as you go or annual contract	Fully hosted, BYOC, or BYOK8s	No listed core limit
Commercial Self-managed	Annual contract	On-premises or Kubernetes	Contract-specific sizing

Resource configuration determines RWU consumption. Ingress, egress, and private connectivity cost extra; SSO and automatic schema evolution are premium capabilities.

For illustration, one RWU for 730 hours equals $165.71 before other charges. That is resource arithmetic, not a minimum cluster quote.

Is RisingWave Good Value for Money?

I see the strongest value when several consumers need the same evolving answer. A maintained aggregate can become a shared serving asset rather than logic duplicated across application endpoints and scheduled jobs. That is an architectural argument, not a claim that RisingWave will lower your bill.

My value assessment depends on the workload:

• Repeated fresh reads: A continuously maintained result has a clear purpose when applications request it throughout the day.
• Occasional reporting: Maintaining state around the clock may be unnecessary if a scheduled query already meets the freshness requirement.
• Complex dependencies: Multiple views and downstream consumers increase the importance of migration and recovery planning.
• Existing platform skills: Self-hosting is less attractive when it introduces unfamiliar infrastructure ownership alongside the data project.

I would budget around a complete pipeline rather than a single SQL query. Historical loading and ongoing processing create different demands, while serving traffic adds another dimension. The relevant comparison is the cost of meeting the application’s freshness requirement, including engineering ownership, not simply the lowest advertised unit.

Reviewer’s Notes: I recommend Basic for a SQL team evaluating one clearly bounded hosted use case. I would choose Pro for a concrete deployment or premium-feature requirement, not as an automatic precaution against future growth.

Getting Started With RisingWave

The data-retention decision matters more than signup. I would settle what needs to be retained before moving beyond the sample workflow.

1. Create the account. The Cloud quickstart supports company email or Google, Microsoft, and GitHub authentication. Select New cluster and an available Basic or Pro plan.
2. Choose the SQL connection. Open the SQL Editor, or use Connect to obtain details for a local PostgreSQL-compatible client.
3. Start with sample SQL. The quickstart introduces sources, materialized views, and result queries before moving to a real input.
4. Define the input model. Configure the connector and schema, deciding whether raw incoming data should persist inside RisingWave.
5. Create the maintained result. Define a materialized view, then query it or deliver its output downstream.

For a hypothetical orders application, I would begin with one narrowly defined question: what is the current order count and value by status? That is easier to reason about than immediately combining customer enrichment, payment reconciliation, and several application endpoints.

The crucial distinction is CREATE SOURCE versus a connector-backed table. A source defines the connection without persisting raw incoming data inside RisingWave, so replay depends on external retention. A connector-backed table persists data independently of that retention and supports primary keys and indexes.

I would generally favor a persisted table for an evolving orders model. A later business-rule change may require rebuilding the result from earlier records. A source-only design remains reasonable when the external system already provides suitable history and avoiding another retained copy is deliberate.

Assuming an orders table with the appropriate columns already exists, the illustrative processing logic could look like this:

CREATE MATERIALIZED VIEW order_totals AS
SELECT
    status,
    COUNT(*) AS order_count,
    SUM(amount) AS total_amount
FROM orders
GROUP BY status;

SELECT * FROM order_totals;

This illustrative query assumes a configured input. Connector credentials and the upstream schema belong to the preceding configuration.

For this example, an order moving from pending to shipped should affect the corresponding groups under the modeled input semantics. That is why I prefer starting with business meaning before adding more SQL: duplicated events and current-state records are not interchangeable inputs.

I would keep the initial scope to one input, one maintained result, and one consumer. That makes incorrect business assumptions easier to isolate before the dependency graph grows.

Streaming SQL and Materialized Views

RisingWave’s main attraction is moving repeated computation ahead of the read. A materialized view defines a SELECT whose results are maintained incrementally, rather than asking every consumer to reconstruct the answer from raw input.

I like this model for operational dashboards and application-facing aggregates with stable query shapes. The SQL definition becomes a reusable result. It is less persuasive when nearly every request asks a different question and few results are reused.

ClickHouse’s incremental views process inserted blocks, with joins triggered by inserts into the left-most source table. A change to a right-side join table does not independently trigger recomputation. Changing joined records matter here: for an orders-and-customers model, I would compare how each system handles a customer update without a new order.

View creation first backfills historical data from referenced relations, with duration depending on data volume. Background DDL and ingestion throttling during backfill are documented controls. I would therefore distinguish initial readiness from steady-state freshness: a view that maintains changes continuously still needs to establish its initial result.

Query changes also deserve attention. Changing a materialized-view definition normally means creating a replacement and coordinating dependent views or sinks before dropping or renaming the old object. SQL is approachable, but a deployed graph of streaming jobs is not equivalent to a saved query you can casually edit.

For a hypothetical revenue model, changing the treatment of refunds affects more than syntax. Historical records may need reinterpretation, and consumers need a deliberate cutover. Retaining source data in a persistent table gives that rebuild a more useful foundation.

SINK INTO TABLE offers another documented pattern for changing processing logic while retaining the persistence layer, with conflict-resolution overhead. I see it as an architectural option, not a universal shortcut around migration planning.

State growth is the other trade-off. A join or aggregate may require retained information as new records arrive. The important design question is how much history the result genuinely needs, rather than how short the SQL statement looks.

Watermarks track event-time progress, and events behind the current watermark are late and not processed within that time window. With table TTL, late inserts, updates, or deletes for expired rows are discarded; cleanup does not erase already computed downstream materialized-view results. For financial corrections, I would be particularly cautious about treating expiration as a harmless housekeeping setting. Flink’s explicit state, timers, and custom late-event handling make it a stronger candidate when the application needs procedural control over these decisions.

Finally, PostgreSQL compatibility stops short of equivalence. RisingWave uses the PostgreSQL wire protocol and works with familiar drivers, but stored procedures and triggers are unsupported. Materialized views update automatically; there is no REFRESH MATERIALIZED VIEW command.

Read-only transactions are a separate capability: they execute against a consistent Hummock snapshot. DDL and INSERT, UPDATE, or DELETE are not allowed inside those transactions. That supports consistent reading, not the assumption that an existing transactional PostgreSQL application can move unchanged.

Connecting Databases and Streams

Native CDC makes RisingWave interesting even without an existing message broker. Kafka is not a prerequisite for every architecture.

The ingestion catalog includes PostgreSQL and MySQL CDC alongside brokers such as Kafka and Pulsar. It also covers object storage and other input types. Catalog breadth should not be read as a promise that every connector belongs to every commercial plan.

The documented PostgreSQL example creates a shared CDC source and then maps a RisingWave table to upstream public.orders. I like the explicit separation between establishing the database connection and choosing the relation to process. It encourages a narrower initial scope than treating an entire operational database as an undifferentiated feed.

PostgreSQL CDC still depends on upstream replication discipline. For failover, the documented requirements include a stable endpoint, a synchronized logical replication slot, and retained WAL covering the last committed LSN. A managed destination cannot compensate for upstream history that no longer exists.

Type mapping also deserves application-level attention. PostgreSQL UUID values map to varchar, and numeric support reaches 28 digits unless alternative mappings are used. For identifiers, the representation change may be acceptable; for precision-sensitive calculations, I would make the chosen representation part of the data contract.

There is a narrowly scoped transaction caveat: native PostgreSQL/MySQL CDC tables support transactional=true, but atomicity is not guaranteed for upstream transactions changing more than 4,096 rows. This is a connector-and-transaction boundary, not a blanket statement that RisingWave lacks transactions. It is separate from the read-only snapshot behavior described earlier.

I would avoid designing a critical consumer around an assumption that every large upstream batch appears atomically. Bulk maintenance and routine application writes can have very different transaction sizes.

Downstream delivery needs equally careful language. Sink guarantees are connector-dependent; input-side behavior is not proof of end-to-end delivery semantics for every destination. My recommendation is to define where correctness must hold, including how the consumer interprets replayed or repeated output, rather than attach one broad guarantee to the whole pipeline.

Deployment and Operational Trade-Offs

The self-hosted option is real, but open-source licensing does not remove operating responsibility. RisingWave’s core repository uses Apache 2.0; commercial premium capabilities remain separate.

Persistent data uses object storage such as S3, GCS, or Azure Blob, with compute and storage scalable separately. That architecture gives teams flexibility in how they provision resources.

The architecture divides responsibilities among serving, streaming, meta, and compactor nodes. For self-hosting, that means managing more than the SQL endpoint. Metadata and compaction capacity are part of the system’s health, even when an application’s immediate concern is fresh query results.

The Kubernetes Operator manages provisioning, upgrades, and scaling through custom resources. Its documented prerequisites include Kubernetes, kubectl, and cert-manager. Metadata storage is configured separately from the state backend, and production guidance recommends matching CPU and memory requests to limits for each component.

I would match ownership to the team rather than assume one deployment is inherently superior:

• Managed service: My preference when the application team needs a streaming result but does not want to operate the database infrastructure.
• Self-hosted core: A sensible option for platform teams with a clear infrastructure reason and capacity to own operations.
• Commercial self-managed: A purchasing path when internal operation needs a commercial support relationship.

Iceberg adds another architectural choice. RisingWave can manage Iceberg tables internally, including catalog and compaction responsibilities, or read and write externally managed tables. I would distinguish those modes by who owns the table lifecycle, not treat “Iceberg support” as a single interchangeable feature.

My main concern is unclear ownership across boundaries. The database operator, source-database administrator, and application owner may each control a different part of freshness and recovery. Even a fully hosted destination leaves business semantics and upstream replication decisions with the adopting team.

How Does RisingWave Compare to Competitors?

I would compare these tools by processing model and ownership, not by unmeasured speed claims. Similar SQL syntax can hide meaningfully different behavior.

• Materialize: My closest comparison for SQL-oriented streaming database buyers. It offers cloud and self-managed deployment, making RisingWave vs Materialize a choice about operating models and licensing. Materialize’s free Community license has 24 GiB memory and 48 GiB disk limits; that is a different licensing boundary from RisingWave’s Apache 2.0 core.
• Apache Flink: My stronger candidate for custom event-processing behavior. Its SQL and Table API sit alongside the DataStream API, so choosing it does not automatically mean writing every job in Java.
• ClickHouse: My candidate when analytical querying is central. Alongside its insert-triggered incremental views, refreshable views provide a periodic full-query model. I would consider that option when scheduled recomputation meets the application’s freshness needs.

Product	Primary model	Decision-relevant distinction	My preferred buyer fit
RisingWave	Streaming database	Incrementally maintained SQL results	Teams serving reusable, changing joins and aggregates
Materialize	SQL streaming database	Cloud and self-managed licensing choices	Buyers comparing SQL-first streaming systems
Apache Flink	Stream-processing framework	Explicit state and timers alongside SQL	Teams needing custom event-processing behavior
ClickHouse	Analytical database	Insert-triggered or periodic materialized views	Teams centered on analytical query workloads

I would choose the processing model before comparing advertised resource prices. These products do not maintain every result in the same way, and a cheaper unit is little help if the architecture cannot express the required update behavior.

How I Reviewed RisingWave

I based this review on documented product behavior, commercial plan details, and technical documentation for the alternatives. My assessment emphasizes SQL workflow, CDC correctness boundaries, deployment ownership, and cost interpretation.

I did not run a hands-on benchmark, provision a cluster, or measure ingestion latency, backfill duration, or serving throughput. The walkthrough explains the documented process rather than reporting personal execution.

My recommendations concern architectural fit. They do not establish which product will be fastest or cheapest for a particular workload.

Prices current as of October 2026.

Should You Choose RisingWave?

I would choose RisingWave when a SQL-capable team needs a maintained result that several consumers reuse. Fresh operational aggregates and changing relational joins are convincing reasons to put it on a shortlist.

I would not switch merely because “real time” sounds preferable to scheduled processing. If existing refresh intervals satisfy the application, another stateful system may add more responsibility than value. I would also keep the transactional application database separate rather than mistake familiar client connectivity for replacement compatibility.

For a hosted evaluation, Basic is my default recommendation when its feature set covers the intended pipeline. Pro makes more sense when a specific deployment or premium capability drives the purchase. I would reserve self-hosting for teams that can name the infrastructure benefit and own its operational consequences.

My verdict is favorable but bounded: RisingWave is a compelling SQL-first candidate for continuously maintained application data, not a universal answer to every analytics or stream-processing problem.

FAQ

Is RisingWave free and open source?

The core repository is Apache 2.0 licensed. Running it yourself still requires infrastructure and operating effort, while premium commercial capabilities are separate. The core license does not make managed hosting free.

Can RisingWave replace PostgreSQL?

I would not treat it as a transactional PostgreSQL replacement. Wire-protocol compatibility is narrower than application compatibility, and its read-only transaction support does not provide ordinary multi-statement write transactions. I see it as a complementary computation and serving layer.

Does RisingWave require Kafka?

No. Native database CDC provides ingestion paths without Kafka. I would add a broker because the broader architecture needs it, not because every RisingWave deployment requires one.

How is RisingWave different from Flink?

RisingWave centers the workflow on database relations and maintained SQL results. Flink is a stream-processing framework with SQL support and lower-level APIs for explicit state and timers. I favor Flink when that procedural control is essential.

What determines RisingWave Cloud costs?

Size the complete workload, including historical loading, continuous processing, and serving traffic. I would compare the cost of meeting the application’s freshness requirement rather than select a database by its advertised unit price.