Skip to content
FR Version françaiseBook a demo

The data catalog

The Data Platform catalog tells you which data exists, who owns it and who may read it. It is built on the Apache Iceberg tables in your object storage: a table created by a job, by Trino or by another tool appears in the catalog, and the catalog copies no data. Buckets, SQL and Iceberg are described in Data and SQL.

Every job receives an Iceberg catalog named graal, already configured, whose namespace is your organization’s. A table is designated by its name, with no address, token or storage key in the code:

Engine Read a table
Spark, local or distributed spark.table("sales")
Python, notebook jobs, dbt graal.read_table("sales")
Dask graal.read_table_dask("sales") (read by the workers)
Flink graal catalog declared by a SQL file provided to the job
Ray graal.load_table("sales").scan().to_ray()

The run token, which exists only for the duration of the run, opens the catalog; no storage key is placed in the run’s pods. Trino reads the same tables: what Spark writes, Trino reads back, and the other way round.

The catalog synchronizes with the real Iceberg tables:

  • at the end of every run, on demand (the “Resynchronize” button in the console or synchronize_catalog for an agent) and on a periodic schedule;
  • a table created outside a job, for example by a Trino query, joins the catalog;
  • a table removed from the engine is marked dropped and keeps its description, owner and tags if it comes back;
  • columns, their types (nested ones included) and the name to use in Trino are kept up to date; the description, owner, tags, glossary terms and certification entered by your teams are never overwritten.

A table page has eight tabs:

Tab What it shows
Overview description, owner, stewards, tags, certification, quality
Schema columns, types, classification and tags of each column
Preview a few real rows, read by Trino under your rights
Statistics rows, files, size, partitioning; per column, nulls, minimum, maximum and distinct values
History the table’s versions (snapshots): date, operation, volume changed
Lineage where the table comes from, down to the column
Usage who queries the table
Definition location, format, Iceberg properties

From the page, the console offers to open the table in the SQL editor or in a notebook, and to copy a code snippet for Trino, Spark, Python, Dask, DuckDB or JDBC.

  • Owner and stewards: a person or a group from your directory.
  • Tags on tables and columns.
  • Certification: a table is certified or marked deprecated; the platform records who did it and when.
  • Column classification: public, internal, confidential, sensitive or personal data.
  • Glossary: business terms, attached to tables and columns, with the linked assets one click away.
  • Faceted search: by layer, format, tag, owner, certification, quality, classification or column name. Results respect your rights: a table in a layer you cannot read appears neither in the list nor in the counts.

Read and edit rights are set per layer, with the platform’s roles (see roles and permissions). Every change is recorded in the audit log.

Agents get ten more catalog tools, on top of list_catalog, get_table, search_catalog and set_table_description: preview, statistics, version history, the glossary, and governance writes (owner, tags, classification, certification, synchronization). An agent’s path runs from search to query: search_catalog, get_table, preview_table, then query_sql with the table’s qualified name. See AI agents (MCP).

The Iceberg catalog is a standard REST catalog, Apache Polaris, backed by the platform’s PostgreSQL database. For each request it provides storage credentials limited to the table concerned, and it applies the catalog’s rights all the way into Trino: no storage key shared between organizations, and a refusal decided by the engine itself. The rights you set in the console are projected into the catalog. An engine that speaks the Iceberg REST protocol connects to it with the same table names.