Skip to content

Introduction ​

Mink is a read-only Iceberg catalog over Kafka. Iceberg engines query topics as tables, and the records stay in Kafka. A Mink node runs next to an existing Kafka cluster, with Postgres for its state and an S3-compatible bucket for the Iceberg metadata.

enginesDuckDB, PyIcebergmink nodeREST catalogtables, snapshotsindexers and writersoffsets into snapshotsS3 endpointbuilt on readPostgrestables, files, leasesbucketmetadataKafkathe recordsloadreadstatefilescommitindexbuild

How it works ​

StepWhat happens
Add a topicmink table add orders makes the topic a table. Indexing starts at the last stable offset, and backfill reads the history.
IndexOne indexer per partition reads each committed record once. Offset ranges become data files with exact statistics. Only metadata is stored.
CommitA writer commits a snapshot every 10 seconds by default, as Iceberg metadata in the bucket.
LoadAn engine loads the table from the REST catalog, up to the last stable offset. See Snapshots.
ReadThe engine reads data files from the S3 endpoint. Mink builds each file's Parquet from Kafka, the same bytes every time, and caches it.

Features ​

  • Standard Iceberg. Engines connect with REST catalog and S3 settings. No plugin and no client library.
  • Schema Registry. Avro, Protobuf and JSON Schema payloads become typed columns. New schema versions evolve the table. A record that does not decode keeps its raw bytes.
  • No data copies. Data files are built from Kafka on read. Kafka keeps the only copy of the records.
  • Real time. A table load covers every record committed up to that moment.
  • Committed records only. Aborted transactions and control records never show up.
  • Pruning. Files are partitioned by time and carry min/max bounds per column. Engines skip the files a filter rules out.
  • Cache. Built files are cached in memory, and on disk when configured.
  • Stateless nodes. Any node can stop. Its partitions move to the others through leases in Postgres.
  • Admin console. Tables, partitions, files, snapshots, schemas, records and nodes, plus a SQL page that runs DuckDB in the browser.

Use cases ​

  • SQL over live topics, without a sink pipeline or a second copy of the data.
  • Joining Kafka data with lakehouse tables in one engine.
  • Finding records by key, offset, time or field value.