Trino¶
Part of the lakehouse (overview and interaction diagram).
The Trino template (Processing category) deploys a Trino coordinator and workers with a lakehouse catalog pre-wired to the chosen Apache Iceberg instance.
Trino is not a database: it is a storage-less SQL engine. Three roles share the work — the Apache Iceberg catalog knows which tables exist and which files make them up, the S3 bucket holds the data as Parquet, and Trino runs the SQL in memory, spread across its workers. Hence the deployment order: the catalog first, Trino next, in the same namespace and on the same bucket.
Deployment options¶
| Field | Role |
|---|---|
| Apache Iceberg (Polaris) catalog (required) | Apache Iceberg instance of the same namespace. Fixed at creation. |
| Iceberg catalog (warehouse) | Catalog name on the Polaris side (lakehouse by default). |
| Warehouse S3 bucket (Storage tab) | The same bucket as the catalog's: select it to fill in endpoint, region and keys. |
| S3 endpoint, S3 region, Access Key ID, Secret Access Key (Storage tab) | Filled in by the bucket picker, editable afterwards — type them in for an external S3. us-east-1 by default for the region. |
| Number of workers (Capacity tab) | 1 by default. |
| Coordinator memory, Per-worker memory (Capacity tab) | 3Gi each by default. Stay ≥ 3 Gi: the JVM heap is fixed at 1400M and the rest is off-heap — an OOM was observed at 2 Gi under load. |
Signing in¶
Sign-in uses your platform account (OpenID Connect), and access is granted from Access to the users or groups you choose — see Access and permissions. Three ways in:
- The web UI,
https://<name>-<namespace>.<domain>/ui/: a monitoring console — running and past queries, cluster state. It is not a SQL editor, you cannot write queries there; - A SQL client:
trino --server https://… --external-authentication, which opens the browser to sign in; or JDBC withexternalAuthentication=true, for DBeaver or a third-party reporting tool; - A JupyterHub notebook of the same namespace: the
TRINO_HOSTvariable is already set there (name:8080, namespace-internal access), enough to pointtrino-python-clientat it without leaving the cluster.
Querying the lakehouse¶
CREATE SCHEMA lakehouse.sales;
CREATE TABLE lakehouse.sales.orders AS SELECT 1 AS id, 'test' AS label;
SELECT * FROM lakehouse.sales.orders;
Parquet files and Iceberg metadata appear in the bucket under <schema>/<table>-<uuid>/.
It is the same catalog as Spark Connect, PyIceberg and the Spark jobs: a table written by a Spark job is readable by Trino right away, and the other way around. One copy of the data, several engines — that is the whole point of the lakehouse.
What Trino does not do here¶
- No source federation: a single catalog is configured,
lakehouse, on the chosen Apache Iceberg instance. The upstream chart's demo catalogs (tpch,tpcds) are removed, and no connector to an application database (PostgreSQL, MySQL…) is exposed in the form. Querying such a database from Trino would mean adding a catalog in the chart values. - No heavy, long-running transformation: for expensive distributed processing, use Spark Connect for interactive work and the Spark jobs for batch.
First start
Allow 3 to 4 minutes before the first query, the time to start the JVM and load the plugins. The card turns Running before Trino answers.
Deletion¶
Deleting a Trino instance also removes its OpenID client from the platform.