Redpanda can write a topic's data straight into Apache Iceberg tables, queryable from Athena, Spark, Redshift, or anything else that speaks a REST catalog — no separate ETL pipeline. Point that at AWS Glue Data Catalog and the setup looks like five config properties. It's five config properties plus one architectural fact about Glue that isn't obvious until your second cluster starts silently overwriting the first one's tables. These are the documented steps and failure modes from Waymark's live route corpus, checked line-by-line against Redpanda's official self-managed documentation.
Sourced from 1 live route record · regenerated 2026-07-10AWS Glue Data Catalog is one catalog per AWS account — there's no per-cluster or per-project catalog the way there is with, say, a self-hosted REST catalog server. Redpanda's docs are explicit about the consequence: "When multiple clusters write to the same catalog, each cluster must use a distinct namespace to avoid table name collisions. This is especially critical for REST catalog providers that offer a single global catalog per account (such as AWS Glue), where there is no other isolation mechanism." By default every cluster writes into a namespace called redpanda — so the second cluster you point at the same Glue catalog, without setting iceberg_default_catalog_namespace, starts writing into namespace-and-table names the first cluster already owns. This property can't be changed after Iceberg is enabled on the cluster, so it has to be right on the first try.
rpk cluster license info), Tiered Storage enabled, and Redpanda 25.1.7 or later for the Glue integration specificallyrpk cluster config set iceberg_enabled true — and set iceberg_default_catalog_namespace in the same operation if this cluster shares a Glue catalog with anotherrpk topic alter-config <topic> --set redpanda.iceberg.mode=<mode>, choosing key_value, value_schema_id_prefix, or value_schema_latestrpk registry schema create <subject> --schema <path> --type <format>, and make sure producers write Schema-Registry wire-format messagesiceberg_catalog_type: rest, iceberg_rest_catalog_endpoint: https://glue.<region>.amazonaws.com/iceberg, iceberg_rest_catalog_authentication_mode: aws_sigv4, and an S3 base location in the same bucket as your cloud_storage_bucketdatabase/*, and table/*/* resources with glue:* actions, then query the table from Athena, Spark, or another catalog-integrated engine# Enable Iceberg + set a namespace unique to this cluster (rpk cluster config edit)
iceberg_enabled: true
iceberg_default_catalog_namespace: ["<custom-namespace>"] # default is "redpanda" — collides across clusters
iceberg_delete: false # Glue tables must be deleted manually; see below
iceberg_catalog_type: rest
iceberg_rest_catalog_endpoint: https://glue.<glue-region>.amazonaws.com/iceberg
iceberg_rest_catalog_authentication_mode: aws_sigv4
# Must be the same bucket as cloud_storage_bucket — Redpanda doesn't
# support a separate bucket for Iceberg data/metadata
iceberg_rest_catalog_base_location: s3://<bucket-name>/<warehouse-path>
# Per topic:
# rpk topic alter-config my-topic --set redpanda.iceberg.mode=value_schema_id_prefixYou'll see 25.2 cited as the cutoff for Iceberg-related Redpanda features in a few places online, and it's true for one specific thing — JSON schemas in Schema Registry are only supported starting with Redpanda 25.2. But Redpanda's own current AWS Glue integration page lists the prerequisite for the Glue catalog integration itself as Redpanda version 25.1.7 or later, not 25.2. It's an easy mix-up if you're skimming release notes rather than the prerequisites section of the actual how-to page — worth confirming against rpk version and the current docs rather than trusting the first version number you see cited.
Two things surfaced while checking Redpanda's official AWS Glue integration page that are worth flagging alongside the namespace-collision issue. First, as of this writing the AWS Glue REST catalog integration page itself carries Redpanda's own beta status label, with the standard disclaimer: "This is a beta feature. Beta features are available for testing and feedback. They are not supported by Redpanda and should not be used in production environments." That's a separate, narrower claim than the BYOC-vs-Enterprise GA split below — it applies to the Glue REST catalog integration specifically, on top of whatever edition you're running. Second, Glue-backed Iceberg tables aren't deleted automatically when you delete the Redpanda topic: you have to set iceberg_delete: false (cluster-wide, or per-topic via redpanda.iceberg.delete) before deleting the topic, then manually delete the table in Glue and the data/metadata files in S3 — otherwise re-creating a topic with the same name can collide with orphaned table state. Redpanda's docs also flag that Redpanda versions 25.2.1 and earlier can leave an empty partition spec that breaks queries from some engines, including Amazon Redshift; the fix is either custom partitioning or upgrading to 25.2.2+.
Redpanda's April 2025 announcement of Iceberg Topics 25.1 draws a line most people miss: Iceberg Topics reached general availability for Enterprise Edition customers, but remain public beta for BYOC deployments. If you're running BYOC, you're on a beta feature regardless of what the cluster-wide GA announcement implied — check which deployment model you're actually on before treating this as production-ready, and combine that with the Glue-integration-specific beta label above if you're using the Glue catalog path.
Agents wired to Waymark's MCP server pull this route (namespace collisions, the manual-deletion requirement, the real version prerequisite) at plan time instead of reconstructing the Glue catalog config from scattered blog posts and shipping a second cluster that quietly clobbers the first one's Iceberg tables. Reads are free and keyless.
# Any MCP client — one call, no key:
waymark_query({ "task": "redpanda iceberg topics aws glue catalog" })
# Or plain HTTP:
curl -s "https://mcp.waymark.network/search?q=redpanda%20iceberg%20glue%20catalog"