Part of Iceberg v1. Lands early so every other issue has a catalog to run against.
What
- An Iceberg REST catalog container in
dev/kafka-single.yml backed by the MinIO that is already there. Apache Polaris or the Iceberg project's REST fixture image; pick the one that supports vended credentials, since the client issue needs to exercise that path.
- A release test in
tests/release: publish N messages to Kafka, run a pipeline with the Iceberg sink through the REST catalog, then read the table back with DuckDB's iceberg extension and assert the row count and a checksum.
- The SQLite-catalog path stays tested as dev mode, and its docs say dev mode.
Why DuckDB for read-back here
The compatibility matrix reads back from each vendor's engine, and that needs accounts and secrets. The release test needs to run on every PR with none of that, so it reads back with the engine sqlflow already embeds.
Part of Iceberg v1. Lands early so every other issue has a catalog to run against.
What
dev/kafka-single.ymlbacked by the MinIO that is already there. Apache Polaris or the Iceberg project's REST fixture image; pick the one that supports vended credentials, since the client issue needs to exercise that path.tests/release: publish N messages to Kafka, run a pipeline with the Iceberg sink through the REST catalog, then read the table back with DuckDB's iceberg extension and assert the row count and a checksum.Why DuckDB for read-back here
The compatibility matrix reads back from each vendor's engine, and that needs accounts and secrets. The release test needs to run on every PR with none of that, so it reads back with the engine sqlflow already embeds.