Trino

Analysts often need to ask questions across data kept in different databases and storage systems. Trino provides a distributed SQL query engine with connectors to those systems, using a coordinator and workers to execute the work. It offers a shared query layer rather than requiring every underlying dataset to live in a new database. Connector behavior, source permissions and query resource limits determine whether it fits the workload, and its project and release path are separate from PrestoDB’s.

Chart ownership

Trino's documentation recommends the project-hosted community chart repository. The trino/trino chart is published at trinodb.github.io/charts; Trino Gateway has a separate chart in that repository. Keep this project distinct from the directory's historical Presto entry and verify connector behavior before migrating workloads.

Before adoption

Set explicit application and chart versions, then size coordinator and worker memory using representative queries. Upstream cautions against packing multiple Trino pods onto the same physical host because of resource contention. Protect catalog credentials and restrict which users can reach each dataset. Test expensive joins, concurrent queries, worker loss and cancellation. Kubernetes deployment does not remove the need for source-system access controls, query limits and careful JVM memory configuration.