PrestoDB and Trino are separate open-source distributed SQL query engines with shared ancestry. The Presto project created at Facebook was open-sourced in 2013. A group of original creators later formed PrestoSQL, which was renamed Trino in December 2020. The projects now have separate governance, releases, documentation, connectors, and behavior.

What a distributed SQL engine does

Presto and Trino query data where it resides through connectors. They are not storage systems and do not automatically make heterogeneous sources consistent. Performance and semantics depend on the selected project/version, connector, source system, data layout, statistics, network, memory, concurrency, and SQL.

Coordinator and workers

The coordinator parses and plans queries, schedules stages and tasks, and returns results. Workers execute tasks against connector splits and exchange intermediate data. A production design must account for coordinator availability, worker loss, discovery, memory pressure, spill, retries where supported, and source-system failure.

Catalogs, connectors, schemas, and tables

A catalog configures a connector and its properties. Connectors expose source-specific schemas, tables, types, predicates, metadata, and write capabilities. Names that look uniform in SQL can still have different null, timestamp, decimal, collation, transaction, authorization, and pushdown behavior.

How queries execute

A query is parsed, analyzed, optimized into stages, divided into tasks, and run across workers. Data may be read from sources, filtered or aggregated through connector pushdown, repartitioned across the network, joined, and merged. Use the engine’s explain and runtime statistics to inspect the deployed version; plans are diagnostics, not stable APIs.

Start with a bounded local environment

Follow current official documentation, pin the engine and Java versions, verify artifacts, and use sample catalogs with nonsensitive data. A localhost UI is for the local environment only. Do not expose it publicly or treat a single-node coordinator/worker configuration as production guidance.

Secure the complete path

Configure authentication, TLS, authorization, catalog and schema access, impersonation policy, secrets, network boundaries, resource groups, audit evidence, and source credentials. The query engine cannot grant more safety than the underlying connector and source enforce. Test identity propagation and row/column controls end to end.

Evaluate performance and reliability

  • Use representative data volume, file size/layout, partitions, statistics, skew, and query shapes.
  • Measure correctness, p50/p95/p99 latency, throughput, queue time, failures, retries, scanned bytes, network exchange, spill, and source load.
  • Test high-cardinality joins, broad scans, many small files, concurrency, worker loss, coordinator restart, and source throttling.
  • Use resource groups and limits so one tenant or query cannot consume uncontrolled capacity.
  • Compare PrestoDB and Trino only with frozen versions, connectors, resources, and acceptance criteria.

Continue with a local Trino sample project, then study Trino performance tuning and cloud-storage integrations.

Do not use “Presto/Trino” as if the names describe one interchangeable current product. State which project, release, connector, and documentation support each configuration or claim.

Originally published February 17, 2021; technically reviewed and substantially updated September 4, 2026.