Federated Compute vs. Centralised Warehouse: A Decision Framework From Someone Who Built Both

Trino on EMR and Redshift solve different problems. Here is how to know which one you actually need.

There is a pattern I have seen repeat itself across data teams of every size.

Someone reads about federated compute or discovers Trino, gets excited about Zero-ETL, and starts planning a migration away from their data warehouse. A few months later they have a half-migrated system that is slower, harder to operate, and costs more than what they left behind.

The opposite happens too. Teams stay loyal to a centralised warehouse long past the point where it can handle their workload, adding nodes and paying RA3 prices for a system that is fundamentally the wrong shape for what they need.

I have been on both sides of this. I ran a large-scale Redshift warehouse managing petabytes of finance data, hit its limits hard, and built a federated compute layer on Trino and EMR to replace parts of it. I have also seen cases where Redshift was exactly the right answer and someone was about to abandon it for the wrong reasons.

This article is the decision framework I wish I had before we started.

What the two architectures actually are

Before comparing them, it helps to be precise about what each one does — because the marketing descriptions for both are misleading.

A centralised warehouse (Redshift) is a system where compute and storage are tightly coupled. Your data lives inside the warehouse. When you query it, the warehouse retrieves it from its own storage. The engine knows exactly where everything is, can optimise aggressively, and delivers very consistent, predictable performance. The cost of that predictability is that you scale storage and compute together — you cannot have one without the other.

Federated compute (Trino on EMR) is a system where compute and storage are fully decoupled. The engine — a Coordinator node plus a fleet of Workers — stores nothing. When a query arrives, the Coordinator breaks it into splits, Workers pull data from wherever it lives (S3, Redshift, a data lake, another database), perform joins and aggregations in memory, and return the result. The data never moves to a central location. Workers scale independently of storage, and you only pay for compute during active processing.

The fundamental difference is not speed or cost. It is the relationship between compute and storage. Everything else follows from that.

Where each one wins

Redshift wins when your workload is predictable and your data is yours

Centralised warehouses are optimised for a specific shape of work: known schemas, stable query patterns, data that belongs to the warehouse. When your workload fits that shape, Redshift is genuinely excellent.

Highly concurrent, latency-sensitive queries. Redshift keeps data close to compute. There is no network hop to S3, no connector overhead, no Coordinator-Worker coordination for simple queries. If you have hundreds of analysts running dashboard queries simultaneously against well-structured tables, Redshift handles that workload with consistent sub-second latency in ways that a Trino cluster will struggle to match at the same concurrency.

Complex aggregations over a single, well-defined dataset. When all your data is in the warehouse and the query is expensive — multi-billion row aggregations, heavy window functions, complex GROUP BYs — Redshift’s columnar storage and zone maps give it a significant advantage. It knows exactly which blocks to skip.

Teams without deep infrastructure expertise. Redshift is a managed service. AWS handles the cluster, the backups, the upgrades. Operating a Trino cluster on EMR requires JVM tuning, memory configuration, connector management, Spot instance fault-tolerance setup, and ongoing performance profiling. That operational overhead is real and should be factored into the decision.

Finance and compliance workloads with strict audit requirements. When data must not leave a specific boundary, a centralised warehouse with well-understood access controls is easier to audit than a federated engine querying across accounts and systems.

Federated compute wins when your data is scattered and your workload is asymmetric

The case for Trino on EMR is strongest when either of two conditions holds: your data lives in multiple places that you cannot or should not consolidate, or your compute needs are spiky and asymmetric.

Data that lives across heterogeneous systems. Before we built the federated layer, data scientists and BI engineers spent days writing ETL pipelines just to join a Redshift table with an S3 data lake. With Trino, that join happens in memory in seconds using standard SQL. No data movement. No pipeline to maintain. No duplication. If your organisation has data in multiple warehouses, lakes, and external databases, a federated engine eliminates an entire class of engineering work.

Spiky batch workloads that run for a fixed window. The finance data processing we ran needed 200–400 nodes for 10–12 hours, then nothing for the rest of the day. On Redshift, you pay for those nodes 24 hours a day whether they are doing work or not. On EMR, you pay for compute hours — the cluster scales up, does the work, and scales down. For workloads with a clear on/off pattern, the cost difference is substantial. We cut hardware costs by roughly 30% on compute-heavy workloads by moving to Spot instances with fault-tolerant execution.

Cross-account and cross-system analytics. If your data governance model keeps data in separate AWS accounts — different business units, different compliance domains — a federated engine can query across accounts via cross-account IAM roles and VPC peering without copying data across boundaries. This is architecturally cleaner than trying to centralise everything into one warehouse.

Teams that need Zero-ETL self-service. When data scientists need to join datasets across systems for exploration, forcing them through ETL pipelines creates weeks of latency. Federated compute gives them direct SQL access to data where it lives, from Jupyter notebooks or SQL IDEs, without submitting engineering requests. We saw this eliminate days of turnaround time for exploratory analysis.

