Presto

I recommend PrestoDB for data teams that need SQL across a lake and several databases, and have engineers available to operate the service. Its strongest appeal is control over distributed analytics, but the absence of a software subscription does not make it a low-maintenance choice.

Key Takeaways

• Presto can query multiple configured data sources within one SQL statement.
• The open-source core has no software license subscription under Apache 2.0.
• Resource groups give operators control over competing workloads.
• Deployment and security require deliberate engineering work.
• Connector capabilities vary, and native C++ workers have additional compatibility limits.

This Presto review covers PrestoDB, the distributed SQL query engine, not the unrelated Presto AI product. In the warehouses and lakehouses category, it fits most naturally as a lake query engine: it provides an analytical SQL layer rather than a complete storage platform.

I like that distinction because it makes the buying decision clearer. If your data already lives in useful systems, a new query layer may be more appropriate than another migration project.

My concern is the work behind that flexibility. Below, I explain the ownership costs, the documented setup path, and the limitations that matter before committing a team to Presto.

Presto Pros and Cons

Presto’s advantages are most convincing when infrastructure control is something you actually need. I see less value in taking on a distributed service merely to avoid paying a software fee.

My main reservation is not any single missing feature. It is the gap between making a query work and running a dependable shared service. For an established platform team, that gap can be manageable. For a lone analyst, it can become the project.

How Much Does Presto Cost?

Presto pricing starts with $0 in core software license fees. The source is Apache 2.0 licensed, without a mandatory subscription for self-hosted use.

There are no core Basic, Pro, or Enterprise plans to compare. Instead, the choice is how to deploy and support the software:

• Local evaluation: Run a development instance on existing hardware. This suits learning and initial compatibility work, not estimating production capacity.
• Self-managed cloud deployment: Pay for the infrastructure you provision and assign responsibility for operating it.
• Self-managed existing infrastructure: Use available servers, while accounting for capacity consumption and maintenance rather than treating them as free.
• Separately purchased assistance: Include any external support contract in the budget. It is not bundled into the open-source license.

Cost component	Pricing basis	What to budget for
Core software license	$0 license subscription	Apache 2.0 obligations still apply
Compute	Infrastructure-dependent	Coordinator and worker capacity
Storage	Backend-dependent	Lake data, logs, and applicable temporary storage
Network	Deployment-dependent	Traffic between sources and compute
Metadata services	Service-dependent	Metastore or catalog operation
Engineering	Internal staffing cost	Deployment, upgrades, tuning, and incident response
External support	Separate agreement	Only the assistance explicitly purchased

The largest budgeting mistake is comparing a managed service bill against only Presto’s virtual-machine bill. Engineering time belongs in both comparisons, including time spent diagnosing why a query stopped working after a source or configuration change.

Utilization matters, too. A cluster reserved for occasional reporting can consume resources between useful queries. A busy shared deployment has a different economic profile, but it also needs more careful workload policies. Neither situation supports a universal monthly price.

I recommend separating the initial adoption budget from the recurring operating budget. The first covers connecting representative data and establishing secure access. The second covers keeping that service useful as demand changes. A successful proof of concept does not erase the second category.

For a meaningful estimate, start with the reports that matter rather than a hypothetical maximum dataset. Identify when they run, which sources they touch, and who responds when they fail. Those details produce a more useful cost model than a license comparison.

Is Presto Good Value for Money?

I see good value when ownership of the query layer solves a specific architectural problem:

• Existing platform team: Presto is more attractive when deployment and monitoring fit established responsibilities.
• Several analytical sources: Federation can justify the effort if it avoids maintaining unnecessary copies.
• Occasional AWS lake queries: Athena deserves consideration when reducing cluster administration matters more than owning the runtime.

My recommendation for a capable data engineering team is a small self-managed evaluation with a named operational owner. For an analyst-only team, I favor a managed approach over adopting Presto purely because its license costs nothing.

Getting Started With Presto

Getting started is a deployment task, not an account-signup flow. SQL familiarity helps once the service is available, but somebody must first make the engine and its data sources accessible.

