Which open-source SQL query engine fits your lakehouse
If your data sits in object storage and several databases and you need one SQL layer across them, Trino is the default choice for interactive SQL in most teams we would expect to shortlist it. Presto is the other fork, with its own roadmap and a Java 17 runtime requirement, Spark SQL fits teams already operating Spark for batch, streaming or machine learning, and StarRocks fits teams that also want their own analytical storage. All four named options are Apache-2.0 licensed, so license alone will not decide between them. The decision turns on whether you want a query layer that leaves data in place, a compute engine you already run, or a database that owns its storage.
The main trade-off is between querying in place and loading into your own engine. Trino and Presto read through connectors and need a table catalog such as an Iceberg REST catalog or Hive Metastore, plus object storage, so governance, table maintenance and format choices stay in your hands. Spark SQL brings a full processing engine but no notebook workspace, scheduler UI, catalog or access control of its own, so you would assemble those pieces yourself. StarRocks reduces the number of moving parts for teams that accept storing data in its format, at the cost of a second system to govern. Fault tolerance also differs: Trino's fault-tolerant execution is off by default and needs an exchange manager spooling to object storage for the TASK policy.
Before committing, confirm three things in your own environment: which connectors and table formats your current sources and Iceberg or Delta tables require, which authentication and access control model your security team will accept (file-based, Apache Ranger or Open Policy Agent for Trino), and which Java and Kubernetes versions your platform team supports. Check the current release lines on each project's release page, since Trino, Presto and Spark ship on different cadences. Pilot one representative query workload against your real catalog before choosing, and ask a implementation partner to price the catalog, spooling and authentication work from that written scope.
Which SQL query engine to pick for each team situation
This table maps common team situations to the query engine that usually fits best, with the condition that makes each fit hold. Read each row as a starting point, then confirm connectors, catalogs and table format support in your own target environment before committing.
| Scenario | Best fit | Why |
|---|---|---|
| Querying an Iceberg or Hive lakehouse with a separate catalog | Trino | Trino's Iceberg connector works with Hive Metastore, AWS Glue, REST and Nessie catalogs and supports time travel and MERGE. Confirm the catalog type and Iceberg format version you run, since version 3 is experimental in Trino. |
| Federating queries across PostgreSQL, MySQL and Snowflake | Trino | Trino queries these sources in place through connectors, so data stays where it is. Confirm the specific connector versions, write support and per-catalog limits, such as one Snowflake database per catalog. |
| A team that already runs Spark for batch and streaming | Apache Spark SQL | Spark already covers batch, streaming and machine learning on the same cluster, so adding a second engine adds operations work. Keep Trino only if interactive analysts need a separate, lighter query layer. |
| A team wanting its own storage with object-storage-backed analytics | StarRocks | StarRocks can run with its own storage or shared-data on object storage, which Trino does not provide because it queries data where it lives. Confirm the deployment mode and object storage fit with your platform team. |
| A team that wants the Presto code base specifically | Presto | Presto is Apache-2.0 licensed and was split from the code base that became Trino in 2019, so the two have diverged. Choose it when you need Presto's own roadmap, connectors or Prestissimo native workers, and confirm the Java runtime and release line you plan to run. |
| Heavy fault-tolerant batch queries on long-running jobs | Trino with the TASK retry policy | Fault-tolerant execution is off by default and needs an exchange manager spooling to object storage or HDFS. Confirm the storage target and spooling cost before relying on it for large batch workloads. |
| Analysts who need a single SQL entry point over many sources with minimal cluster work | Trino, deployed on Kubernetes with Helm | Trino's documentation covers a Kubernetes Helm guide and a coordinator plus workers layout. Plan for a dedicated coordinator on larger clusters and confirm sizing with your own query patterns. |
Why Trino and Presto are now separate open-source SQL query engines
Trino and Presto share a root, but they have been separate projects since the 2019 split and now ship on different release lines. The four cards below cover the history a buyer needs and the checks that follow from it, before any feature comparison.
Presto's origin at Facebook
Presto was created at Facebook by Martin Traverso, Dain Sundstrom, David Phillips and Eric Hwang, who joined the company's data infrastructure team in 2012. Much of the code base that later branched into two projects dates from this period. For a buyer, the practical point is that older Presto documentation, blog posts and connector examples may describe either lineage, so check which project a tutorial targets before reusing it.
Two foundations in 2019
In January 2019 the creators started the Presto Software Foundation. Later that year Facebook established the Presto Foundation at The Linux Foundation in September 2019. The governance history matters because it explains why there were two parallel efforts with different maintainers. When you assess a vendor or support partner, ask which foundation or maintainer group stands behind the release line they will run, and where security advisories for that line are published.
The PrestoSQL fork becomes Trino
The fork that the creators had been developing under the PrestoSQL name was renamed Trino on December 27, 2020. Trino's documentation describes it as formerly known as PrestoSQL, so the two projects share a code base up to the 2019 split and have developed separately since. Any internal standard that refers to "Presto" should name the exact project, because a configuration key or connector that works in one may not exist in the other.
Separate release lines and runtimes
The two projects now move on their own schedules. Trino 484 was published on October 15, 2026, and Presto 0.299 on August 28, 2026. Their Java requirements also differ: Trino's deployment documentation calls for a 64-bit Java 25 runtime, minimum 25.0.1, while the Presto README lists a 64-bit Java 17 runtime. Confirm which runtime your platform team supports, and whether a connector you need is maintained for that project's current release.
How Trino, Presto, Spark SQL and StarRocks compare on capability
This table sets Trino, Presto and Spark SQL side by side on license, release, runtime, architecture, connectors, table formats, fault tolerance, security and built-in tooling. Cells marked confirm with vendor show where the supplied research is silent, so verify those before shortlisting. StarRocks is Apache-2.0 with a shared-nothing or shared-data design on object storage, so decide first whether you want an engine that owns its storage. Its other cells need confirmation against its documentation.
| Capability | Trino | Presto | Spark SQL |
|---|---|---|---|
| License | Apache-2.0 | Apache-2.0 | Apache-2.0 |
| Latest release and date | 484, October 15, 2026 | 0.299, August 28, 2026 | 4.2.0, July 14, 2026 |
| Runtime requirement | 64-bit Java 25, minimum 25.0.1, on 64-bit Linux | 64-bit Java 17, on Mac OS X or Linux | Confirm with vendor |
| Architecture | Coordinator plus workers; queries data in place through connectors | Coordinator plus workers; C++ Prestissimo worker built on Velox is available | Driver coordinating executors on Standalone, YARN or Kubernetes |
| Connector breadth | 37 connectors, including Iceberg, Delta Lake, Hive, Snowflake and SQL Server | Hive, Iceberg, Delta Lake, Kafka, Pinot, Druid and others; confirm full list | Confirm with vendor |
| Table format support | Iceberg format versions 1 and 2; version 3 experimental | Iceberg and Delta Lake connectors documented; confirm format versions | Confirm with vendor |
| Fault-tolerant execution | Off by default; QUERY or TASK retry policy, with TASK needing exchange spooling storage | Confirm with vendor | Confirm with vendor |
| Authentication and access control | Password file, LDAP, OAuth 2.0, Kerberos, certificates, JWT; file-based, Apache Ranger or Open Policy Agent | Confirm with vendor | Spark has no access control layer of its own; add a catalog or access layer |
| Built-in catalog or notebook | No; needs an external table catalog and object storage | Confirm with vendor | No notebook, scheduler UI, catalog or access control of its own |
What each engine is good at and where it gets harder
Trino is the strongest fit when the main job is running interactive SQL across many systems at once, especially an Iceberg lakehouse alongside operational databases. It queries data through connectors, so it does not hold its own storage. That design suits teams that want one SQL layer over several sources.
- Connector breadth: The documentation lists 37 connectors, including BigQuery, Iceberg, Delta Lake, Snowflake, PostgreSQL and SQL Server. This matters when your data sits in many systems and you want one query entry point.
- Iceberg writes: The Iceberg connector supports INSERT, UPDATE, DELETE and MERGE, with time travel and schema evolution, on format versions 1 and 2. Version 3 is marked experimental, so confirm its status before you depend on it.
- Fault-tolerant execution: It is off by default. The TASK retry policy, which the documentation recommends for large batch queries, needs an exchange manager that spools to S3, Azure Blob Storage, Google Cloud Storage or HDFS.
- Runtime requirements: The deployment guide calls for a 64-bit Java 25 runtime, minimum 25.0.1. Release 484 was published on October 15, 2026.
The hard part is everything around the engine. You run the object storage, a table catalog such as an Iceberg REST catalog or Hive Metastore, and the access control choice among file-based rules, Apache Ranger or Open Policy Agent. Confirm the connector versions and exchange manager settings you need against the fault-tolerant execution documentation before you size the cluster.
Presto is the right comparison point when a team already runs the Presto code base or wants a native C++ worker option. Presto and Trino shared code up to the 2019 split and have developed separately since, so they share history but now move on separate tracks. Check each project's current features rather than assuming parity.
- Prestissimo native worker: This C++ worker is built on the Velox library, lives in the presto-native-execution directory and implements the Presto worker REST API. It matters when you want native execution in the worker tier. Confirm which features and connectors it supports for your workload.
- Shared lineage: Presto was created at Facebook by four engineers, and the Presto Foundation was established at The Linux Foundation in September 2019. This matters if you want the prestodb governance model and its community.
- Java 17 runtime: The README lists a 64-bit Java 17 runtime, which is lower than the Java 25 requirement for Trino. This matters if your JVM standard is pinned to 17. Confirm that your chosen release supports it.
- Connector coverage: The documentation includes Hive, Iceberg, Delta Lake, Hudi, Kafka, Pinot, Druid and other connectors. Confirm the maturity of each connector you need.
- Release activity: Release 0.299 was published on August 28, 2026, after 0.298.1 on June 17, 2026.
The hard part is parity. Because the two projects now develop separately, you must verify the features you rely on, such as fault tolerance, authentication and access control, in the Presto release itself. A native worker also adds a second worker build to operate. Ask the maintainers which connectors and security options your workload depends on, and test the native worker on your own queries before you adopt it.
Spark SQL is strongest when your team already runs Spark for ETL, streaming or machine learning and wants SQL on the same engine. Spark is a general data engine, so SQL is one part of a wider platform. That is an advantage when the same jobs and skills already exist, and a cost when you only need an interactive query service.
- Existing Spark estate: One engine covers batch, streaming, distributed SQL and machine learning, with Python, SQL, Scala, Java and R. This matters when those workloads and skills are already in place.
- Cluster managers: Spark supports its standalone manager, Hadoop YARN and Kubernetes. Kubernetes fits teams that already operate a container platform.
- Spark Connect: Introduced in Spark 3.4, it is a client-server design that sends unresolved logical plans over gRPC and returns Apache Arrow batches. PySpark clients have been available since 3.4 and Scala clients since 3.5, which suits thin clients.
- Kubernetes operator: The Apache-2.0 Spark Kubernetes Operator manages Spark applications through the operator pattern. Confirm its maturity for your deployment.
- Versions and support: Spark 4.2.0 was released on July 14, 2026. The 3.5.x extended LTS ends in November 2027 with security fixes only. Spark 4 is built with Scala 2.13 and dropped Scala 2.12.
The hard part is what Spark leaves out. It has no notebook workspace, job scheduler UI, catalog or access control layer, so a self-hosted platform usually adds JupyterHub, Apache Airflow and a table catalog. You also design the authorization model yourself. Confirm which catalog and authorization layer you will run, and check your Spark version's support window before you standardize on it.
StarRocks is the option here for teams that want their own analytical storage alongside the query engine. It is an Apache-2.0 MPP analytics database and a Linux Foundation project, and it can run shared-nothing or shared-data on object storage. It is a different kind of choice from the three engines above, which query data where it already lives.
- Owned storage: Data is loaded into StarRocks, so you query one system directly. This matters when curated datasets are the main workload and you want a single analytics store.
- Deployment modes: Shared-nothing and shared-data on object storage differ in how compute and storage scale. Confirm which mode fits your growth pattern and failure model.
- Foundation and license: It is Apache-2.0 licensed and governed as a Linux Foundation project. Confirm the current security features and governance details in its documentation.
- External lakehouse access: If you still need to query Iceberg or other external tables in place, confirm the supported catalogs and formats. This comparison has no researched StarRocks connector data, so verify them directly.
- Release details: Confirm current version lines and support windows from the project's release page before you plan upgrades.
The hard part is ownership. You become responsible for storage design, ingestion pipelines, backups and upgrades of a stateful database, and for moving existing workloads into its storage. Ask for a written test on your own data volumes and access patterns before you decide to move data into it.
How fault tolerance and governance differ across these engines
Judge reliability first by what happens when a worker fails mid-query. Trino's fault-tolerant execution is off by default, so a team running long jobs must enable it deliberately with either a QUERY or a TASK retry policy, set through the retry-policy property. The TASK policy is the one to plan for with large batch queries, because it retries individual tasks rather than whole queries. It requires an exchange manager that spools intermediate data to S3, Azure Blob Storage, Google Cloud Storage or HDFS, so the spooling bucket or filesystem becomes a component you must size, secure, back up and monitor. Confirm the exact configuration keys and the failure modes you care about in the Trino fault-tolerant execution documentation before you commit to a batch design.
Judge access control by how identity reaches the engine and where authorization decisions are made. Trino documents password file, LDAP, Salesforce, OAuth 2.0, Kerberos, certificate and JWT authentication, so the choice usually follows your existing identity provider. For authorization, Trino offers file-based rules, Apache Ranger or Open Policy Agent, and each choice moves policy ownership to a different team. Spark is different: it does not supply its own access control layer, so governance comes from the surrounding stack, such as the table catalog, a notebook gateway or the scheduler you assemble around it. Presto and StarRocks have their own authentication and authorization features, and you should confirm their equivalents against their current documentation rather than assume they match Trino's list. No engine discussed here should be treated as audited or certified on the strength of this comparison. Ask each vendor or project for its own evidence, and have your assessor review your configuration.
How to choose and pilot an open-source SQL query engine
This five-step sequence turns a shortlist of Trino, Presto, Spark SQL and StarRocks into a pilot with recorded evidence, so the choice can be defended to a CISO or architect before any production commitment. Each step closes with a document the decision owner can review.
Inventory the sources and table formats
The data platform owner and the analysts who run the most important queries list every source the queries must reach, including databases, object storage paths and warehouses, and the table format used for each lakehouse table, such as Apache Iceberg, Delta Lake, Hudi, Hive tables or plain files. For each source, record the owner, the access path and whether the data is read only or must also be written. The step is done when the list is signed off by the data owner and each source is mapped to a candidate engine that can reach it. Connector counts in vendor documentation are a starting point, not proof, so the list drives the next step.
Confirm connectors and catalog support in target versions
The platform engineer checks each required connector and table format against the exact release the team would deploy, not against the latest documentation. For Trino, that means the Iceberg connector's catalog options (such as Hive Metastore, AWS Glue, REST or Nessie), the supported format versions and the write operations the team needs. For Presto and Spark SQL, confirm the equivalent support for the same catalogs and formats. Record the release number, the connector configuration used and any gaps, such as features marked experimental. The step is done when every mapped source has a tested connection or a documented workaround, and the gaps are shared with the architect.
Run representative interactive and batch queries
The analytics lead and platform engineer run a set of representative queries: short interactive dashboard-style queries, long joins and aggregations over large tables, and at least one scheduled batch job. Run each workload under the fault-tolerance setting the team would use in production. For Trino, that means choosing between no fault tolerance (the default), the QUERY retry policy or the TASK retry policy, and if TASK is chosen, provisioning an exchange manager that spools to object storage or HDFS. Record latency, failures, retries and resource use for each run, and note the setting used. The step is done when the results show whether the chosen configuration meets the workloads and what it costs in storage and compute.
Test authentication and access control against the identity provider
The security engineer connects the pilot cluster to the existing identity provider using the same protocol the production estate uses, such as LDAP, OAuth 2.0, Kerberos, certificates or JWT for Trino, and tests how user groups map to catalogs, schemas and tables. Then test the access control model, whether file-based rules, Apache Ranger or Open Policy Agent, by attempting queries that should be denied as well as allowed, and check that the audit trail records who queried what. Confirm with the vendor or the community documentation which controls exist in the target release, especially column-level and row-level controls. The step is done when a written access matrix has been tested with both allowed and denied cases and the results are reviewed by the CISO or security architect.
Measure the operating work for upgrades and runtimes
The platform team records the work needed to keep the engine running after the pilot. This covers the Java runtime version and how it is patched, the release cadence and upgrade steps for the engine, the coordinator and worker layout, and the storage and catalog components the engine depends on, such as object storage, a metastore and any spooling location. For Spark, include the cluster manager and the separate notebook, scheduler and catalog tools the platform will need, because Spark does not provide them. Ask each vendor or community maintainer for their release support window and security patch policy in writing, then compare against the team's change calendar. The step is done when the team has a written run book, an estimated monthly operating workload agreed with the platform owner, and a list of questions for the quote.
What running each engine yourself actually requires
Running Trino yourself starts with one coordinator plus workers, and the Trino deployment guide recommends a dedicated coordinator once the cluster grows. Plan for a 64-bit Linux host and a 64-bit Java 25 runtime, at minimum 25.0.1, and confirm that your base images and patch process can keep that runtime current. The recurring load is the upgrade cadence: release 482 shipped on June 25, 2026, 483 on July 17, 2026 and 484 on October 15, 2026. Teams that run Trino on Kubernetes can follow the project's Helm-based guide, but treat the chart as a starting point and decide which chart version, values and coordinator settings you will own. Name who tests and approves each upgrade before you commit to the platform.
A Trino lakehouse does not bring its own storage. Trino reads through connectors, so you run object storage for the table files and a table catalog such as an Iceberg REST catalog, AWS Glue or Hive Metastore. Each is a separate system with its own backup, access control and upgrade plan. Spark adds more components. Its cluster overview covers only cluster managers (standalone, Hadoop YARN and Kubernetes), and Spark ships no notebook workspace, job scheduler UI or catalog. A self-hosted Spark platform is usually assembled from JupyterHub, Apache Airflow and a table catalog, and each of those is another service to patch, secure and connect to your identity provider.
On versions, Spark 4.2.0 was released on July 14, 2026, with maintenance releases 4.1.3 and 4.0.4 on July 15, 2026 and 3.5.9 on July 16, 2026. Spark's versioning policy keeps feature branches for six months, and the 3.5.x extended LTS receives security fixes only until November 2027, so confirm which line your upgrade plan targets. Cost follows people and infrastructure. Staff time covers installation, identity and access setup, upgrades and on-call, while infrastructure covers compute nodes, object storage, catalog databases and backups in your own accounts or data centers. Ask any quote to state which costs are one-time and which recur, the environments in scope, the upgrade frequency and the handover documents. DeployOpen works from a written scope, so the quote follows from that scope.
What buyers ask before hiring help to deploy a SQL query engine
How much effort does a Trino lakehouse deployment take?
The effort depends mostly on how many moving parts the deployment has, not on the engine alone. A Trino cluster is one coordinator plus workers, and the deployment documentation recommends a dedicated coordinator for larger clusters, so cluster sizing and node layout are early decisions. The main drivers are the number of catalogs, the number and type of connectors, whether fault-tolerant execution is enabled and with which retry policy, and how identity integration is wired (password file, LDAP, OAuth 2.0, Kerberos, certificates or JWT). Each catalog also needs its own credentials, object storage access and, for Iceberg, a table catalog such as an Iceberg REST catalog or Hive Metastore. Ask for the effort to be broken down by these drivers in any written scope.
Can our team run Trino or Presto without outside help?
Yes, many teams run them in-house, and the decision turns on skills and staffing rather than on whether the software is hard to install. Trino needs a 64-bit Linux system and a 64-bit Java 25 runtime (minimum 25.0.1), and Presto needs a 64-bit Java 17 runtime, so your platform team must own the JVM, the Kubernetes or VM layer, upgrades and monitoring. Trino's Kubernetes guide with Helm reduces some of that setup work. Outside help usually adds value in connector configuration, identity and access control design, fault-tolerance tuning and documentation. Ask whether the people who will operate the cluster will be trained and named in the scope, since operating knowledge is what sustains the deployment after handover.
Can we swap Trino and Presto without rewriting queries?
Often partly, but do not assume a drop-in swap. Trino and Presto shared a code base until their 2019 split and have developed separately since, so SQL dialect details, function behavior, connector versions and session properties can differ. Connector coverage also differs in places, and the two projects ship on different release schedules, with Trino at release 484 and Presto at release 0.299 in the latest supplied releases. Before any migration, run a representative query set against both engines using the same catalogs and compare results, plans and error behavior. Ask the implementer to list every query, view and connector that would change, and to state what is in and out of scope for the rewrite.
What does Spark SQL need beyond the engine itself?
Spark SQL is one part of Spark, and Spark does not include its own notebook workspace, job scheduler UI, catalog or access control layer. A self-hosted Spark platform is therefore usually assembled from a cluster manager (standalone, Hadoop YARN or Kubernetes), a notebook environment such as JupyterHub, a scheduler such as Apache Airflow, and a table catalog. Each of those adds a component to secure, back up and upgrade. Spark 4 is built with Scala 2.13 and has dropped Scala 2.12 support, so job code and libraries need checking before upgrades. Ask for each added component to appear in the written scope with its owner.
What does StarRocks add when it also owns storage?
StarRocks is a different kind of choice from a query engine like Trino. Trino and Spark query data where it lives, so the lakehouse keeps separate object storage and a table catalog. StarRocks is an analytics database that can own its storage, so adopting it means data loading pipelines, table design, storage sizing, backup and restore, and upgrades become part of the platform you operate. That can simplify some workloads and add operational duties for others. Ask whether the plan is to keep an open lakehouse as the system of record or to move serving tables into StarRocks, because that choice decides the data movement, retention and recovery work.
What do you need from our team before work starts?
Expect to supply four things. Data owners must confirm which datasets, schemas and sensitivity classes are in scope and who approves access. The identity team must provide the chosen authentication method, group mappings and the access control model, whether file-based, Apache Ranger or Open Policy Agent. Storage and catalog teams must grant access to object storage buckets, Hive Metastore or Iceberg REST catalog endpoints, and any Snowflake or database accounts used by connectors. Finally, you need a representative test dataset with realistic query patterns, since performance and access tests depend on it. Ask the implementer to list these dependencies with named owners and dates before the scope is signed.
How long does a pilot take?
No supplied source gives a pilot duration, so any figure would be a guess. The length depends on the number of catalogs and connectors in the pilot, whether fault-tolerant execution is part of the test, how many identity providers and access rules must work, the availability of data owners and the cluster infrastructure. A narrow pilot with one catalog, one identity method and an agreed test dataset is far shorter to define than a multi-catalog pilot with governance tests. Ask for the timeline as milestones tied to the client inputs listed above, and for the acceptance criteria that close the pilot.
What should a written scope for a SQL engine include?
A useful written scope names the engine and version, the cluster topology, and the list of catalogs and connectors with their credentials and owners. It should state the authentication method, the access control model, the fault-tolerance policy and, for Trino, the exchange manager target if the TASK policy is used. It should list documentation, handover sessions, backup and upgrade procedures, and the test plan with acceptance criteria. Ask who is responsible for each deliverable, what is excluded (for example, data modeling or downstream dashboards), and how changes are priced. DeployOpen plans, implements, documents and supports these platforms inside your own infrastructure, and most engagements are fixed-scope, so the written scope is the basis for the quote.
How DeployOpen scopes and delivers a SQL query engine selection
DeployOpen helps teams choose and run a SQL query engine inside their own cloud accounts, data centers or air-gapped networks. Engagements start from a written scope that compares Trino, Presto and Spark SQL against your lakehouse, governance and staffing needs.
How we scope
- Inventory the lakehouse storage, table formats and catalogs already in use before comparing engines.
- Agree in writing which query patterns, connectors and user groups the selection must cover.
- Record governance, identity and fault-tolerance requirements so each candidate is tested against the same criteria.
How we build
- Deploy the shortlisted engines in your environment, including coordinator, worker and catalog configuration.
- Test connectors, table format behavior and access control against representative queries from your own data.
- Harden authentication, access policies and network paths to match your internal security standards.
How we hand over
- Deliver written runbooks covering deployment, upgrades, scaling and catalog configuration for your operators.
- Document the selection rationale, test results and open risks so decision makers can review them later.
- Walk your platform and security teams through the running system and the evidence it produces.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- Ongoing upgrades, monitoring and continuous testing are available as a retainer after handover.
- Ask any provider to confirm which engine versions, connectors and licenses they will support in writing.
