Presto
Presto is a distributed SQL query engine for federated analytics, governed by the Presto Foundation under the Linux Foundation, whose members include Meta, IBM, Uber, and Nvidia — the original codebase that PrestoSQL forked from before renaming itself Trino.
LicenseOpen source (permissive)· Apache-2.0
DeploymentSelf-hostedManaged
PricingFreeSubscription
Operational complexityHigh
WorkloadInteractiveBatch
LanguageJava, C++
Use it when
- You are already on the PrestoDB side of the fork: operational lore from Meta and Uber, IBM support, or existing EMR Presto clusters.
- Federated SQL across roughly 45 connectors, joined in one query, is the job.
- You want C++ workers (Velox) with no JVM tuning on the data path.
- RaptorX caching matters: metastore, file, and fragment-result caches hold latency down on hot data.
Think twice when
- You are choosing fresh between the forks; Trino has run at roughly three times the commit volume with a larger community, and the capability gap is small.
- A lost worker kills the query, and retry is whole-query only; Trino's task-level fault tolerance resumes instead.
- Nobody wants to operate a coordinator-and-workers cluster; Athena or Starburst Galaxy removes that.
How it runs
Self-hosted as a coordinator plus workers on VMs or Kubernetes, optionally with C++ Velox workers; managed flavors ship in EMR and IBM watsonx.data. Lake connectors want a Hive Metastore or Glue. Resource groups queue and cap concurrent workloads. Clients use JDBC, ODBC, the presto-cli shell, or the REST API.
Details
CompareHow Presto answers the questions Query Engines turns on.
Query Engines
| How it works | |
| Engine shape | Distributed cluster: coordinator and workers; Presto C++ swaps the Java workers for Velox with no JVM on them |
| Catalog required | A Hive Metastore or Glue for the Hive connector; the Iceberg connector also takes Hadoop, Nessie or REST |
| SQL dialect | Presto SQL (ANSI-based) |
| Running it | |
| Concurrent users | Resource groups queue rather than fail, selectors route by user, source or client tag, with soft and hard limits on concurrency, memory and CPU |
| Acceleration | RaptorX hierarchical caching: versioned metastore cache, file list cache, file handle and footer cache, fragment results and Alluxio data on worker SSDs |
| Failure recovery | A lost worker kills the query; retry is whole-query only, onto a backup cluster or through a per-query limit that is off by default |
| Connections | |
| Non-lake sources | Around 45 connectors (Hive, Iceberg, Delta, Hudi, Postgres, MySQL, Kafka, MongoDB, Elasticsearch, Druid, Pinot, BigQuery, Redshift, Arrow Flight) and one query can join across them |
| Table formats | ORC, Parquet and Avro through the Hive connector; Iceberg, Delta and Hudi have connectors of their own, Hudi read-only |
| Client access | JDBC and ODBC drivers, the presto-cli shell, and an HTTP REST API the client libraries wrap |
| Access | |
| Access control | SystemAccessControl plugins: file-based rules, or Ranger for catalog, schema, table and column policies with allow and deny conditions |
Alternatives to Presto
