StreamNative and RisingWave are building an open-standard real-time streaming stack for the operational side of the business — Kafka and Pulsar for streams, Postgres for queries, Iceberg for tables.
There's an architecture diagram our two teams have seen too many times: events flowing through Apache Kafka® and Apache Pulsar™ on one side, the applications and dashboards that need answers on the other, and a dotted line between them labeled "custom." For years, our field teams kept running into each other in the same accounts, on opposite ends of that line — StreamNative moving a company's events, RisingWave turning them into something a person or an application could actually query. The line in the middle was always a pile of glue: a pipeline to build, a second vendor to onboard, another security review, a connector fleet somebody now owns.
Today we're getting rid of the glue. SQL Workspace, now in Private Preview in StreamNative Cloud and powered by the RisingWave SQL engine, puts Postgres-compatible SQL directly on your streams, inside StreamNative Cloud and inside your VPC. It's the first step in something bigger we've decided to build together: an open-standard, real-time streaming stack for the operational side of the business, and for the agents starting to run it.
An Open-Standard Streaming Stack
We're both engine builders, and we built different systems on the same bet: build on interfaces nobody owns.
At StreamNative, that meant Ursa, a leaderless engine that writes Kafka and Pulsar streams straight to object storage as Apache Iceberg™ and Delta tables. At RisingWave, it meant a streaming database that maintains materialized views incrementally, keeps its state on S3, and speaks the Postgres wire protocol instead of inventing its own.
The obvious question is why we didn't each just build the other half ourselves. Of course we looked. A streaming database is its own multi-year discipline, and RisingWave had already spent five years on exactly the bets we would have made: state on object storage, the Postgres wire protocol, incrementally maintained views. They were further along than we could get alone, and the same logic runs the other way — RisingWave gets a streaming backbone it doesn't have to operate. Partnering was the honest answer.
So the stack needs no translation layers. Streams speak Kafka and Pulsar, tables speak Iceberg, and queries speak Postgres — pick almost any tool in the world and it already speaks one of the three. We didn't invent an interface for this partnership, and that's the point. It's also your guarantee of an exit: everything here stays readable and portable through interfaces no vendor controls.
SQL on Your Streams, Out of the Box
Putting SQL on streams used to be a project: a processing cluster to size and operate, connectors on both ends, state stores, schema reconciliation, and an argument about whose support contract covers the seam.
SQL Workspace collapses that into a workflow. Create a workspace in StreamNative Cloud, point it at your Kafka and Pulsar clusters, and your topics show up as sources. Write SQL against them in the browser. Turn a query into a materialized view (for example, joining order, payment, and fulfillment events into a live order-status view) and it stays current as events arrive. Add a sink when you want results pushed to a downstream database. One signup, one console, one VPC. The governance you set upstream carries through to what gets served.
And the support-contract argument ends here: SQL Workspace is a StreamNative Cloud service. If something breaks at the seam, StreamNative fixes it.
For the full walkthrough, read Introducing SQL Workspace in StreamNative Cloud.
The Stack Agents Can Rely On
Agents change the load profile. A person asks a dashboard a few questions a day; an agent re-checks its context on every decision it makes, at machine rate, through machine interfaces: SQL, APIs, MCP.
The stack is built for that consumer. Every SQL Workspace is a Postgres-compatible endpoint, and Postgres is the interface agent frameworks already speak — no custom SDK required. Because the views are maintained incrementally, updated as events arrive rather than recomputed on a schedule, the read an agent makes is a lookup, not a scan: governed, current context fetched in milliseconds, shaped by SQL your team reviewed. We're also bringing RisingWave's MCP tooling into the StreamNative Cloud MCP server, so agents (including Rio, the assistant built into StreamNative Cloud) can discover and query workspaces the same way engineers do.
For where this fits in the bigger picture, read the blog Introducing the StreamNative Data Platform.
Open Source, Upstream, Together
Both engines are open source at the core, and the partnership works the way open source does: upstream. Building SQL Workspace has already sent improvements back — schema registry integration and OAuth support for Pulsar in RisingWave, with more coming. RisingWave started with a mission to democratize stream processing. StreamNative started with the belief that open protocols win. Neither of us is changing that for the other: SQL Workspace connects to StreamNative clusters out of the box, and RisingWave stays RisingWave, an open engine you can run anywhere, with or without us.
Where This Goes
On August 27 we're co-hosting a live webcast, Real-Time Context on Demand: Query Your Streams with SQL, where our product teams demo all of this end-to-end.
SQL Workspace is in Private Preview today. Contact the StreamNative team to request access, point a workspace at a cluster, and retire the first piece of glue the same afternoon. And on October 7–8 in San Francisco, we'll share a joint session at Data Streaming Summit: The Data + Agent Conference.
The operational side of the business is getting its stack. We're building it in the open, together. Come watch on the 27th.
