In Tableau, where does a cross-database join between a warehouse table and a CSV execute?

## What federation means here A normal join happens inside one connection: Tableau writes SQL containing the join and the database executes it. A **cross-database join** spans two connections — a warehouse and a spreadsheet, two different databases, a database and a cloud file — and no single source can execute it, because neither one holds both tables. Tableau resolves this by acting as a federated query engine. It plans the overall query, decomposes it into one query per connection, executes those queries against their respective sources, and combines the returned results in its own engine. That engine runs wherever the query is running: in Tableau Desktop's process on your machine, or on the Tableau Server or Cloud node serving the view. ## What gets pushed down and what does not Tableau pushes what it can into each source's own query — projections, filters that apply to that source's columns, and aggregation where it is safe to do so. That is what keeps a cross-database join viable at all: you want the warehouse to do the heavy reduction before anything crosses the network. What cannot be pushed down is the join itself, and any operation that depends on both sides. Those are performed locally on the intermediate results. ## Why the shape of your data matters so much Because intermediate results move across the network and are materialised locally, the cost of a cross-database join scales with how much data has to leave each source. The shape that works well is **one large governed table plus one small lookup**: a warehouse fact filtered down to what the view needs, joined to a few hundred rows of regional mapping from a spreadsheet. The shape that works badly is two large tables from two systems — you are asking a single Tableau process to do work that a distributed warehouse would spread across a cluster, and to pull the inputs over the network first. For this reason, cross-database data sources are very commonly **extracted**. Extracting materialises the joined result once into a `.hyper` file on a schedule, and every subsequent view queries that file instead of re-federating. You trade freshness for predictable performance, and for most cross-source lookups that is the right trade. ## What cannot participate Not every connection is eligible. The one that catches people out is a **published Tableau data source**: you cannot cross-database-join it to another connection. If the governed, certified source is published and you need to bring in something else, the mechanism available is **data blending**, which combines results in the view rather than joining rows. Some other connection types — notably multidimensional (cube) sources — likewise cannot take part in joins. Eligibility varies by connector and by version, so check rather than assume for anything unusual. ## Cross-database join, relationship, or blend? All three combine data, and they differ in where and when. A **join** merges rows before the view exists; a cross-database join is a join whose merge happens in Tableau's engine instead of a database's. A **relationship** in the logical layer keeps each table at its own grain and lets Tableau compose the right query per measure at query time; relationships can span connections in one data source too, and they carry the same federation cost when they do. A **blend** does not merge rows at all — it queries each source separately and combines *aggregates* in a single worksheet, which is why it is the fallback when a source cannot be joined. Choose the cross-database join when both connections are eligible and the volumes are asymmetric; choose blending when one side is a published data source or the grains differ and you want the secondary pre-aggregated; and consider whether the real answer is to load the small file into the warehouse so it becomes an ordinary same-connection join with no federation at all. ## The governance angle The reason cross-database joins exist is that analysts have data the warehouse does not: a targets spreadsheet, a manual mapping, a vendor extract. Making that easy is a feature. But a spreadsheet joined into a dashboard is now a production dependency living on someone's laptop or a shared drive, with no schema, no history and no owner. Treat a recurring cross-database join as a signal that the small side belongs in the warehouse, and use the join as the bridge until it gets there.