What causes "Don't support Map" in risingwavelabs/risingwave?

Remove or flatten the MAP column before sinking (extract needed keys into scalar columns).

risingwavelabs/risingwave · error · SinkError::BigQuery

Don't support Map

Error message

Don't support Map

What it means

The BigQuery sink maps each RisingWave column type to a protobuf field when building the row-encoding schema. MAP columns have no representation in this flat protobuf message, so build_protobuf_field rejects them with this error at sink creation time.

Solutions

Remove or flatten the MAP column before sinking (extract needed keys into scalar columns).
Cast the MAP to VARCHAR: `CAST(map_col AS varchar)` in the sink query to store it as a JSON string.
Create an upstream MV that reshapes the data (unnest/row expand) and sink that instead.
Request MAP support in the BigQuery connector if flat scalars are not viable.

Example fix

// before
CREATE SINK s FROM mv;  -- mv.attrs is map<varchar,varchar>
// after
CREATE SINK s AS SELECT id, CAST(attrs AS varchar) AS attrs FROM mv;

Defensive patterns

Strategy: validation

Validate before calling

-- Reject Map columns before CREATE SINK:
-- any MAP<..> column must be flattened or CAST to varchar before sinking to BigQuery.

Try / catch

match sink_creation {
    Err(SinkError::BigQuery(e)) if e.to_string().contains("Don't support Map") => {
        // flatten the map or CAST it to varchar in the sink SELECT and retry
    }
    other => other?,
}

Prevention

Flatten MAP columns into scalar columns in an upstream MV before sinking.
Store maps as JSON strings (CAST(map AS varchar)) when structure is not needed in BigQuery.
Check column types in the MV schema before CREATE SINK.
Avoid connecting complex nested sources directly to the BigQuery sink without reshaping.

When it happens

Trigger: BigQuerySinkWriter::new -> build_protobuf_schema encounters a column of DataType::Map (e.g. MAP<VARCHAR, VARCHAR>) in the sink schema.

Common situations: Sinking a table with map-typed columns (common with nested/complex sources like Debezium); upstream type change introducing a map column.

Related errors

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

Appendix: source

Thrown at src/connector/src/sink/big_query.rs:1013

            return Ok((field, Some(sub_proto)));
        }
        DataType::List(l) => {
            let (mut field, proto) = build_protobuf_field(l.elem(), index, name)?;
            field.label = Some(field_descriptor_proto::Label::Repeated.into());
            return Ok((field, proto));
        }
        DataType::Bytea => field.r#type = Some(field_descriptor_proto::Type::Bytes.into()),
        DataType::Jsonb => field.r#type = Some(field_descriptor_proto::Type::String.into()),
        DataType::Variant => {
            return Err(SinkError::BigQuery(anyhow::anyhow!("Don't support Variant")));
        }
        DataType::Serial => field.r#type = Some(field_descriptor_proto::Type::Int64.into()),
        DataType::Float32 | DataType::Int256 => {
            return Err(SinkError::BigQuery(anyhow::anyhow!(
                "Don't support Float32 and Int256"
            )));
        }
        DataType::Map(_) => return Err(SinkError::BigQuery(anyhow::anyhow!("Don't support Map"))),
        DataType::Vector(_) => {
            return Err(SinkError::BigQuery(anyhow::anyhow!("Don't support Vector")));
        }
    }
    Ok((field, None))
}

#[cfg(test)]
mod test {

    use std::assert_matches;
    use std::collections::HashMap;

    use risingwave_common::catalog::{Field, Schema};
    use risingwave_common::types::{DataType, StructType};

    use crate::connector_common::AwsAuthProps;
    use crate::sink::big_query::{

View on GitHub (pinned to 6469eb736d)