Managing shared tables

Table Shares support grouping multiple tables under a single share. Each share has one or more schema under which you can associate multiple tables. When you access the share from a remote client, you can perform operations against any table under a given schema.

When you create a new table share, you define the initial schema and table associated to that share. You can then add new tables to that share under the same or a different schema.

Use the mc table share update with the --add modifier to add a table to an existing share. For example, the following command adds a new table located at analytics/sales to the analytics-share under the HR schema:

mc table share update myaistor/analytics-share \
  --add "HR:sales:delta:analytics:sales/"

When you list the share, the output includes all tables grouped under the HR schema.

Table Sharing serves both Delta and Iceberg tables stored in MinIO AIStor buckets over the Delta Sharing protocol. For an Iceberg table, MinIO AIStor reads the table’s native Iceberg metadata and translates it into Delta Sharing responses at request time. MinIO AIStor does not convert the table or write any Delta metadata, so the table remains a pure Iceberg table. The uniform table type used when adding an Iceberg table to a share is unrelated to Databricks UniForm, which generates Iceberg metadata alongside a Delta table. This enables workload patterns such as:

• Sharing Delta Lake data alongside Iceberg tables.
• Providing a unified interface for consumers across data formats.
• Serving Iceberg tables to Delta Sharing clients without converting them or requiring end-user knowledge or interaction.

This functionality assumes the AIStor Tables APIs and access methods as the primary source of Iceberg data management.

To colocate Iceberg and Delta table data within a single share, you must at minimum partition data between the two formats. For example, consider a bucket analytics-data intended for storing both Iceberg and Delta data stores. Use the prefixes iceberg and delta to isolate data between the two formats when creating and accessing the stored data:

analytics/                              # S3 bucket
│
├── delta/                              # Delta tables (user-defined paths)
│   ├── sales/
│   │   ├── _delta_log/                 # Delta transaction log
│   │   │   ├── 00000000000000000000.json
│   │   │   └── 00000000000000000001.json
│   │   ├── year=2024/
│   │   │   └── part-00000-*.parquet
│   │   └── year=2025/
│   │       └── part-00000-*.parquet
│   │
│   └── inventory/
│       ├── _delta_log/
│       └── part-00000-*.parquet
│
└── 01913e6a-c8b8-7448-8121-72f53e6a1427/   # Iceberg table (UUID path)
    ├── metadata/
    │   ├── 00000-40585df9-metadata.json
    │   └── snap-1234567890-avro.avro
    └── data/
        └── part-00000-*.parquet

AIStor Tables use UUID-based paths during table creation, while Delta Tables use user-controlled prefixes. For additional control or isolation, you can further nest AIStor Tables using iceberg or a preferred prefix.

Use the mc table share update with the --add modifier to add an AIStor Table to an existing share. For example, the following command adds a new Iceberg table as marketing with warehouse, namespace, and table data as marketing:marketing:marketing to the analytics-share share under the HR schema:

mc table share update myaistor/analytics-share \
  --add "HR:marketing:uniform:analytics:marketing:marketing"

When you list the share, the output includes all tables grouped under the HR schema. Client applications querying the data interact directly with the table as marketing rather than through the full Iceberg path.