The honest trade-offs

Every comparison article lists the wins. Here are the things that do not get mentioned as often.

Trino’s Redshift connector is single-threaded. When you join a Redshift table with an S3 dataset using Trino, the initial pull from Redshift is single-threaded via JDBC. You cannot distribute that fetch across Worker nodes — only the subsequent join and aggregation is parallelised. For queries that pull large volumes from Redshift, this is a real bottleneck that JVM tuning will not fix.

In-memory joins at petabyte scale require careful memory management. When Workers pull data from multiple sources and join it in memory, OOM errors are a genuine risk on large queries. We spent significant time configuring G1GC garbage collection, setting strict query.max-memory-per-node limits, and tuning spill-to-disk behaviour. This does not happen with a managed warehouse.

Federated performance is unpredictable compared to centralised. Redshift’s query planner knows exactly where your data is and how it is structured. Trino’s planner is working with metadata from Glue and statistics from remote systems — its estimates are less reliable, especially for cross-system joins. You will see more query plan variability and more surprises at the tail of the latency distribution.

Redshift does not scale asymmetrically. This is the mirror of Trino’s advantage. If your workload is constant and high-throughput, Redshift’s always-on model is efficient. The problem is when it becomes saturated — a 16-node cluster running 16–17 hours of daily processing has no room for concurrent ad-hoc queries, historical backfills, or anything else. You either add nodes (expensive) or queue everything (slow).

Operating Trino on EMR has a real engineering cost. Coordinator-Worker topology, JVM heap configuration, Alluxio file system caching for S3 throttling, fault-tolerant execution for Spot instance recovery, cross-account IAM role management, connector configuration for each data source. None of this is hard, but all of it is work. A small team without someone who has done it before will spend months getting it right.

The decision framework

Based on what I have seen, these are the questions worth asking in order.

Is your data in one place or many? If everything is in Redshift and that is where it should stay, a federated engine adds complexity without benefit. If your data is spread across data lakes, warehouses, and external systems that cannot be consolidated, federated is almost always the right answer.

Is your compute need constant or spiky? Constant high-throughput workloads favour Redshift’s always-on model. Batch-heavy workloads with clear processing windows favour EMR’s pay-per-hour model.

What does your concurrency pattern look like? Many concurrent short queries from analysts favour Redshift. Fewer, longer, more complex queries from data engineers and scientists favour Trino.

What is your team’s infrastructure tolerance? If your team’s strength is data modelling and business logic, not JVM tuning and cluster operations, the operational overhead of Trino on EMR is a real cost. Redshift Serverless or a managed warehouse removes that from the equation.

Do you have cross-account or cross-system access requirements? If yes, federated compute becomes significantly more attractive — it is architecturally designed for this pattern in a way that ETL-and-centralise is not.

What we actually did, and why

We ran both simultaneously, which is the answer nobody wants to hear but which was correct for our situation.

Redshift remained the right answer for high-concurrency reporting workloads — the dashboards that hundreds of analysts hit every morning, the latency-sensitive queries where consistent sub-second response mattered.

Trino on EMR replaced Redshift for the batch-heavy finance processing workloads where we needed 200–400 nodes for a defined window, then nothing. The elastic scaling alone justified the operational overhead. We also used the federated layer to eliminate the ETL pipelines that data scientists were maintaining just to join datasets across systems — that was a Zero-ETL win that improved productivity significantly.

The result was not a clean migration from one to the other. It was a deliberate split based on workload type — and the split was the right engineering decision even though it added architectural complexity.

A note on what this comparison does not cover

Snowflake is the obvious third option in this space and deserves its own article. It offers compute-storage separation with significantly less operational overhead than Trino on EMR, at a higher per-query cost. If the choice were purely between Redshift and Snowflake, the decision framework would look different.

Athena is relevant for serverless, infrequent querying against S3 — it handles cases that neither Redshift nor an always-on Trino cluster is cost-effective for.

The right answer for most large organisations is a combination, with different workloads routed to the engine that fits them.

Summary

Choose Redshift (or a centralised warehouse) when:

• All your data already lives there and should stay there
• You need high-concurrency, low-latency query performance
• Your workload is constant rather than spiky
• Your team’s strength is analytics, not infrastructure operations
• Auditability and access control simplicity are priorities

Choose Trino on EMR (or federated compute) when:

• Your data is spread across heterogeneous systems that cannot be consolidated
• Your compute needs are asymmetric — large batches with idle periods between them
• You need Zero-ETL access across data lakes, warehouses, and external databases
• Cross-account querying is a requirement
• You have the infrastructure expertise to operate and tune a distributed engine

The question is not which architecture is better. It is which one fits the shape of your actual workload.

Senior Data Engineer with 19+ years of experience building enterprise-scale data platforms. Writing about real architecture decisions, trade-offs and the numbers behind them. Connect on LinkedIn.