The catalog

The catalog lists every table your organisation holds, organised as catalogs, namespaces and tables. A catalog belongs to a domain and an environment: sales in dev is the catalog sales_dev. Tables are stored in open formats — mostly Apache Iceberg — in your own account.

• Finding a table
• A table's page
• Lineage
• Permissions
• Quality rules
• Maintenance

Finding a table

Open Catalog. Search by name across catalogs, databases, tables and columns, or filter by type. Each result shows its path, rows, size, when it last changed and who owns it.

The catalog switcher in the top bar sets the catalog you are working in. New kernels start on it, sandbox mode shadows it, and SQL notebooks resolve unqualified names in it.

A table's page

Tab	Shows
Overview	Rows, size, data files and when it last changed, and how it is partitioned.
Schema	Its columns and their types.
Snapshots	Each committed version of the table — what time travel can reach.
Properties	The table's settings.
Lineage	What wrote this table and what reads it. See below.
Profile	What profiling measured about each column: completeness, distinct values, lengths, ranges and the shape of its values — never raw values. See Governance.
Maintenance	Whether a schedule covers this table, its recent runs, and Run now.
Permissions	Who can read and write it. See below.
Rules	Its quality rules and their latest results.

Lineage

Lineage is recorded from the engines as work runs — nothing is guessed by reading code afterwards. A pipeline step that lists its input and output tables, or a pipeline committed from a notebook, appears as the link between the tables it read and wrote. A table with no lineage yet gets some the first time a pipeline writes it with lineage capture on.

Permissions

The Permissions tab on every catalog, namespace and table lists the roles granted on it, what each may do, and where the grant came from. Grants on a catalog or namespace reach the tables inside; those are listed on the page where they are made.

• A grant usually applies to both notebooks and SQL. Where only one side grants it, the row says so.
• Column masks hide or transform a column's values for the people named. Row filters limit which rows they see.
• Masks and row filters are enforced when a table is read through SQL warehouses and dashboards, and in notebooks on kernels running runtime 0.4.

Access follows membership: adding someone to a domain, removing them or changing their role updates what they can read within moments. Administrators manage extra grants in the Roles & permissions console. No grant gives a person row writes in a production catalog — those go through pipelines.

Quality rules

A quality rule is a check on a column, evaluated each time the table is profiled. Rules compare what profiling already measured, so they run nothing of their own.

Measure	Compared as
Completeness	A fraction of rows present, between 0 and 1 — 0.95 means 95%.
Uniqueness	A fraction of rows distinct — 1 means every value is distinct.
Row count	A number of rows.
Minimum, Maximum	The smallest or largest value measured.

Each rule is a column, a measure, a comparison (≥, >, ≤, <, =, ≠) and a threshold. The Rules tab shows each rule's last result — passed, failed or not checked yet — and the value measured. A failed check notifies the groups that follow data quality anomalies (see Notifications).

Maintenance

Tables that are written often collect many small files and old versions, and queries over them slow down. Maintenance compacts and tidies them.

Operation	Does
Compact data files	Rewrites small or fragmented data files into fewer, larger ones.
Rewrite manifests	Compacts the files that index a table's data.
Rewrite position deletes	Compacts the delete files row-level updates leave behind.
Expire snapshots (deletes data)	Permanently removes versions older than the number of days you keep — 7 by default. Time travel cannot reach them afterwards.
Remove orphan files (deletes data)	Permanently deletes files in the table's location that no version refers to, older than a number of days you choose — at least 3.

To maintain one table now, open it and use Run now on its Maintenance tab. To maintain on a schedule, add a policy on the Table maintenance page: a scope (every table in a catalog, every table in a namespace — including tables created later — or one table), the operations, and daily or weekly. A policy runs as a named person, so it touches only what their grants reach. Where policies overlap, the narrowest one applies.

A job wakes every hour and runs the policies that are due, a few tables at a time, so maintenance never crowds out pipelines. Versions a sandbox is holding are never expired while the sandbox exists.

Running maintenance needs a role that may run it; operations that delete data, and adding a policy, are for owners and admins.