You're on RisingWave: It Keeps Your Streaming Views Fresh. Data Workers Owns Whether What They Serve Is Right
RisingWave 3 keeps streaming SQL results fresh in Postgres-compatible views. Data Workers checks what those views and sinks land, traces a quiet or wrong result to its cause and gets the fix approved.
Your team runs RisingWave. Sources read Kafka topics and CDC from Postgres, MySQL or MongoDB. Materialized views stack on top of each other, each kept current as events arrive, with watermarks and windows for event-time logic. Apps, Grafana panels and agents query the views over the Postgres protocol on port 4566, and sinks write results to Iceberg, Kafka or the warehouse. You run it on RisingWave Cloud, in your own cloud with BYOC, or self-managed under Apache 2.0. RisingWave 3.0 shipped on June 11, 2026; v3.1.0 was tagged on GitHub on September 21, and the docs still list it as upcoming.
RisingWave is excellent at its job: one Postgres-compatible system in place of a broker, a stream processor and a serving database. Whether its results are right is a different job. A view can be fresh, every job healthy, and still serve nothing to the service that holds cards. Data Workers watches what your views and sinks land, traces a quiet or wrong result to the change behind it, and gets the fix approved before a customer or a report acts on it.
Key takeaways
- •RisingWave keeps its job. Sources, materialized views, sinks, watermarks and DDL stay with your streaming team. Data Workers works on what the views land and everything downstream of them.
- •Connected from day one. Data Workers reads the warehouse tables, dbt models, orchestrators and BI around RisingWave natively; your team inspects RisingWave itself with its MCP server on a read-only role.
- •Fresh and right, checked where results land. When a producer change leaves a view quiet or wrong, Data Workers turns it into one incident with the likely cause and every table and job that would spread the damage.
- •Every fix goes through a named person. The owner approves the holds and the DDL, and applies them in RisingWave.
- •Autonomy is set per domain. Start at L1 observe, move to L2 propose, and open L3 act reversibly for narrow classes once the record supports it.
RisingWave is the streaming database that keeps your views fresh. Data Workers owns whether what they serve is right.
The job around RisingWave is to notice a wrong or missing result, find the change behind it, hold what would act on it, get the fix made and prove it. Here is one Thursday at a card issuer. This is an illustrative example.
The payments service publishes every card authorization as JSON to the Kafka topic card-auths. In RisingWave, the source card_auths declares WATERMARK FOR event_time AS event_time - INTERVAL '5' SECOND. The materialized view fraud_velocity_5m counts authorizations per card in 5-minute tumbling windows, joins a merchants table kept current by MongoDB CDC, and uses EMIT ON WINDOW CLOSE, so each window is written once, final. A card-hold service queries the view every minute. An Iceberg sink appends each closed window to risk.fraud_velocity_5m in the AWS Glue catalog. Snowflake reads that table through a Glue catalog integration, and at 18:00 the Airflow 2 DAG finance_daily runs the dbt model fct_chargeback_exposure behind the Tableau workbook finance opens every morning.
| Time | System | What happens |
|---|---|---|
| Thu 16:22 | GitHub | PR #4471 merges in payments-service: a naming cleanup renames event_time to authorized_at in the authorization event. The release goes out at 16:30 |
| 16:30 | Kafka | New events on card-auths carry authorized_at. The topic is JSON with no registry subject, so nothing rejects them |
| 16:30 | RisingWave | The source reads the missing event_time as NULL. A NULL never advances the watermark, so it stays at 16:29:54, and the watermark filter drops the NULL rows. fraud_velocity_5m closes no more windows. Every streaming job is healthy and no error is raised |
| 16:31 | RisingWave + Iceberg + Grafana | The sink commits no new rows. The card-hold service finds nothing to hold, and Grafana's velocity alerts read zero: it looks like a calm afternoon |
| 17:05 | Data Workers + Snowflake | The window-lag metric the team records with monitor_metrics on RISK.FRAUD_VELOCITY_5M breaks its bar: the newest window ends at 16:25, 40 min behind a 10-min limit. The rows-per-window metric the team records with monitor_metrics reads zero against a baseline of about 180. Data Workers opens an incident and pages the fraud-platform owner in PagerDuty |
| 17:12 | Data Workers + dbt | diagnose_incident places the break at 16:30 and ranks an upstream producer change first. blast_radius_analysis from the Snowflake table returns fct_chargeback_exposure and, through the team's context-graph note, the Tableau workbook; the team's context-graph note ties the model to the 18:00 finance_daily run |
| 17:15 | RisingWave MCP | In the same client, the owner uses the RisingWave MCP server on a read-only role: the source's watermark is on event_time, and a sample shows event_time NULL in every row since 16:30. The 16:30 release carries PR #4471 |
| 17:18 | Slack | The approval request goes to the fraud-platform owner, with the finance data owner copied |
| 17:35 | Spellbook | She reviews three proposals: hold finance_daily; a DDL diff for a new source card_auths_v2 with authorized_at, a generated column event_ts AS COALESCE(authorized_at, event_time) carrying the watermark, and a Kafka start at 16:25, plus fraud_velocity_5m_v2 and a v2 sink into the same Iceberg table in place of the v1 sink; and a note asking the payments team to treat authorized_at as the contract. She approves all three |
| 17:40 | Airflow | She pauses the finance_daily schedule |
| 17:50 | RisingWave | She applies the diff from the team's migration repo and points the card-hold service at the v2 view. v2 reads card-auths from 16:25 and catches up by 18:04 |
| 18:06 | Iceberg + Snowflake | The sink appends the windows since 16:25. Fourteen cards that burst during the gap go to fraud operations for review |
| 18:15 | Data Workers + Snowflake | Data Workers verifies: the window-lag and rows-per-window metrics are back on baseline. The owner's check finds one row per card and window |
| 18:25 | Data Workers + Airflow | Data Workers queues the approved finance_daily run with trigger_airflow_dag; it finishes at 18:48. The receipt records cause, approvals, DDL, checks and the undo (drop the v2 objects and restore the v1 sink; v1 stays until the owner signs off) |
| 18:50 | Airflow + Tableau | The owner resumes the schedule. Tomorrow's exposure workbook includes the gap |
Every part of RisingWave did what it was told. Its docs list a missing watermark on a time-windowed view among the common pitfalls: rows never emit. A NULL event time has the same effect, and from inside the database a quiet window looks like a quiet afternoon. Catching it takes knowledge outside the view: that zero alerts is abnormal for a Thursday, and that finance closes on the table the sink writes.
| Job | What RisingWave does | What Data Workers does |
|---|---|---|
| The computation | Ingests from Kafka and CDC, keeps cascading materialized views fresh, with watermarks and windows for event time | Reads the catalogs, tables, models and jobs around it natively; the team inspects RisingWave with its MCP server |
| The serving | Serves fresh results over the Postgres protocol to apps, dashboards and agents | Ties the tables a view lands in to the services, models and reports that read them, so a quiet view shows up as a data incident |
| The results | Sinks to Iceberg, Kafka and warehouses, and manages Iceberg tables with compaction | Checks what sinks land: nulls and volume on Snowflake and BigQuery, plus the team's key metrics against a baseline |
| The fix | Runs whatever DDL the owner applies: new sources, views, sinks, watermarks | Proposes the holds and the DDL diff to a named owner, then queues the approved downstream runs |
| The proof | Keeps streaming job status, backfill progress and system catalogs | Re-checks the data and writes a receipt: what changed, who approved it, how it was checked, how to undo it |
Why doesn't RisingWave just do this itself?
Because RisingWave is a streaming database, by design, and that focus is why teams trust it to replace three systems. Its guarantees are precise: consistent results across views and joins, exactly-once processing, windows that close exactly when the watermark says. Whether zero velocity alerts is plausible on a Thursday is a question about the business, and a database rightly leaves meaning to the people who write the SQL.
RisingWave's AI work follows the same scope: a vector type and vector indexes, an openai_embedding function, and fresh views served to agents. The open-source RisingWave MCP server gives an assistant more than 100 tools, from read queries and catalog lookups to DDL and DML that create and drop views, sources and sinks or change rows, acting with the database role in its connection string. Deciding whether a DDL change is the right fix for a Snowflake table, a dbt model and a finance workbook, and who has to approve it, sits outside a database's scope, as it should.
Owning whether the data is right from Iceberg through Snowflake, dbt and Tableau is a different product with a different liability: a context graph, blast-radius scoping, approvals that name a person, a recorded undo and receipts an auditor can read. That is Data Workers. See is it safe to let AI agents change production data.
Every tool owns a slice. Data Workers covers the whole lifecycle
RisingWave owns keeping streaming SQL results fresh. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the RisingWave views already there.
| Stage | Data Workers | RisingWave | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 3 | System catalogs list sources, materialized views and sinks inside the database; owners, meaning and consumers live elsewhere. Data Workers keeps one governed context graph from the landed table to the models and dashboards that read it. |
| Analytics & Insights | 8 | 6 | Materialized views serve fresh results over the Postgres protocol, and DataFusion queries the Iceberg tables. Data Workers answers data questions from governed definitions with lineage behind every number. |
| Data Quality | 8 | 4 | Views are kept consistent and fresh; whether a result is right is SQL the team writes. Data Workers checks what views land downstream, so a quiet view with missing results still raises an incident. |
| Observability & Incidents | 8.5 | 4 | Streaming job status, backfill progress, barriers and sink lag show the cluster's health. Data Workers diagnoses the data incident across the landed tables, the models and the jobs downstream, then verifies the fix. |
| Pipelines & Ingestion | 8.5 | 9 | RisingWave's home stage: sources from Kafka and CDC, cascading materialized views with watermarks and windows, and sinks to Iceberg, Kafka and warehouses. Data Workers plans the repair and queues the downstream reruns for the owner. |
| Schema & Migration | 8 | 4 | Sources can add columns, and watermarks follow the column they are defined on; schema contracts with producers are the team's to keep. Data Workers sizes a schema change on the tables sinks write against every model and report that reads them. |
| Governance & Access | 8.5 | 3 | Users, roles and privileges guard who may query or change objects. Data Workers routes every data change to a named approver and records the decision. |
| Security & Privacy | 8 | 4 | Secrets, TLS and the cloud's network controls protect the cluster. Data Workers leaves a receipt on every data change. |
| Cost / FinOps | 8 | 4 | Compute and storage scale apart, and parallelism is tunable per job. Data Workers traces Snowflake spend to the dbt model behind it through query tags and sets a scan budget per session. |
| MLOps & Models | 7.5 | 4 | A vector type, vector indexes and an embedding function bring features and context to agents. Data Workers keeps the data under models and agents healthy. |
How RisingWave and Data Workers work together
Data Workers reads what RisingWave lands in Snowflake and BigQuery natively, and the Iceberg catalogs behind it (Glue + Lake Formation, Iceberg REST, Polaris, Nessie) connect over their APIs today. Then dbt manifests, Airflow 2 DAG runs and task status, Tableau (read), GitHub (pull-request review), Slack and PagerDuty, among 50+ connectors. If Kafka Connect or Schema Registry sit beside RisingWave, Data Workers reads each connector's status with get_connector_status and registers a new schema version with register_stream_schema only after a named approval.
RisingWave itself is inspected by your team with the RisingWave MCP server, which understands sources, materialized views and sinks. It sits next to Data Workers in the same client: RisingWave answers "what does this source or view look like right now", and Data Workers answers "is what it landed right, what reads it, and what's the fix".
By design, Data Workers runs no DDL in RisingWave: sources, views, sinks, watermarks and Kafka offsets belong to the owner, through the team's migration repo, psql or the RisingWave Cloud console. Data Workers proposes them as a diff, scopes what they touch and verifies the landed data afterwards. Lag comes from the monitoring you already run; Datadog and OpenTelemetry are native reads.
The Data Workers side follows the documented client setup: clone the open-source repo and add each agent's start-agent.sh entry to your client. The RisingWave MCP server goes in the same client with a connection string for a read-only role.
# Example: Data Workers agents plus the RisingWave MCP server in Claude Code
claude mcp add --scope user dw-incidents -- "$(pwd)/start-agent.sh" dw-incidents
claude mcp add --scope user dw-quality -- "$(pwd)/start-agent.sh" dw-quality
claude mcp add --scope user dw-catalog -- "$(pwd)/start-agent.sh" dw-context-catalog
claude mcp add --scope user dw-connectors -- "$(pwd)/start-agent.sh" dw-connectors
claude mcp add --scope user dw-schema -- "$(pwd)/start-agent.sh" dw-schema
claude mcp add --scope user risingwave \
-e RISINGWAVE_CONNECTION_STR="postgresql://rw_reader:<password>@<host>:4566/dev" \
-- python /path/to/risingwave-mcp/src/main.pyList the tools with your client's own command (/mcp in Claude Code). In this incident: monitor_metrics and diagnose_incident (dw-incidents) flag the zero windows and rank the cause; run_quality_check (dw-quality) checks volume and nulls on the Snowflake table; trace_cross_platform_lineage and blast_radius_analysis (dw-context-catalog) map what reads it; trigger_airflow_dag (dw-connectors) queues the approved run on Airflow 2. For a schema change on a table the sinks write, assess_impact (dw-schema) sizes it downstream.
The agents run in your infrastructure with your credentials and model key; your data stays in your systems and the hosted Conductor sees workflow metadata only. More in where does our data go.
One incident, L0 to L4, set per domain:
- •L0 manual. Someone notices next morning that the alerts panel went flat at 16:30.
- •L1 observe. Data Workers flags the stale table at 17:05 with the 18:00 finance run in the blast radius. Nothing changes; the owner starts from the answer.
- •L2 propose. Data Workers proposes the hold and the DDL diff. Nothing reaches production until the named owner approves; an unanswered request expires and escalates, never auto-grants.
- •L3 act reversibly. For a class with a clean record, Data Workers queues approved runs inside the domain you open, verifies them and sends any failed check to a person. DDL stays with the owner.
- •L4 autonomous. Once the owner's DDL lands, Data Workers queues the downstream runs, re-checks the metrics and posts the receipt without waiting.
Who sets those levels: who owns the agents, how approvals work for AI data agents and autonomy levels L0 to L4 explained.
What changes for your team
- •Streaming, fraud and finance share one record. They see the same incident and receipt in Spellbook Data Catalog (in preview), linked from Slack.
- •Quiet gets a baseline. Views that emit on window close get a rows-per-window metric, so zero alerts reads as an incident, not a calm afternoon.
- •Producer changes get a downstream check. A renamed field, a new type or a dropped column is weighed against every table, model and report that reads the results.
- •DDL fixes have a plan. The new source, the start offset, the sink swap and the downstream reruns arrive as one approved sequence with a recorded undo.
Keep RisingWave, or consolidate?
Keep RisingWave if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For almost every RisingWave team the answer is keep it. What teams consolidate is the tooling around the results: a separate data observability tool, alert rules nobody tunes, and runbooks that say "check the panel and ask the payments team". If Kafka feeds your sources, see you're on Apache Kafka; if you run stream jobs in Flink, see you're on Apache Flink; if you are weighing another incremental view engine, see you're on Materialize. Data Workers integrations lists what connects natively, and Data Workers vs data observability covers the monitoring question.
Building this yourself on the RisingWave MCP server? Read build it ourselves with Claude Code and MCP servers: the context graph, approvals, undo and receipts are the work.
The case for your CFO
The outcome. When a producer change leaves a RisingWave view quiet or wrong, the numbers built on it are caught within the hour and corrected before anyone acts on them.
The risk story. At L0 and L1, agents only read. At L2 they propose and a named person approves; an unanswered request expires and escalates, never auto-grants. At L3 they act on reversible changes inside the domains you open; L4 is a later choice per domain. DDL in RisingWave stays with the owner. No agent can promote its own work, and an org-wide stop halts all autonomous dispatch. Every change carries a receipt: what changed, who approved it, the blast radius and how to undo it.
Why now. Card holds, alerts, agents and finance tables read streaming views within seconds. A view that goes quiet stops protecting the business before a person sees it.
What stays the same. RisingWave and how you run it, your sources, views and sinks, Kafka, Iceberg, the warehouse and your on-call rota. Zero migration. For the numbers, see the ROI of agentic data operations.
The sentence for upstairs: "RisingWave keeps our real-time numbers fresh; Data Workers makes sure they are right, and gets them fixed with our approval when they aren't, before a hold, an alert or a finance report acts on them."
Getting started
Start with a pilot. Pick the views that feed holds, alerts or finance tables, give Data Workers read access to the catalog, warehouse and orchestrator downstream, record the metrics that define "right" for each view, and run at L1 through a few producer releases. Then turn on L2 for one domain, and open L3 for a narrow class once the receipts show the agents were right. The pilot path is on the pricing page, and the pilot is credited in full against the first year.
FAQ
How does Data Workers connect to RisingWave? Through what RisingWave lands. The Iceberg catalogs, warehouse tables, dbt models, orchestrators and BI around it connect natively. For source and view definitions, job status and row samples inside RisingWave, your team uses the RisingWave MCP server in the same client.
RisingWave is Postgres-compatible. Can Data Workers use its PostgreSQL connector? The PostgreSQL connector is built for PostgreSQL's own catalog, and RisingWave runs its own catalog with sources, materialized views and sinks, so the RisingWave MCP server is the path that understands those objects. The PostgreSQL connector reads the Postgres databases your CDC sources come from.
Our streaming jobs are healthy. How can a view be wrong? Healthy jobs don't say the input still means what the SQL expects. A renamed field reads as NULL; a NULL event time never moves the watermark, and a view that emits on window close goes quiet. Data Workers checks the results where they land.
Will Data Workers change our sources, views or sinks? No. DDL, watermarks, sink swaps and Kafka offsets stay with the owner, through your migration repo, psql or the RisingWave Cloud console. Data Workers proposes the change as a diff and verifies the data afterwards.
The RisingWave MCP server can drop objects. What role should it run with? A read-only role for inspection. The owner applies DDL through the change process you already trust, and the approval and receipt live in Spellbook.
We sink to Iceberg and read it in Snowflake. Where does Data Workers check? On the Iceberg table through the Glue catalog, and in Snowflake with run_quality_check for nulls and volume, plus the per-window metrics your team records with monitor_metrics.
Sources
- •RisingWave homepage ("Streaming Infrastructure for Agentic AI"; managed Iceberg powered by DataFusion), https://risingwave.com/ (checked Oct 3, 2026)
- •RisingWave pricing (fully hosted, BYOC or BYOK8s; self-manage under Apache 2.0), https://risingwave.com/pricing/ (checked Oct 3, 2026)
- •RisingWave docs index (Postgres wire compatibility on port 4566; missing watermark on a time-windowed view among common pitfalls; MCP server), https://docs.risingwave.com/llms.txt (checked Oct 3, 2026)
- •RisingWave docs, Watermarks (WATERMARK FOR syntax; updated only when the new value is greater; generated columns for expressions), https://docs.risingwave.com/processing/watermarks (checked Oct 3, 2026)
- •RisingWave source, watermark filter (NULL values skipped when computing the watermark; rows filtered on event time at or above the watermark), https://github.com/risingwavelabs/risingwave/blob/v3.1.0/src/stream/src/executor/watermark_filter.rs (checked Oct 3, 2026)
- •RisingWave docs, Emit on window close (final result when the watermark passes the window end), https://docs.risingwave.com/processing/emit-on-window-close (checked Oct 3, 2026)
- •RisingWave docs, AWS Glue catalog (Glue for Iceberg sinks, sources and internal tables), https://docs.risingwave.com/iceberg/catalogs/glue (checked Oct 3, 2026)
- •RisingWave docs, Release notes (v3.0.0 Jun 11, 2026; v3.0.4 Sep 16, 2026; v3.1.0 listed as upcoming; openai_embedding, vector type and vector indexes), https://docs.risingwave.com/changelog/release-notes (checked Oct 3, 2026)
- •RisingWave GitHub releases (v3.1.0 published Sep 21, 2026), https://github.com/risingwavelabs/risingwave/releases (checked Oct 3, 2026)
- •RisingWave MCP server README (100+ tools including DDL and DML; RISINGWAVE_CONNECTION_STR), https://github.com/risingwavelabs/risingwave-mcp (checked Oct 3, 2026)
- •RisingWave docs, pg_catalog (Postgres-compatible system catalogs), https://docs.risingwave.com/sql/system-catalogs/pg-catalog (checked Oct 3, 2026)
- •Snowflake docs, CREATE CATALOG INTEGRATION (AWS Glue) (Iceberg tables that use Glue as the catalog), https://docs.snowflake.com/en/sql-reference/sql/create-catalog-integration-glue (checked Oct 3, 2026)
- •Data Workers open-source repository (tool registrations in dw-connectors, dw-schema, dw-context-catalog, dw-quality, dw-incidents), https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)
- •Data Workers client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)