RisingWave 3.0: The real-time context layer for interactive AI

The turn

Real-time data systems are becoming the context layer for AI.

An agent is only as good as the context it can reach — the embeddings it retrieves, the records it joins against, the state of the world at the moment it acts. And that context goes stale fast. A vector index rebuilt nightly, features recomputed on a schedule, a knowledge base re-embedded in a weekend batch job — each of these quietly hands the model a picture of the world that is already hours out of date.

RisingWave has always been built around a single idea: keep data continuously fresh, without rebuilding it from scratch on every query. That is exactly what the context behind an agent needs. We are not arriving at AI as another vector database racing to catch up — we are bringing a streaming engine, designed from day one to keep results fresh, to the place where freshness now matters most.

RisingWave 3.0 brings native vector search and an open lake for AI's memory onto one always-fresh engine. It also opens the 3.x series — our push toward a single real-time context layer for interactive AI.

This release rests on three things: context that stays fresh by default, an AI-native engine that lives in one system, and a lake that serves as durable memory for both analytics and AI.

Context that's always fresh

Most AI data stacks bolt freshness on after the fact. A pipeline extracts data in batches, a job recomputes embeddings on a timer, an operator reindexes by hand. Every one of those steps is a place where the context drifts away from reality.

RisingWave builds freshness into the engine instead.

Materialized views are maintained incrementally and refresh on their own — there is no REFRESH MATERIALIZED VIEW, because there is nothing to trigger. When source data changes, only the affected rows are recomputed. This is the same mechanism that has always powered RisingWave's analytics, and in 3.0 it powers AI context too:

Incremental embedding. When a source row changes, only that row is re-embedded and only the downstream index is updated. No nightly full re-embedding, no manual reindexing.
One engine for compute and serving. The same system that incrementally maintains your context also serves it at low latency — there is no separate freshness layer to operate.
Built in, not bolted on. Context stays fresh as a property of the engine, not as a pipeline you have to keep alive.

Vector search is now table stakes — plenty of systems have it. What can't be copied easily is keeping that context incrementally fresh, with analytics and serving on the same engine. That is the heart of what 3.0 is for.

AI-native, in one engine

3.0 makes vector search a first-class part of the streaming engine, not a separate system stitched on beside it.

Native vector search

A native vector type, with FLAT (exact) and HNSW (approximate) indexes. Distance types include l2, cosine, l1, and inner_product, each with a dedicated operator (<->, <=>, <+>, <#>).
Streaming vector index lookups. Inside a streaming job, expand every incoming row with its Top-N nearest neighbors and write the result to a materialized view, a sink, or a sink-into-table — the foundation for real-time RAG and live enrichment.
Index on a function expression, so you can index get_embedding(description) directly instead of materializing and storing a separate vector column.
Because a vector is just another column, similarity search composes with relational filters and joins in a single SQL query — embeddings and structured metadata, side by side.

In-stream embedding

Embed text directly in SQL with the built-in openai_embedding function.
Plug in any embedding model — including multimodal (image, audio, video) models — through Python or external UDFs, returning a vector that RisingWave stores and searches natively.

All of this runs on the always-fresh engine described above. Embedding and retrieval aren't external systems you sync against; they're part of the same continuously-maintained pipeline.

The lake as AI's memory

A lake isn't just another sink. For an agent, it's long-term memory — the open, durable store of everything the model may need to recall.

In 3.0, RisingWave's Iceberg integration grows from a sink into a full table engine:

Support for Iceberg V2 and V3 formats, with both Merge-on-Read and Copy-on-Write.
Built-in table maintenance and compaction — small-file optimization and snapshot cleanup handled for you, no external tooling.
A built-in query engine powered by Apache DataFusion, speaking PostgreSQL dialect.
Source-to-destination automatic schema evolution, plus a streaming, refreshable Iceberg source.

Because Iceberg is an open format, the same data is readable by Spark, Trino, DuckDB, and any other compatible engine — your memory layer isn't locked inside RisingWave.

And this is where the analytics story and the AI story converge. The structured side (analytics) and the unstructured side (embeddings for AI) live on one continuously-fresh foundation: one copy of the data, one open lake, serving both.

Ship it to your stack

Your AI context shouldn't be stranded inside one system. 3.0 streams it out to where your applications already live.

Native sinks to Turbopuffer, LanceDB, and Zilliz. RisingWave streams embeddings into your vector store continuously and incrementally, so the indexes you serve from stay fresh. (These are sinks — RisingWave writes to them.)
Vector databases themselves are converging on the lake — object storage, open formats, separated compute and storage — bringing structured and unstructured data into the same place.

The connector layer feeding all of this is stronger in 3.0 too:

Parallel CDC backfill for faster historical loads.
End-to-end automatic schema evolution from source to destination.
Refreshable batch sources.
Webhook and WebSocket ingestion, for pushing events straight into RisingWave.

Production-grade

A release that sets direction has to be something you can actually build on. 3.0 hardens the engine across the board.

Backfilling & isolation

Locality backfill, 2x–10x faster on supported workloads.
Snapshot backfill with stronger isolation.
Backfill order control and index selection for fine-grained control over job creation.
Database isolation and cross-database streaming queries.

Performance (RisingWave Ultra)

A tunable elastic disk cache.
Fine-grained cache refilling across streaming and serving.
Memory-warmed state tables to avoid cold cache misses.
Dynamic compaction group split and merge.

Stream processing & SQL

Watermark-consistent state TTL for tables.
Partial-update SINK INTO TABLE for upsert streams.
AS CHANGELOG subscriptions and batch CURSOR consumption.
Zero-downtime materialized view rebuilds via ALTER ... SWAP WITH ....
Job-level runtime configuration changes.

Security

Built-in secret management, including a native secret store and HashiCorp Vault integration.
LDAP authentication.
Stronger TLS for sources and sinks.
View-level privileges for row-level security.

Observability

Streaming EXPLAIN ANALYZE.
The RisingWave Console for on-prem deployments.
A richer rw_catalog of system tables and functions.
Improved visibility into jobs, fragments, and resource usage.

Deprecations & breaking changes

The CANAL and MAXWELL formats are deprecated.
NO_SHUFFLE backfill is deprecated. The regular NO_SHUFFLE dispatcher (used, for example, by dynamic filters) is unaffected.
Several parallelism configuration options have been unified and simplified.

Please review these before upgrading.

The 3.x trajectory

3.0 lays the foundation. Here's where the series is headed — directions we're actively investing in, not finished features:

Built-in chunking, so the full path from ingestion to chunking to embedding to serving lives in one SQL pipeline, with no external preprocessing step.
Deeper, native multimodal embedding, promoting multimodal from the UDF path into the engine itself.
A truly unified structured + unstructured lake, where analytics and AI memory converge on one set of storage and governance — not two stores kept in sync, but one.

Across the 3.x series, we're building toward a single real-time context layer for interactive AI — fresh by default, with analytics and memory on one open lake.

Get started

RisingWave 3.0 is available now.