.svg)
Key Takeaways
- AIStor's built-in Iceberg catalog eliminates the need for a separate catalog service, reducing both infrastructure and operational overhead.
mc table migratemoves catalog metadata only, not data files, so your query engines keep working through the transition.- Migration is idempotent by default. Use
--dry-runto preview every table that would be registered before anything changes.
If you are already running Apache Iceberg tables in production, you have almost certainly set up a catalog to manage them. That catalog, whether it is Project Nessie, Apache Polaris, Hive Metastore, or AWS Glue tracks table locations, schema evolution, snapshot history, and partition specs. It is essential, but when it’s external to your storage it is also additional infrastructure to run, monitor, and maintain.
MinIO AIStor is the first on-prem, natively S3-compatible data store with an Iceberg REST catalog built directly into it. When the catalog lives in the same system as the data, you eliminate the network hop between catalog lookup and data access and reduce the number of services to operate.
The question for most teams has been: how do you actually get there without re-registering hundreds of tables by hand? AIStor answers that with mc table migrate, a feature that automates the migration process end to end.
What the Command Does
mc table migrate reads catalog metadata from your existing catalog and registers those tables in AIStor. Critically, it does not move your Parquet files. If your table data is already in AIStor buckets, which is the common case because MinIO is frequently used as the object store even when a separate catalog manages the table definitions, the migration touches only metadata. Your existing query engines keep working through the transition. Trino, Spark, Flink, and others can continue reading the same underlying files; you are just pointing them at a new catalog endpoint when you are ready to cut over.
If your data currently lives in a different object store entirely, for example Amazon S3, you would first mirror the data into AIStor using mc mirror or batch replication, and then run mc table migrate to register the table metadata against the new data paths. The two steps are intentionally separate so you can validate each independently.
Supported Source Catalogs
The command currently supports five source types:
nessie— Project Nessie, via its Iceberg REST interfacerest— any generic Iceberg REST catalog, including Apache Polarishive— Hive Metastore, via the Thrift protocolglue— AWS Glue Data Catalog, with region and credential propertiessql— SQL-backed catalogs
Nessie has the most test coverage and the most documented examples, but the rest source type gives you a broad net for any catalog that speaks the Iceberg REST spec.
The Migration Workflow
Start with a Dry Run
Before migrating anything, use --dry-run to see exactly what would be registered. Combined with --output-dir, this writes a file listing every table and namespace that would be touched:
Review the output before committing. This is especially useful for large warehouses where you want to validate namespace and table discovery before anything changes in AIStor.
Migrate All Namespaces
Once you are satisfied with the preview, drop --dry-run to run the full migration:
This registers every table and view discovered in the source catalog. Iceberg views are included by default; use --exclude-views if you only want tables.
Migrate Selectively
For large catalogs you may want to migrate incrementally, one namespace or team at a time. The --namespaces flag accepts a comma-separated list:
--ignore-existing makes the run safe to re-execute. Tables already registered in AIStor are skipped rather than causing errors, which means you can run the command multiple times as you migrate namespace by namespace.
You can also target specific tables by exact identifier or by regex pattern:
Migrating from Polaris (Generic REST)
For any catalog that implements the Iceberg REST spec, use --source-type rest. Credentials are passed via environment variables rather than on the command line, which avoids exposing secrets in the process list:
Migrating from Hive Metastore
Hive uses the Thrift protocol. Note that Iceberg views are not supported in Hive, so the migration registers tables only:
Migrating from AWS Glue
For Glue, pass region and credential properties explicitly. Using shell variable expansion keeps credentials out of the command string as it appears in process listings:
One-Way Move: Register and Drop
When you are ready to fully decommission the source catalog entry for a set of tables, --delete-source registers each table in AIStor and then drops it from the source catalog. The command prompts for confirmation by default:
For CI pipelines or scripted cutover workflows, add --force to skip the confirmation prompt.
Handling Partial Failures
Migrations over large catalogs will occasionally hit transient errors — network timeouts, permission issues on specific tables, or edge cases in schema metadata. When --output-dir is set, the command writes a failed_identifiers.txt for any tables that could not be registered. You can feed that file directly into a retry run:
This makes large migrations operationally tractable. You do not need to re-run the full discovery pass; you retry exactly what failed.
What This Means for Your Stack
The value here goes beyond convenience. Running a separate catalog service means another component in your dependency graph: another service to deploy, another one to keep highly available, another set of credentials to manage, and another failure point that can block query engines from resolving table locations.
Collapsing the catalog into AIStor means your Iceberg tables have a single home. The object store that holds your Parquet files also holds the metadata that describes them. Query engines make one connection to AIStor and get both catalog operations and data access from the same infrastructure. For teams running AIStor on-premises or at the edge, where every additional service adds operational weight, that consolidation has real value.
For teams coming from a managed cloud catalog — AWS Glue being the most common — migrating to AIStor also means removing a dependency on a cloud-provider-specific service. Your table metadata moves with your data, and the catalog endpoint becomes part of your own infrastructure rather than a managed service you pay access fees to reach.
Availability
mc table migrate is available as of release RELEASE.2026-04-13T21-15-24Z. Download the latest mc binary from dl.min.io.
Documentation at docs.min.io is being updated to cover the new command. In the meantime, mc table migrate --help provides the full flag reference with annotated examples for all supported source types.
If you want to test the end-to-end workflow before migrating production tables, a sample setup with a local Nessie instance and test data is available in the AIStor test data repository.
.svg)
