Catalogs, domains, tables, and buckets

Griot names data in a visible hierarchy: catalog → domain → resource. A workspace receives a default catalog. A domain groups data by ownership and policy. A resource is a table or a bucket.

Tables

A table describes structured, queryable data. Its detail page is where you inspect columns, lifecycle state, contract, and lineage. Uploading a structured file can start a table workflow, but queryability follows validation and governance state, not a filename extension alone.

Buckets

A bucket keeps original files and relative paths. You can place many files in one bucket, including content that has no row-and-column shape. The bucket view lists those files; each file has its own detail page. Creating a table from a file is an explicit action and should record the source file as lineage.

Names and identifiers

Use catalog.domain.table or catalog.domain.bucket to describe a resource to a person. APIs also expose stable IDs and may accept older addresses during migration. Never drop the catalog or domain when two names could refer to different things. The server must reject ambiguous legacy names rather than guessing.

The catalog work is being integrated across the UI, API, and storage authority. Check the API reference for the operations actually available in the current revision.

For the difference between a catalog name, Iceberg storage, and permission to read, see Catalog identity, storage, and access.