# Presto

> Distributed SQL engine, and the project Trino forked from

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.

Website: https://prestodb.io

## 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

### General

| Attribute | Value |
| --- | --- |
| License | Open source (permissive) |
| SPDX identifier | Apache-2.0 |
| Deployment | Self-hosted, Managed |
| Workload | Interactive, Batch |
| Operational complexity | High |
| Pricing | Free, Subscription |
| Language | Java, C++ |
| Repository | https://github.com/prestodb/presto |
| Documentation | https://prestodb.io/docs/current/ |
| Stars | 16.7k |

### Query Engines

| Attribute | Value |
| --- | --- |
| Engine shape | Distributed cluster: coordinator and workers; Presto C++ swaps the Java workers for Velox with no JVM on them |
| 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 |
| 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) |
| Client access | JDBC and ODBC drivers, the presto-cli shell, and an HTTP REST API the client libraries wrap |
| 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 |
| Access control | SystemAccessControl plugins: file-based rules, or Ranger for catalog, schema, table and column policies with allow and deny conditions |

## Capabilities

- [Query Engines](https://matca.io/capabilities/query-engine)

---

Source: https://matca.io/presto
Last updated: 2026-08-31T11:40:49.386Z