From data streaming to a data platform for the agentic era --- with a redesigned console, a Postgres-compatible SQL Workspace, and Rio, your data streaming assistant.
For seven years, whenever someone asked me what StreamNative was, I had a simple answer: we are a data streaming company.
Today, that answer changes.
We're introducing the StreamNative Data Platform, the evolution of StreamNative Cloud from a data streaming service into a complete data platform. Alongside it, we're shipping a redesigned console (Public Preview), SQL Workspace, a Postgres-compatible way to query your streams (Private Preview), and Rio, an AI assistant built directly into the platform (Public Preview).
This post is the story of why, and how the pieces fit together.
Let me start with an observation about agents. An agent is a loop: it reads context, decides, and acts. The model handles the deciding, and the models are genuinely good now; every company can call the same frontier intelligence with an API key. The reading and the acting run on your data infrastructure, and that's where production agents fail. Not because the model isn't smart enough, but because the data underneath it is stale, fragmented, and locked behind interfaces designed for human hands. An agent working from last night's snapshot can't see the order that just failed or the payment that just cleared. It will reason beautifully about a business that no longer exists.
The models are interchangeable now. The context isn't. It lives in your databases, your SaaS tools, and your event streams, in a shape unique to your company, and agents consume it at a rate no dashboard user ever did.
The Lakehouse Analyzes the Business. Something Has to Run It.
The data that runs your business is the point. Orders, payments, inventory, user sessions, machine telemetry --- this is the business, happening in real time. The systems that consume it are production systems: they face customers, hold SLAs, and increasingly include agents.
Analysis came after. We copy operational data into warehouses and lakehouses to understand what happened and decide what to do next, and the lakehouse solved that problem well: open table formats, one governed copy in your own object storage, a decade of engines that can query it. We integrate deeply with that world, and nothing here changes it. But the lakehouse made design choices that fit its job. Data arrives in batches, hours or days late, queries are shaped for analysts, and the SLAs are internal. That's fine for analysis. It's a bad fit for anything that has to run the business.
So the operational side of the business, the primary side, has been living on infrastructure built for the other one, plus whatever teams could stitch together themselves. You've probably seen the stitches. A service in your repo named something like kafka-to-postgres-sync, written two years ago, owned by nobody, load-bearing. A Flink cluster that exists to answer one question. Security reviews that end with agents cut off from production databases entirely, because those interfaces were never designed for a non-human reader.
Earlier this year we introduced Lakestream, an open architecture pattern where streams and tables become one: every stream lands as an open table on object storage the moment it's written. Lakestream fixed storage and movement for operational data. What it didn't yet give you is everything above that: a way to connect every source, query the streams directly, govern the result, and serve it to people and agents at production SLAs.
That full stack is what the operational side of the business needs. We call it a real-time data foundation. Lakestream is its storage layer, and today we're building the rest of it upward.
Introducing the StreamNative Data Platform
We started as the creators of Apache Pulsar™ and built our reputation running some of the largest streaming workloads in the world. Then we rebuilt the engine itself: Ursa, our lakehouse-native streaming engine, leaderless and diskless, writing streams directly to object storage in open table formats. It cut streaming costs by up to 95% and won the VLDB 2025 Best Industry Paper award along the way. This spring we surprised a few people by becoming a Kafka company, too: native Apache Kafka® and native Pulsar, side by side, on one engine.
One belief drove every step: open protocols win. Kafka and Pulsar won streaming; Apache Iceberg™ and Delta Lake won the lakehouse. Every time we bet on an open interface, the platform got more valuable.
Somewhere along the way, the old label stopped fitting. Data was flowing in through connectors, moving through Kafka and Pulsar, landing as governed tables in the lakehouse. Customers kept asking why, with the data all here, their teams --- and now their agents --- still couldn't simply use it. What we were operating was no longer just a streaming platform. The honest name for it is a data platform.
I know how that sounds. Every vendor eventually calls itself a data platform, and for years we didn't use the phrase ourselves for exactly that reason. What earns it now is what the platform actually does: a data layer that connects, streams and stores, and queries real-time data; a governance layer that makes it trusted; and an experience layer that people and agents both operate. Let me walk through the three.
The Data Layer: Connect, Stream & Store, Query
A data layer for running the business has three verbs in it. Frankly, until today we only shipped two.
Connect.UniConn, our managed connector engine, streams data in from databases via CDC, from SaaS applications, and from logs. And if you already run Kafka somewhere else, Data Links and Schema Links mirror your data and schemas over without downtime --- the on-ramp doesn't require a migration weekend. Wherever your data is born, there's a governed path onto the platform.
Stream & store. Kafka and Pulsar run as native protocols on Ursa. Storing isn't a second step: events flow through topics and land as Iceberg and Delta tables in your object storage at the same time. No connectors between your streams and your lakehouse. No ETL pipeline to babysit. Streaming stops being an expensive, isolated tier and becomes the real-time layer of the same lakehouse everything else already uses.
Query. This is the verb we were missing. SQL Workspace, powered by the RisingWave SQL engine, puts Postgres-compatible SQL directly on your streams. Topics show up as sources you can query. Tables hold state. Materialized views do the continuous work: write a join across your order, payment, and fulfillment topics once, and the view stays current as events arrive, with no batch schedule and no refresh job. Sinks push results to downstream systems. You can poke at a topic in the browser editor, and when the query is right, leave it running for good.
Every SQL Workspace is a PostgreSQL-compatible endpoint. What the Kafka protocol did for streams, the Postgres protocol does for queries: one open interface, and the whole ecosystem plugs in. psql, DBeaver, your BI tools, your applications --- if it speaks Postgres, it can query your streams. Most agent frameworks already do.
That completes the data layer. For the architecture and a full walkthrough, read Introducing SQL Workspace in StreamNative Cloud.
The Governance Layer: What Makes Context Trusted
When we sit in security reviews with platform teams, the fear is rarely the model. It's an agent touching data nobody governed.
Our answer is structural. Streams on this platform physically are tables, so they inherit the governance the lakehouse world already built. The platform registers the tables Ursa writes into the catalogs you already run (Unity Catalog managed tables, Snowflake's Horizon Catalog, and Iceberg REST-compatible catalogs across clouds), so streaming data is discoverable, permissioned, and auditable with the same tools as everything else you govern. One copy of the data, fine-grained access control across streams and tables alike, and more native catalog capability on the way.
It also means the platform feeds your lakehouse instead of fighting it. The operational data we capture and refine is the same governed data your analytical world builds on.
The Experience Layer: Agents Are the New Users
Data platforms have always had two interfaces: a console for people and APIs for software. Agents need a third, one that is conversational, tool-based, and loaded with operational knowledge. We've been building it in the open all year. The StreamNative MCP Server gives any MCP-compatible client (Claude, Cursor, or your own agents) typed, permissioned access to the platform, now managed at the organization level. StreamNative Agent Skills package our operational know-how into skills those agents can load.
Today we're adding the two biggest pieces.
The redesigned console (Public Preview) rethinks the experience for both kinds of user: a home page with key metrics and global search, navigation that goes from organization to instance without the scavenger hunt, one guided place to create Kafka clusters, Pulsar clusters, and SQL Workspaces, and dedicated views for connections, catalogs, and migration.
And Rio (Public Preview). Rio is the AI mode of StreamNative Cloud, built directly into the console. No MCP client to configure, no separate setup: open the side panel and ask which clusters need attention, what a configuration actually does, or why a connector is lagging. Sessions persist, so you can leave an investigation on Tuesday and pick it up Thursday. The name is the Spanish word for river. Ursa is the engine underneath; Rio is where you work with your streams.
An assistant on production infrastructure has to earn trust, so Rio is built cautious. Changes go through dry-run, approval, and diff review, and AI-generated SQL never runs without a human saying so.
For the full tour of the new console and Rio, read A New StreamNative Cloud Experience.
Four Open Interfaces, One Platform
Streams speak Kafka and Pulsar. Tables speak Iceberg and Delta. Queries speak Postgres. Agents speak MCP.
Every interface in that list existed before today. The platform is new; nothing you have to learn is. That's the same conviction that has carried us from day one --- platforms built on open protocols compound in value, because any tool or agent can plug in. Your data stays yours: in your buckets, in open formats, reachable through interfaces that no vendor controls, including us.
The Road Ahead
Where everything stands today:
- New StreamNative Cloud console --- Public Preview, rolling out
to all users. Start a free trial to explore it.
- Rio --- Public Preview, available in the new console.
- SQL Workspace --- Private Preview. [Contact the StreamNative
team](https://streamnative.io/contact) to request access. It's also how you finally get to delete that kafka-to-postgres-sync service.
There's more coming. September brings news on the open-source front, the public preview of SQL Workspace, and Apache Pulsar 5.0. On October 7--8 in San Francisco we host Data Streaming Summit: The Data + Agent Conference, where the other half of this story gets told: trusted real-time context is what agents consume, and where they run and how they're governed is a story of its own. The pattern behind all of this, an operational counterpart to the lakehouse, is bigger than one company. You'll hear more from us, and from others across the industry, very soon.
Come see what that means.
