What is a Sink in RisingWave?

A sink in RisingWave delivers processed streaming data to external systems like Kafka, databases, data lakes, and search engines. Learn how sinks work and which downstream systems are supported.

What is a sink?

A sink in RisingWave is a connection that continuously delivers processed data to an external downstream system. Sinks are the output stage of a streaming pipeline — they take results from materialized views, tables, or queries and write them to systems like Kafka, PostgreSQL, Iceberg, Snowflake, or Elasticsearch.

When you create a sink with CREATE SINK, RisingWave establishes a persistent connection to the target system and continuously streams updates as the upstream data changes. Sinks do not store data inside RisingWave — they push data out.

How sinks work

-- Create a sink that sends aggregated results to Kafka
CREATE SINK order_metrics_sink FROM order_metrics
WITH (
  connector = 'kafka',
  topic = 'order-metrics',
  properties.bootstrap.server = 'broker:9092',
  type = 'upsert',
  primary_key = 'product_id'
) FORMAT UPSERT ENCODE JSON;

A sink can consume from:

• A materialized view — most common; delivers continuously updated results.
• A table — delivers the current state and all subsequent changes.
• An inline query — defines the transformation directly in the sink statement.

-- Sink from an inline query
CREATE SINK high_value_orders_sink AS
SELECT order_id, customer_id, amount
FROM orders WHERE amount > 1000
WITH (
  connector = 'jdbc',
  jdbc.url = 'jdbc:postgresql://downstream:5432/analytics',
  table.name = 'high_value_orders',
  type = 'upsert',
  primary_key = 'order_id'
);

Sink types: append-only vs. upsert

RisingWave supports two sink emission modes:

Mode	Behavior	Primary key required	Use case
Append-only	Inserts only; no updates or deletes	No	Log-style destinations, event streams
Upsert	Inserts, updates, and deletes by primary key	Yes	Database tables, search indexes, key-value stores

The emission mode depends on the downstream system and the nature of your data. For example, sinking to an Iceberg table typically uses upsert mode, while sinking to a Kafka topic for log analytics might use append-only mode.

Supported sink connectors

RisingWave supports a broad set of sink connectors:

Message brokers: Apache Kafka, Apache Pulsar, Amazon Kinesis, NATS, Google Pub/Sub, MQTT

Databases: PostgreSQL, MySQL, ClickHouse, StarRocks, Doris, TiDB, BigQuery, DynamoDB, CockroachDB

Data lakes: Apache Iceberg, Delta Lake

Search and analytics: Elasticsearch, OpenSearch

Object storage: Amazon S3, Google Cloud Storage, Azure Blob Storage

Data warehouses: Snowflake

Key-value stores: Redis, Cassandra

For the full list, see Supported sink connectors.

Delivery semantics

RisingWave uses a barrier-based checkpoint mechanism to provide exactly-once state updates for internal stream processing. End-to-end delivery guarantees for sinks are connector-dependent — most sinks provide at-least-once delivery, while specific connectors (such as Iceberg with is_exactly_once=true and sink decoupling enabled) support exactly-once delivery. For the precise semantics by connector, see Delivery semantics.

Related topics

• CREATE SINK — SQL reference
• Delivery overview — Full connector list
• Source, Table, MV, and Sink — Core object comparison