risingwavelabs/risingwave · error · SinkError::DynamoDb

variant is not supported yet

Error message

variant is not supported yet

What it means

The DynamoDB sink serializes RisingWave rows into DynamoDB AttributeValues. The Variant data type (arbitrary semi-structured JSON) has no direct DynamoDB mapping implemented in this connector, so map_data rejects it explicitly.

Source

Thrown at src/connector/src/sink/dynamodb.rs:364

    let attr = match data_type {
        DataType::Int16
        | DataType::Int32
        | DataType::Int64
        | DataType::Int256
        | DataType::Float32
        | DataType::Float64
        | DataType::Decimal
        | DataType::Serial => AttributeValue::N(scalar_ref.to_text_with_type(data_type)),
        // TODO: jsonb as dynamic type (https://github.com/risingwavelabs/risingwave/issues/11699)
        DataType::Varchar
        | DataType::Interval
        | DataType::Date
        | DataType::Time
        | DataType::Timestamp
        | DataType::Timestamptz
        | DataType::Jsonb => AttributeValue::S(scalar_ref.to_text_with_type(data_type)),
        DataType::Variant => {
            return Err(SinkError::DynamoDb(anyhow!("variant is not supported yet")));
        }
        DataType::Boolean => AttributeValue::Bool(scalar_ref.into_bool()),
        DataType::Bytea => AttributeValue::B(Blob::new(scalar_ref.into_bytea())),
        DataType::List(lt) => {
            let list_attr = scalar_ref
                .into_list()
                .iter()
                .map(|x| map_data(x, lt.elem()))
                .collect::<Result<Vec<_>>>()?;
            AttributeValue::L(list_attr)
        }
        DataType::Struct(st) => {
            let mut map = HashMap::with_capacity(st.len());
            for (sub_datum_ref, (name, data_type)) in scalar_ref
                .into_struct()
                .iter_fields_ref()
                .zip_eq_debug(st.iter())
            {

View on GitHub (pinned to 6469eb736d)

Solutions

  1. Change the source column to JSONB, which the sink serializes as a DynamoDB string via to_text_with_type.
  2. Cast the VARIANT column to JSONB (or VARCHAR) in the materialized view feeding the sink.
  3. Exclude the VARIANT column from the sink's plan (sink only the needed scalar columns).
  4. Await/track connector support for Variant in the DynamoDB sink.

Example fix

// before
CREATE MATERIALIZED VIEW mv AS SELECT payload::VARIANT AS data FROM src;
CREATE SINK s FROM mv WITH (connector='dynamodb', table='events');
// after
CREATE MATERIALIZED VIEW mv AS SELECT payload::JSONB AS data FROM src;
CREATE SINK s FROM mv WITH (connector='dynamodb', table='events');
Defensive patterns

Strategy: validation

Validate before calling

-- ensure no VARIANT columns before sinking to DynamoDB
SELECT count(*) FROM rw_catalog.rw_columns WHERE relation_id = <mv_id> AND data_type = 'VARIANT';

Prevention

When it happens

Trigger: A sink's materialized view/table contains a column of type VARIANT and a row is formatted for writing to DynamoDB.

Common situations: Ingesting semi-structured JSON payloads into a VARIANT column and then sinking that table to DynamoDB; schema changes that add a VARIANT column to an existing DynamoDB-sunk relation.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


AI-assisted analysis of risingwavelabs/risingwave@6469eb736d (2026-09-11). Data as JSON: /api/errors/9e41721ee2f324d7. Report an issue: GitHub.