Skip to main content

Overview

Trino is a distributed SQL query engine that queries data where it lives. This template deploys a Trino cluster — one coordinator plus a scalable worker tier — that connects to PostgreSQL, MySQL, ClickHouse, MongoDB and 40+ other sources through catalogs, and joins across them in a single query without copying any data. Databases you already run on Control Plane are reachable over internal DNS, so a query can span several of them at once. Trino stores nothing itself: it plans and executes queries against your existing systems, so there are no volumes and a restart costs only the queries in flight.

Architecture

  • Coordinator — Parses and plans queries, serves the Web UI and the JDBC/REST endpoint on port 8080, and tracks the workers. Always exactly one replica.
  • Workers — Stateless execution tier on port 8080, workers.replicas replicas. Setting workers.replicas: 0 collapses the cluster to a single node where the coordinator executes queries itself.
  • Catalogs — One properties file per data source, mounted on every node. The image already ships the tpch, tpcds, memory and jmx catalogs, so a default install is queryable immediately.

What Gets Created

  • Standard Coordinator Workload — A single replica serving clients, the Web UI and worker discovery on port 8080.
  • Standard Worker Workloadworkers.replicas interchangeable execution replicas on port 8080. Not created when workers.replicas: 0.
  • Config Secrets — The rendered config.properties (one per tier), jvm.config and node.properties, mounted into /etc/trino.
  • Catalog Secrets (optional) — One per catalogs[] entry, mounted as /etc/trino/catalog/<name>.properties on every node.
  • Password-authenticator Secret (optional) — Created on the coordinator when auth.enabled.
  • Identity & Policy — One identity shared by both workloads, with a policy granting reveal on exactly the config, catalog and authentication secrets in use — including the credential secrets you created yourself.
  • No Volume Sets — Trino owns no data.
This template does not create a GVC. You must deploy it into an existing GVC.

Prerequisites

  • None for a default install. The built-in tpch, tpcds, memory and jmx catalogs make the cluster queryable the moment it is ready.
  • To query your own data sources: one Control Plane secret per credential, created before installing — see Connecting Data Sources. Credentials are never passed through values.
  • To enable authentication (required for public access): two opaque secrets created before installing — see Authentication.

Installation

Install the template using your preferred method:

UI

Browse, install, and manage templates visually

CLI

Manage templates from your terminal

Terraform

Declare templates in your Terraform configurations

Pulumi

Declare templates in your Pulumi programs

Configuration

The default values.yaml for this template:

Coordinator and Workers

  • image — The Trino container image. The chart is shipped and tested on Trino 483.
  • coordinator.resources — CPU and memory for the single coordinator replica.
  • workers.replicas — Number of worker replicas. Raise it for more query throughput and to keep capacity available through a rolling restart; 0 collapses the cluster to a single node where the coordinator both plans and executes.
  • workers.resources — CPU and memory per worker replica.
maxMemory must be a whole number of GiB and at least 2Gi, minMemory may not exceed maxMemory, and maxCpu:minCpu may not exceed 4:1 (a Control Plane limit) — the chart refuses to render otherwise, with a message naming the value to fix.

JVM and Memory

jvm.maxRAMPercentage (default 70, allowed range 40–80) sets the JVM heap as a percentage of each tier’s maxMemory. Trino derives its per-node query memory and headroom from that heap, so maxMemory is normally the only number you change. Capacity AI is disabled on both workloads: the JVM sizes its heap from the container limit at startup, so shrinking the container afterwards would be an out-of-memory kill with no diagnostic.

Catalogs

Each catalogs[] entry renders one secret and mounts one file at /etc/trino/catalog/<name>.properties on every node: Object-storage catalogs (Hive, Iceberg, Delta Lake) are not offered in this version — they require an external metastore.

Authentication