I recommend a staged evaluation. Begin with generated data, connect one real source, and add federation only after the individual connections make sense. This separates basic server problems from storage permissions and connector behavior.

The documented Java deployment uses Java 17 for the coordinator and Java workers. A coordinator plans queries and schedules work; workers execute tasks. For development, one instance can perform both roles.

A manual setup involves these steps:

1. Prepare the runtime: Install the required Java version and unpack the server distribution.
2. Create configuration files: Define node, JVM, and server settings under etc, including the data directory.
3. Choose the development layout: Configure a combined coordinator and worker for an initial evaluation.
4. Add a catalog: Supply connector properties for the first data source.
5. Start the server: Use the launcher and inspect logs if startup fails.

For a Homebrew-based evaluation, the documented route is brew install prestodb, followed by presto-server run. That distribution also includes the presto command-line client.

These routes make an evaluation accessible, but sample memory allocations are not production sizing advice. Hardware and workload requirements need their own sizing decision.

The naming model is worth understanding early:

Term	Meaning	Illustrative example
Connector	Adapter for a source type	Hive connector
Catalog	Configured connector instance	lake
Schema	Group of tables within a catalog	sales
Table	Queryable relation	orders
Qualified table name	Catalog, schema, and table	lake.sales.orders

For the first SQL smoke test, the TPCH connector avoids the need for an external database. Create etc/catalog/tpch.properties containing connector.name=tpch, then connect the CLI using the tpch catalog and tiny schema.

TPCH generates deterministic sample data on demand. Its tiny schema uses scale factor 0.01. A sensible progression is SHOW TABLES, a small SELECT, and then a grouped aggregation.

I like this progression because each step answers a narrower question. It establishes basic query access before adding source-system credentials. It is not a production benchmark, and its results should not become a capacity forecast.

For a real lake, the Hive connector can read formats such as Parquet and ORC without invoking Hive’s execution engine. A documented Thrift catalog uses connector.name=hive-hadoop2 with a metastore URI; AWS Glue is another supported metadata route.

An S3 location alone is not enough. The files need usable table metadata and appropriate storage access. I recommend starting with one known table and a narrowly scoped query before introducing cross-source joins.

The browser console defaults to port 8080. Query Viewer exposes plans and stage-level diagnostics, rather than acting as a no-code dashboard builder. Query information resets after server restarts, although query JSON can be exported and reopened.

That distinction matters for evaluation planning. A working SQL prompt proves access, while a useful operating environment also needs a way to investigate failures and retain relevant evidence.

Querying Across Lakes and Databases

Federation is my main reason to shortlist Presto rather than simply add another database. It can expose separately configured sources through a common SQL interface, allowing a query to reference more than one catalog.

The connector range includes familiar lake and database technologies:

• Lake sources: Hive, Iceberg, Delta Lake, and Hudi.
• Relational sources: MySQL, PostgreSQL, and SQL Server.
• Other systems: Kafka, MongoDB, Redis, and Elasticsearch.

I care more about the exact connector behavior than the length of that list. A connector’s presence does not establish complete compatibility with its source system.

Consider an illustrative reporting question: how much revenue came from each customer segment last month? Orders might reside in a lake, while current customer segments live in MySQL.

With suitable catalog definitions, the SQL could look like this:

SELECT c.segment, SUM(o.total_amount) AS revenue
FROM lake.sales.orders o
JOIN crm.customers.customer c ON o.customer_id = c.customer_id
WHERE o.order_date >= DATE '2026-09-01'
  AND o.order_date < DATE '2026-10-01'
GROUP BY c.segment;

This example assumes those tables and columns exist. Its appeal is straightforward: the question does not first require a new consolidated database.

However, federation is not zero data movement. Source reads and distributed execution still involve data transfer. I also recommend agreeing on acceptable analytical load with whoever owns the application database before opening access to a reporting audience.

