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.replicasreplicas. Settingworkers.replicas: 0collapses 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,memoryandjmxcatalogs, 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 Workload —
workers.replicasinterchangeable execution replicas on port8080. Not created whenworkers.replicas: 0. - Config Secrets — The rendered
config.properties(one per tier),jvm.configandnode.properties, mounted into/etc/trino. - Catalog Secrets (optional) — One per
catalogs[]entry, mounted as/etc/trino/catalog/<name>.propertieson 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
revealon 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,memoryandjmxcatalogs 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 defaultvalues.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;0collapses 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
Eachcatalogs[] 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:
Access
publicAccess.enabled— Serve the Web UI and the JDBC/REST endpoint on the automatic*.cpln.appHTTPS endpoint. Requiresauth.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:
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:Querying Across Catalogs
With several catalogs configured, one statement spans all of them — including the built-intpch data — and Trino performs the join itself:
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.enabledrequirespublicAccess.enabled, and public access requires authentication — the chart rejects either one on its own at render time.internalAccess.type: noneis 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 credentialsTrino Template
View the source files, default values, and chart definition