Trino vs Presto

Trino and Presto share a root, but they have been separate projects since 2019, so a vendor risk review should evaluate each one on its own governance record. Presto was created at Facebook by Martin Traverso, Dain Sundstrom, David Phillips and Eric Hwang, who joined Facebook's data infrastructure team in 2012. In January 2019, the creators started the Presto Software Foundation. In September 2019, Facebook established the Presto Foundation at The Linux Foundation. On December 27, 2020, the creators renamed their PrestoSQL fork to Trino. That sequence explains why the two names now refer to different code bases with different owners.

The governance difference is structural and should be checked against each project's own documents. Trino is maintained under the trinodb organization by the creators' project, while Presto is maintained in the prestodb repository under the Presto Foundation at The Linux Foundation. The Trino announcement of the rename is the primary public account of this history, and it is the document to cite in your file. Ask each project for its written governance model, its trademark and copyright holders, its contributor license terms, and how maintainer decisions are made. Record the answers, since a foundation structure and a company-founded project carry different continuity and exit assumptions.

Treat version numbers as project-specific. Presto release 0.299 (August 28, 2026) and Trino release 484 (October 15, 2026) follow separate numbering and separate release processes, so a security advisory or upgrade note for one does not apply to the other. Build the vendor file with one row per project, and add a check that confirms the repository, package registry and documentation domain you deploy from belong to the project you approved. Ask the team that owns your risk review to confirm whether a Linux Foundation-hosted project meets its requirements, and whether the creators' project meets the same bar, before the choice is signed off.

The running cost of a self-hosted Trino or Presto cluster comes from several separate lines, and the engine's license is the smallest of them. Both projects are Apache-2.0 licensed, so there is no license fee to pay. Your spend goes to compute for the coordinator and workers, object storage holding the data, a table catalog such as an Iceberg REST catalog or Hive Metastore, and the people who build and operate the platform. Because Trino queries data in place through connectors, storage and catalog are not bundled with the engine. Ask your team to price each of these as its own line item, and to say which ones are one-time and which recur.

One-time work includes sizing the coordinator and workers, choosing and deploying the catalog, wiring authentication (password file, LDAP, OAuth 2.0, Kerberos, certificates or JWT, as the security documentation describes) and setting up access control through file-based rules, Apache Ranger or Open Policy Agent. Recurring work is where most of the effort sits: Java runtime maintenance, Kubernetes or VM operations if you use the Trino Helm guide, monitoring, and applying each new release. Trino's release notes show releases 482, 483 and 484 in roughly four months, so budget staff time for regular upgrades rather than treating the install as finished. Confirm the Java version each release requires before scheduling a cutover.

Support is the cost line most open to choice. If you run the community projects yourself, the cost is internal engineering time, and the cost of a bad upgrade or a stalled query is carried by your own on-call team. If you buy support from a vendor, ask for a written scope that names the release lines covered, response expectations, and whether upgrades and testing are included. The main drivers of the total are cluster size and query concurrency, the number of catalogs you connect, whether you enable fault-tolerant execution (which adds spooling storage in S3, Azure Blob, Google Cloud Storage or HDFS), and how many engineers already know Java and Kubernetes. Any quote should follow a written scope that lists your own infrastructure, data volumes and team skills.

Most Trino projects slip in the same few places, and the schedule risk sits mainly in the JVM and the identity layer rather than in the query engine itself. Trino's deployment documentation requires a 64-bit Linux system and a 64-bit Java 25 runtime, minimum 25.0.1, so teams that standardize on an older Java image often lose time on JVM sizing, garbage collection settings and coordinator memory limits during the first load tests. Presto's README asks for Java 17, so a team that runs both, or that is migrating from a Presto deployment, should confirm the runtime version early and rebuild its container images to match rather than assuming an existing JVM baseline carries over.

The second source of delay is catalog and credential wiring. Each connector, from Hive and Iceberg to PostgreSQL, Snowflake or SQL Server, needs its own catalog properties, network paths and service accounts, and the Snowflake connector maps one Snowflake database per catalog. Identity is usually the longest item. Trino documents password file, LDAP, OAuth 2.0, Kerberos, certificate and JWT authentication, and the choice has to match your directory and token issuer. Access control adds a further decision: file-based rules, Apache Ranger or Open Policy Agent. Confirm with your security team which model is the system of record for table and column permissions before the first catalog goes live, because retrofitting it after users have queries in production is slow. Fault-tolerant execution is the third area to plan for if batch queries matter. It is off by default, and the TASK retry policy needs an exchange manager that spools intermediate results to S3, Azure Blob Storage, Google Cloud Storage or HDFS, so it requires storage, permissions and sizing work that a dashboard-only deployment does not. Ask your provider to estimate that work as a separate line in the written scope. DeployOpen plans, implements and documents these pieces inside your own cloud accounts or data centers under a fixed scope agreed in writing before work starts, which makes the Java, identity, access control and exchange manager decisions visible at the start instead of discovered at cutover.