There is a semantic concern beyond infrastructure. Joining historical orders to current customer segments answers a different question from joining them to segments recorded at purchase time. A shared SQL interface cannot settle that business definition.

Writes need equally careful treatment. The MySQL connector supports querying and creating tables, but its documented unsupported operations include UPDATE and DELETE. Presto is therefore neither universally read-only nor a generic CRUD layer.

The PostgreSQL connector similarly lists unsupported statements, including UPDATE and DELETE. Each configured instance accesses one database, so multiple databases require separate catalogs. Source types also undergo mapping to Presto types.

My practical recommendation is to review the operations your pipeline needs, not just whether the connector can run a SELECT. That prevents an attractive reporting prototype from being mistaken for a complete application-data integration.

The same rule applies to Presto vs Trino. I recommend comparing the precise sources and query patterns involved rather than assuming similarly positioned engines are interchangeable. Connector compatibility deserves its own acceptance criteria, separate from speed.

Performance and Workload Management

Presto gives operators tools to manage analytical workloads, but those tools do not establish a universal response time. I consider predictable sharing of resources more useful than an unsupported claim that every query will be fast.

Resource groups provide memory, CPU, concurrency, and queue controls. When capacity is exhausted, new work generally queues; once maxQueued is reached, additional queries are rejected.

For a shared reporting service, I recommend distinguishing workload classes:

• Interactive reporting: Keep its queue policy aligned with how long people can reasonably wait.
• Scheduled reporting: Account for overlapping refresh windows rather than sizing from one isolated query.
• Exploratory work: Contain expensive investigations so they do not consume the entire shared allocation.

These are operating choices, not subscription limits. They also make expectations visible: a queued query is not necessarily a broken query, while a rejected query needs a clear explanation.

File-based resource group definitions use JSON and require a restart for changes. Database-backed definitions support updates without restarting. I like the simpler file route for a stable initial policy, but frequent changes can justify the additional configuration store.

For Java worker execution, memory limits can cause queries to fail. Spill-to-disk can move supported intermediate operations to storage, at the cost of additional I/O. It does not guarantee that every memory-heavy query completes.

My recommendation is to investigate the query shape before treating spill or more hardware as the answer. An unnecessarily broad join remains an expensive reporting design even if the cluster eventually completes it.

Presto C++, also called Prestissimo, is a separate execution choice. It uses Velox-based C++ workers with a Java coordinator, and those workers do not require JVMs.

I do not recommend treating native workers as an automatic upgrade. The native documentation describes active development and a restricted connector set. Its Iceberg support is documented as read-only for V1/V2 tables with positional deletes, without equality-delete support. That limitation is specific to C++, not a blanket description of Presto’s Iceberg connector.

Native execution also has function, type, plugin, and configuration differences. A migration is consequently a compatibility project, not merely a runtime switch.

For local analytical work, I prefer considering DuckDB before accepting these distributed-system responsibilities. Distribution should solve a workload problem. It should not be the default answer to every SQL task.

Security and Administration

Presto’s most consequential security detail is easy to overlook: the default built-in system access-control plugin is allow-all. That is a configuration default, not evidence that every deployed cluster is insecure.

I recommend treating production authorization as a prerequisite for connecting sensitive data. A successful login does not establish what the logged-in user should be allowed to query.

The security responsibilities are distinct:

• Authentication: Establish who is accessing the coordinator.
• Transport protection: Protect connections with appropriately configured TLS.
• Authorization: Define allowed actions and data access.
• Source permissions: Restrict what connector credentials can reach underneath Presto.

The documented Kerberos, LDAP, and password-file authentication routes require HTTPS access to the coordinator. That includes certificate-related configuration, not simply selecting an authentication option.

Built-in authorization alternatives include read-only and file-based control. System authorization runs before connector authorization. I like having those layers, but their existence does not substitute for a coherent policy across the service and its sources.

For example, an analyst may need access to aggregated sales without unrestricted access to customer records. The operational question is not just whether Presto accepts the query. It is whether the entire access path enforces the intended boundary.

