Cross-Database Queries Without Running a Presto or Trino Cluster

Presto was a genuine breakthrough. Engineers at Facebook built it because Hive was too slow, and the idea was elegant: define connectors to every data source, present them all as standard SQL tables, and push computation down to each source. One query engine to rule every data store in the company.

Trino (Presto's open-source successor) carries that vision forward. It has connectors for Postgres, MySQL, S3, Kafka, Elasticsearch, Cassandra, MongoDB, Delta Lake, Iceberg — practically everything. Netflix, LinkedIn, and Lyft run it at massive scale. The SQL dialect is clean. The architecture is proven.

So why am I writing a post about not using it?

Because most teams evaluating Trino aren't Netflix. They're a 15-person company with data in Postgres, Stripe, HubSpot, and maybe BigQuery. They want to join their users table with their payments table and their CRM contacts. That's a three-way join across three sources. It doesn't require a distributed query engine with a coordinator node, four workers, and a JVM heap tuned to 16GB.

What Trino costs you

The connector ecosystem and SQL engine are excellent. The operational tax is the problem.

A production Trino deployment means running a coordinator node that parses queries and plans execution, plus N worker nodes that actually process data. The coordinator is a single point of failure. The workers need enough memory to handle intermediate results, and JVM memory tuning in Trino is not optional — get it wrong and you'll spend a week chasing OutOfMemoryErrors and spill-to-disk performance cliffs.

Then there's connector configuration. Each source needs a catalog properties file. Postgres alone requires specifying the JDBC URL, connection pooling behavior, pushdown settings, case sensitivity handling. Multiply that by five sources and you have a configuration surface that needs an owner.

Monitoring is its own project. You need Trino's built-in web UI or a Prometheus/Grafana stack to watch query queuing, memory allocation per worker, split distribution, and connector health. When a query hangs, you're debugging distributed execution plans.

I've seen teams dedicate 1-2 engineers part-time just to keep Trino running. At organizations doing hundreds of concurrent queries across petabytes of data, that's a reasonable investment. At a 20-person company running 50 queries a day, it's an expensive way to join two tables.

When Trino is the right answer

Trino earns its complexity at a specific scale. If your workload hits several of these, you probably need it:

• Petabyte-scale joins across data lakes and warehouses
• Sub-second latency on federated queries with 100+ concurrent users
• Regulatory requirements that prevent data from leaving its source system
• A dedicated platform team that can own the cluster's lifecycle
• Complex query routing — different compute pools for ad-hoc vs. scheduled workloads

At that scale, Trino's pushdown architecture is a genuine advantage. Instead of pulling all data into one place, it pushes filter predicates and aggregations down to each source. A query that scans a billion-row Postgres table only transfers the matching rows. That's efficient when your data is enormous.

When Trino is overkill

Most cross-source query needs look nothing like the above. They look like this:

You have 3-5 data sources. Your largest table has a few million rows. Your team is 5-50 people. You need analytics, not production serving. And you want the answer this week, not after a two-month infrastructure project.

For this profile, the Trino approach is buying a semi truck to move a couch. The vehicle works — it can definitely move a couch — but the licensing, insurance, fuel, and parking aren't justified by the cargo.

The DuckDB alternative

DuckDB takes the opposite approach to distributed federation. Instead of pushing queries out to sources and coordinating results across workers, it pulls data from each source into a local columnar store and processes everything in a single engine.

On Fastero, that looks like this: you connect your sources — Postgres, BigQuery, Stripe, HubSpot, Shopify, whatever — and the platform syncs the tables you care about into a DuckDB data store. From there, you write standard SQL across all of them. No coordinator. No workers. No JVM. No connector configs.

SELECT
    u.email,
    u.created_at AS signup_date,
    s.amount / 100.0 AS total_paid,
    h.lifecycle_stage,
    h.last_activity_date
FROM postgres_users u
JOIN stripe_charges s ON u.stripe_customer_id = s.customer_id
LEFT JOIN hubspot_contacts h ON u.email = h.email
WHERE s.created > '2026-01-01'
  AND h.lifecycle_stage = 'customer'
ORDER BY total_paid DESC

That query joins a Postgres users table, Stripe charges, and HubSpot contacts. It runs in DuckDB's vectorized columnar engine — fast on analytical workloads, no tuning required. The data was synced from each source on a schedule you set.

Pushdown vs. pull: the real trade-off

The architectural difference between Trino and DuckDB isn't a minor detail — it determines when each tool is appropriate.

Trino pushes computation to sources. When you query a billion-row Postgres table with a WHERE clause, Trino sends that predicate to Postgres and only transfers the filtered rows. This is efficient when your source tables are huge and your filters are selective. The data never leaves its origin until it's been narrowed down.

DuckDB pulls data then processes locally. The sync step copies relevant tables into DuckDB's columnar format. Queries run entirely within DuckDB — no network round-trips during execution, no cross-source coordination, no distributed query plans to debug. The vectorized engine processes data in tight CPU-cache-friendly batches.

For moderate data volumes — millions of rows, not billions — the pull-then-process approach is simpler and often faster. You trade real-time freshness for predictable performance and zero operational complexity. A scheduled sync every hour or every day covers most analytics use cases.

For massive data volumes where you can't afford to copy everything, pushdown federation wins. That's Trino's territory.

Identity resolution across sources

Cross-source queries are only useful if you can match records across systems. Your Postgres database identifies users by user_id. Stripe uses customer_id. HubSpot uses email. Shopify uses shopify_customer_id. Same human, four different identifiers.

Fastero's DuckDB store includes identity resolution that maps these identifiers to a unified record. When you sync data from multiple sources, the platform matches records by email, customer ID, domain, or any field you configure. The result is a cross-source graph where a single entity resolves across all your systems.

This means your cross-source queries don't break when one system uses email and another uses an opaque ID. The identity layer handles the mapping, and your SQL stays clean.

Scheduled sync vs. real-time federation

Trino federates in real time — every query hits the live source data. DuckDB on Fastero works on synced snapshots. This is the most honest trade-off in the comparison.

If you need up-to-the-second freshness across sources — a stock trading dashboard, a real-time fraud detection system, a live operational view with SLA requirements — Trino's real-time federation is the right model. Synced snapshots won't cut it.

But most analytics workloads don't need real-time. Marketing attribution doesn't change minute-by-minute. Revenue reconciliation runs daily. Churn analysis looks at 30-day windows. For these use cases, a sync that runs every hour (or every 15 minutes, or daily) gives you fresh-enough data without the operational burden of maintaining a live federation layer.

Scheduled sync is also predictable. You know exactly when the data was last updated, how long the sync took, and whether it succeeded. With real-time federation, a slow source can bottleneck every query that touches it — and you may not notice until someone complains that their dashboard is timing out.

Skip the SQL entirely

Not everyone joining this data writes SQL. Fastero's AI agent understands the schemas across all synced sources. Ask it:

"Which customers are paying us through Stripe but show as 'lost' in HubSpot?"

The agent writes the cross-source query, runs it against the DuckDB store, and returns the result. If you want it on a dashboard, it builds the widget. The query is visible and editable — your analyst can refine it, and nobody had to configure a Trino connector to make it happen.

The honest split

If you need real-time federated queries across petabytes of data with hundreds of concurrent users and a platform team to operate it, use Trino. It's battle-tested at that scale and nothing else comes close.

If you need to join 3-5 sources, build dashboards for your team, and you'd rather spend your engineering hours on product instead of infrastructure, DuckDB-based cross-source querying gets you there without the cluster.

The question isn't which engine is better. It's which operational model fits your team. Running a Trino cluster is a commitment — ongoing, non-trivial, and expensive in engineer-hours even when the software is free. Syncing sources into DuckDB and querying locally is a task, not a project.

For more on the cross-source dashboard workflow, see Connect Multiple Databases to One Dashboard (Without a Warehouse). For the DuckDB engine deep dive, see DuckDB for Analytics Dashboards: From Local to Shared.

Try Fastero free — connect your sources, query across all of them with SQL, and build dashboards without running a Trino cluster. No credit card required.