Trino Configuration

What is Trino?

Trino (formerly PrestoSQL) is TDP's distributed SQL query engine.

It allows you to query multiple data sources with a single SQL command — you can join a ClickHouse table with an Iceberg table in Ozone in a single SELECT, without moving data.

Trino does not store its own data: it is a federated query engine.

All data read or written by Trino comes from external sources called catalogs.

Each catalog points to a data source (Hive/Iceberg in Ozone, ClickHouse, PostgreSQL, Kafka) and uses a specific connector.

Learn more

See Trino — Concepts for a complete overview of the tool, its architecture and how it works.

Coordinator-worker architecture

Trino works with a coordinator + workers model:

Component	Role
Coordinator	Receives the SQL query, creates the execution plan and distributes the work
Workers	Execute parts of the plan in parallel, processing data from sources

You do not scale the coordinator — it is always one.

You scale the workers (trino.server.workers) to increase parallelism.

In production, configure autoscaling (trino.server.autoscaling) so that workers scale with load.

This page describes the Trino configuration in TDP Kubernetes. The tdp-trino chart deploys the coordinator, workers and configurable catalogs for distributed SQL queries.

Overview

Property	Value
Chart	tdp-trino
Trino Version	478
Chart Version	3.0.0
Registry (examples)	oci://registry.tecnisys.com.br/tdp/charts/tdp-trino

Installation

Example

helm install <release> oci://registry.tecnisys.com.br/tdp/charts/tdp-trino \
  -n <namespace> --create-namespace

Resource names follow the Helm release; multiple instances can coexist in the cluster with different releases.

Main parameters (chart)

Parameter	Description	Typical default
trino.enabled	Enable Trino	true
trino.image.tag	Image tag	See helm show values
trino.server.workers	Worker replicas	2
trino.server.node.environment	Trino environment label	Placeholder in values
trino.service.port	Service port	8080
trino.ingress.enabled	Ingress	false
trino.server.autoscaling.enabled	HPA on workers	false
trino.server.keda.enabled	KEDA on workers	false
trino.jmx.enabled	JMX	false
trino.serviceMonitor.enabled	ServiceMonitor	false
trino.accessControl	Access control (optional)	{}
trino.catalogs	Catalog definitions	E.g.: tpch / tpcds / memory (see values.yaml)
trinoCerts.pvc.enabled	PVC for certificates	false
trinoCerts.secret.enabled	Secret with certificates	false
trinoCerts.copyJob.enabled	Pre-install job to copy certificates to PVC	false

Catalogs (connectors)

Catalogs are configured under trino.catalogs. To enable a connector, add an entry in properties format, following the examples in the chart's values.yaml.

Generic example (PostgreSQL — adjust host, database and credentials):

trino:
  catalogs:
    postgresql: |
      connector.name=postgresql
      connection-url=jdbc:postgresql://<db-host>:5432/<database>
      connection-user=<user>
      connection-password=<password>

In-memory catalog example:

trino:
  catalogs:
    memory: |
      connector.name=memory

Apply with helm upgrade using your values file or -f.

TLS and certificates (trinoCerts)

When HTTPS or a keystore is required (for example with LDAP enabled), the chart can:

• provision a PVC (trinoCerts.pvc)
• reference a Secret with files (trinoCerts.secret)
• run a Job before install/upgrade to copy from the Secret to the PVC (trinoCerts.copyJob)

Exact mounting details and key names are in the chart's values.yaml.

LDAP and HTTPS

With ldap.enabled: false (default): HTTP on port 8080, no mandatory authentication.

With ldap.enabled: true and LDAP values: HTTPS on port 8443, PASSWORD authentication, certificate volumes and associated secrets.

Steps and values examples are in Security — Trino. Ingress with LDAP typically requires TLS passthrough — see Ingress — Trino.

Connecting to Trino

The Kubernetes service DNS name is typically the release name or the one defined by the chart; check with:

kubectl -n <namespace> get svc

Same namespace

• Host: <trino-service-name>
• HTTP port: 8080 (without LDAP)
• HTTPS port: 8443 (with LDAP, as configured)

Different namespace

• Host: <trino-service-name>.<namespace>.svc.cluster.local

Examples

Python (trino client):

import trino

conn = trino.dbapi.connect(
    host="<trino-service-name>",
    port=8080,
    user="<user>",
    catalog="tpch",
    schema="tiny",
    http_scheme="http",
)

CLI:

trino --server http://<trino-service-name>:8080 \
      --user <user> \
      --catalog tpch \
      --schema tiny

Local access (port-forward)

kubectl -n <namespace> port-forward service/<release> 8080:8080

(With LDAP/HTTPS, use port 8443 in the mapping as needed.)

Scaling

Trino uses one coordinator and multiple workers. The number of workers is controlled by trino.server.workers or autoscaling resources in values.yaml, as supported by the chart — do not scale the coordinator to more than one replica.

Troubleshooting

kubectl -n <namespace> get pods
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Uninstallation

helm uninstall <release> -n <namespace>

For the full list of parameters, see the chart's values.yaml.