RisingWave

There is a familiar shape to a certain kind of infrastructure company. It looks at a problem that a small priesthood of specialists has learned to solve at great expense, and it asks the mildly heretical question: what if this were boring?

RisingWave is that company for stream processing, which is the practice of doing something useful with data the instant it arrives rather than waiting to batch it up overnight. Stream processing is genuinely hard, and for most of the last decade the way you did it was to adopt a framework - Apache Flink being the canonical example - hire people who understood it, and accept that "real-time" was a capital project. RisingWave's founder, Yingjun Wu, spent a decade inside that world and came away with the opinion that most of the difficulty was incidental rather than essential. So in 2021 he left a software-engineering job on AWS Redshift and started a company premised on the idea that you should be able to do streaming with the same SQL you already use for a database, and that if you couldn't, that was a bug in the tooling, not a fact about the universe.

This is a more radical claim than it sounds, because "just use SQL" is the kind of thing that everyone agrees with in principle and almost nobody delivers in practice. The reason is that a streaming SQL engine has to hold a lot of contradictory promises at once. It has to be fast. It has to be correct even when machines fail and messages arrive out of order. It has to keep state that can grow enormous. And it has to do all of this while pretending, to the developer, that nothing unusual is happening - that a query which continuously updates itself forever is the same sort of object as a query that runs once and returns rows. RisingWave's engineering bet is that you can hide that complexity behind a PostgreSQL-compatible interface, which is a polite way of saying: your existing tools, drivers, and muscle memory should just work.

A person who found real-time too hard, professionally

Wu is not a first-time tourist to this problem. He holds a PhD from the National University of Singapore, was a visiting PhD at Carnegie Mellon's well-known database group, did research at IBM's Almaden lab, and then worked on Redshift, Amazon's data warehouse. That resume matters because it means RisingWave was not started by someone who read about streaming and thought it looked like a market. It was started by someone who had built the adjacent systems and formed strong, specific opinions about why they were painful. The company's stated design principles read like a person settling old grudges: SQL-first, correctness over speed, open source for trust, cloud-native by construction. The "correctness over speed" one is quietly the most interesting, because the entire streaming industry is usually sold on speed. RisingWave's position is that a fast answer that is occasionally wrong is worse than useless in the places where real-time actually matters - fraud, trading, monitoring - and so it guarantees exactly-once semantics first and optimizes latency second.

What you can actually do with it

Concretely, RisingWave lets you point a continuous query at a stream of events - say, transactions flowing out of a database via change data capture, or clicks arriving through Kafka - and define a materialized view that stays permanently up to date. Instead of recomputing an aggregate from scratch, the engine updates it incrementally as each event lands, in milliseconds. You write it in SQL. The result is a live table you can query like any other, except it is never stale.

-- a view that updates itself, forever
CREATE MATERIALIZED VIEW suspicious_charges AS
SELECT user_id,
       count(*) AS charges_last_min,
       sum(amount) AS total
FROM payments
WHERE status = 'authorized'
GROUP BY user_id, tumble(ts, '1 minute')
HAVING count(*) > 20;   -- alerts in <100ms

The list of things this pattern unlocks is long and, refreshingly, unglamorous: real-time monitoring and alerting, data enrichment, IoT and telemetry crunching, fraud detection, trading systems, dynamic pricing, customer segmentation that reacts within the session rather than the following week. RisingWave ships the core as an open-source engine written in Rust - a deliberate choice for a from-scratch database, where memory safety and predictable performance are worth the extra effort - and sells a managed version, RisingWave Cloud, for people who would rather not operate a distributed system themselves. In 2026 it shipped Cloud V2, a ground-up rewrite of its control plane, which is the sort of thing companies do when they have learned enough from the first version to be embarrassed by it.

Betting early on Iceberg, and on being in the middle

If there is a single strategic decision that will look either prescient or ordinary in hindsight, it is RisingWave's early embrace of Apache Iceberg, the open table format that by 2026 has become the thing every major data platform reads and writes. RisingWave's team includes core contributors to the Iceberg Rust project, and the company built what it calls a streaming lakehouse: operational database to change-data-capture to RisingWave to an Iceberg sink, with RisingWave sitting in the middle as the SQL layer that ingests, transforms, and writes processed results into open tables that Spark, Trino, or Databricks can all read. Being in the middle is a good place to be, provided the middle does not get commoditized. In 2025 the company announced an integration with Databricks and positioned itself as a launch partner for its open-format initiatives, which is the kind of partnership that signals RisingWave would rather interoperate with the giants than pretend it can replace them.

Demand showed up quickly

The clearest evidence that Wu was onto something came at launch. When RisingWave went open source, it reached more than 5,000 deployments and over 100 long-running clusters within 28 days - the kind of adoption curve that is difficult to manufacture and easy to believe, because developers do not spin up a database cluster to be polite. On the balance sheet, the company raised a $36 million Series A in October 2022, led by Yunqi Partners with undisclosed corporate and angel investors, bringing total funding above $40 million. The team is small - on the order of 43 people - and draws from AWS Redshift, Microsoft Azure, Snowflake, LinkedIn, and Uber, which is roughly the alumni network you would assemble on purpose if you were building a serious data system and wanted people who had already been burned by the hard parts.

A customer list that refuses to pick an industry

The named customers span sectors that do not obviously belong in the same sentence: PepsiCo and Siemens from the industrial world, Robinhood from fintech, Tencent from consumer internet, OpenSea from crypto, plus Thumbtack, Booksy, Henkel, and Shopline. The eclecticism is the point. Real-time data is not an industry so much as a layer, and RisingWave's bet is that every industry eventually needs it - manufacturers watching machines for predictive maintenance, banks scoring transactions for fraud, retailers repricing on the fly, healthcare systems monitoring patients. More than a thousand organizations run it in some form, which is enough to prove the thesis without yet settling the question of how many will pay.

And then, of course, agentic AI

No 2026 infrastructure story is complete without the word "agentic," and RisingWave has duly rebranded around "streaming infrastructure for agentic AI." It would be easy to be cynical about this, and one should reserve the right to be. But the underlying claim is more sober than the label: AI agents, whatever else they are, need fresh data delivered fast, and a system that already ingests, transforms, and serves real-time streams is a reasonable place to put that data. The pivot is less a change of product than a change of noun - RisingWave was always selling low-latency, correct, queryable real-time state, and it turns out that is a thing autonomous software wants as badly as a fraud team does. Whether the market rewards the framing is a separate question from whether the framing is honest, and this one is at least honest.

What RisingWave has not yet done is the thing every open-core company must eventually do, which is convert enthusiasm into durable revenue at a scale that justifies the ambition. It competes with Flink and its managed cousins, with Materialize, with Spark's structured streaming, and with a small crowd of streaming-SQL startups - and the winner of that fight will be decided less by benchmarks than by which one makes the boring version of a hard thing feel genuinely boring. On the evidence so far, RisingWave has a specific, defensible answer to that: make it look exactly like the database people already know, and get out of the way.