auth.enabled turns on Trino’s file-based password authentication on the coordinator and the shared secret that nodes use to authenticate to each other. It requires publicAccess.enabled, and both secret names are required when it is on. Create both opaque secrets before installing:
auth.enabled requires publicAccess.enabled, and the chart enforces both directions. Trino’s server refuses password authentication over plain HTTP, so an internal-only cluster with authentication on cannot be queried by anyone — in-GVC clients get 401 Password not allowed for insecure authentication. Either enable public access (TLS terminates at the Control Plane edge) or leave authentication off and let the internal firewall be the boundary. Public access without authentication is rejected too: an unauthenticated Trino on the internet is a read primitive over every connected data source.

Access

  • publicAccess.enabled — Serve the Web UI and the JDBC/REST endpoint on the automatic *.cpln.app HTTPS endpoint. Requires auth.enabled. When off, external requests are blocked at the edge even though the workload still has a canonical endpoint.
  • internalAccess.type — Which workloads inside Control Plane may reach the coordinator:
none is rejected by the chart. The coordinator addresses itself by service DNS, so its own task and status calls travel through this internal firewall — with none every query fails with 403 RBAC: access denied, even at workers.replicas: 0.
The worker tier keeps its own least-privilege firewall regardless of this setting: only the coordinator and sibling workers may reach it.

Connecting Data Sources

Point a catalog at any database Trino can reach. Templates deployed in the same GVC are reachable at {workload-name}.{gvc}.cpln.local. Credentials always come from a secret you create first and are referenced with Trino’s ${ENV:NAME} substitution, so no password is written into values or into any rendered file — the mounted catalog file contains only the placeholder.
1

Create the credential secret

Use an opaque secret for a single credential, or a dictionary secret when one secret holds several values:
2

Add the catalog to your values

Reference the secret by name and inject it as an environment variable:
3

Query it

The catalog appears in SHOW CATALOGS once the cluster restarts with the new values.

Catalog Examples

Worked entries for the sibling database templates:
The matching templates are postgres, postgres-highly-available, mysql, mariadb, clickhouse and mongodb.

Querying Across Catalogs

With several catalogs configured, one statement spans all of them — including the built-in tpch data — and Trino performs the join itself:
Trino reads from each source at query time; nothing is copied and nothing is written back.

Connecting

With authentication on, the Web UI login form is served at /ui/legacy/login.html on the public endpoint.

Availability

Trino has no fault-tolerant execution in this template: a query running on a node that goes away fails and must be retried. Measured on a 3-worker cluster: The coordinator is the single point of failure — open-source Trino has no coordinator failover, and this template does not claim otherwise. Workers are interchangeable, so workers.replicas is the knob for both capacity and restart tolerance. At the default workers.replicas: 1 a rolling restart empties the execution tier entirely, so every query in flight fails for the duration.

Important Notes

  • Every catalog credential secret must exist before installing — a missing secret leaves the deployment waiting and the cluster never becomes ready.
  • Rotating a secret’s payload does not take effect until the workloads are redeployed. Control Plane resolves secret-backed environment variables at deployment time, so run a Helm upgrade after changing a credential.
  • auth.enabled requires publicAccess.enabled, and public access requires authentication — the chart rejects either one on its own at render time.
  • internalAccess.type: none is rejected — the coordinator must be able to reach itself over the internal path.
  • Trino is read-oriented here — it queries the databases you connect; the template never installs or modifies them, and uninstalling removes only the cluster. Your own credential secrets are left in place.
  • Keep the GVC single-location — coordinator-to-worker traffic is per-query and latency-sensitive.

External References

Trino Documentation

Official Trino documentation

Connectors

Every available connector and its properties

SQL Reference

Trino SQL statement and syntax reference

JDBC Driver

Connect BI tools and applications over JDBC

Password File Authentication

How the bcrypt password file is used

Secrets in Properties Files

The ${ENV:NAME} substitution used by catalog credentials

Trino Template

View the source files, default values, and chart definition