Skip to main content
How-to guideApplies to: All deployments
Use these examples when importing a pipeline as YAML. For console setup, see Schema Registry. Each example includes the source, destination and pipeline. Replace the connection settings for your environment before importing. Your deployment needs access to Kafka, Glue, the Iceberg catalog and its storage. For AWS roles and permissions, see Cross Account Access.

Write to one Iceberg table

This example reads Debezium Avro events from MSK using AWS Glue Schema Registry and writes them to one Iceberg table. Replace every <placeholder>. The source role needs both MSK and Glue read permissions. Configure the REST catalog’s warehouse for your S3 bucket and prefix, and create the destination namespace before starting the pipeline. If the catalog requires authentication, add its authentication settings.
The S3 writer role is separate from the source role. Use the bucket’s region, and grant the writer role access to the warehouse bucket and prefix. If it requires an external ID, add client.assume-role.external-id under storageOptions. If your deployment or catalog already supplies storage credentials, omit client.assume-role.arn. See S3 access. Start the source before publishing new events: this example reads only records arriving after it starts. Wait for a successful checkpoint, then query the destination table. Each event is stored as a new row, including updates and deletes; the pipeline does not apply changes to existing rows.

Write to several Iceberg tables

Use this example when one topic contains events from several source tables. Each event must have a non-empty string in source.table, which names its destination table. Missing destination tables are created automatically. This sample uses an unauthenticated development broker and the deployment’s AWS credentials for Glue and S3. Replace the broker, authentication, registry, catalog, warehouse, namespace and storage settings for your environment.
This pipeline stores complete events as new rows. Use separate pipelines or namespaces if different databases use the same table names and their data must stay separate. Review multi-table routing limits, including supported schema changes, before starting. Start the pipeline, wait for a successful checkpoint, and query each destination table to verify that the events arrived.
Last modified on November 6, 2026