My preferred ownership arrangement is explicit: one team owns service configuration, while source owners approve the access granted through each connection. Ambiguous responsibility becomes especially risky when a convenient shared credential reaches more data than its users should see.

Administration also extends beyond permissions. Larger deployments can dedicate coordinator resources, and disaggregated coordination supports multiple coordinators with resource managers. The availability design therefore depends on the chosen topology.

Those choices still require engineering judgment. Presto supplies configuration mechanisms; it does not turn an installation into a managed availability commitment or a compliance certification.

How Does Presto Compare to Competitors?

I recommend choosing the operating model before debating unmeasured speed differences. These alternatives address overlapping analytical needs, but they do not ask the same things of a team.

• Trino: My closest comparison for teams considering a distributed SQL service. Its documented fault-tolerant execution includes task retries backed by an exchange manager. That makes it worth evaluating for larger batch workloads where recovering failed work matters. External exchange storage, such as S3, also introduces configuration and infrastructure costs.
• Amazon Athena: My stronger starting point for AWS teams prioritizing less cluster administration. Its serverless model removes Presto-style cluster provisioning. Published on-demand SQL examples use $5 per TB scanned, with separate S3 and Glue charges potentially applying. That is an example pricing basis, not a universal rate across every mode or region.
• DuckDB: My first alternative for local or embedded analytics. It runs inside a host process, integrates with Python and R, and is MIT licensed. Its in-process architecture avoids the coordinator-and-worker service needed by Presto.

Product	Operating model	Buyer fit	Main consideration
PrestoDB	Self-managed distributed SQL	Shared cross-source analytics	Ownership and connector compatibility
Trino	Distributed SQL with configurable task retries	Teams evaluating batch resilience	Exchange storage and configuration
Athena	Serverless AWS analytics	AWS teams reducing cluster administration	Usage and related service costs
DuckDB	Embedded analytical database	Local and application-embedded analysis	Different architecture from a shared cluster

For an existing Presto deployment, I recommend migration only when it solves a concrete problem. For a new project, the shortlist should remain open until its critical queries and operational requirements point toward one model. Familiarity alone is not enough, but neither is novelty.

How I Reviewed Presto

I evaluated Presto through documented architecture and connector specifications, with particular attention to ownership costs and production boundaries. This is a document-based capability review.

My judgments connect those specifications to buyer decisions: whether federation justifies another service, who owns security, and which compatibility limits could disrupt adoption. Competitor comparisons concern operating models rather than measured speed.

Licensing and pricing information is current as of October 2026. Deployment-dependent costs are presented as budget components, not invented monthly estimates.

Should You Choose Presto?

I recommend Presto when a team needs a shared SQL layer across existing sources and has the engineering capacity to own it. Its value is the combination of federation and operational control, not simply free software.

I recommend DuckDB for a solo analyst seeking a convenient local query tool, and Athena for an AWS team whose overriding goal is avoiding cluster administration.

For an established Presto team, retaining the service can be sensible if its connector support and workload controls meet requirements. For a new deployment, my deciding question is simple: who owns the service after launch? A clear answer makes Presto much easier to recommend.

Frequently Asked Questions

Is Presto free?

Yes. The open-source core is Apache 2.0 licensed without a software subscription charge. Running it still consumes infrastructure and engineering time. I recommend budgeting those costs before comparing it with a managed service.

What is the difference between Presto and Trino?

They are separate distributed SQL projects that deserve separate compatibility evaluations. Trino documents configurable task retries with exchange storage. I recommend comparing required connectors and failure-recovery needs rather than assuming either engine is universally faster.

Is Presto a database or a query engine?

Presto is a distributed SQL query engine for analytics, aggregation, and reporting. It queries connected sources rather than replacing an OLTP application database. I see it as an analytical access layer, not a complete storage platform.

Can Presto support AI data workflows?

Presto can supply SQL-based joins and aggregations used in preparing data for downstream AI workflows. That does not make it an AI assistant or model-training platform. I recommend assessing it for the data-access task itself, separately from whatever trains or serves the model.