1.3 Combining Data: Data Blending vs. Cross-Database Joins

1.3 Combining Data: Data Blending vs. Cross-Database Joins

Tableau can combine data at different stages of the analytical pipeline. The important distinction is whether records become part of one data source before the view is aggregated or whether already aggregated results from separate data sources are combined for a worksheet.

Cross-database joins

A cross-database join places tables from supported connections inside one Tableau data source and joins them in the physical layer. The join operates at row level before the measures in the view are aggregated. This permits row-level calculations across the joined fields and supports inner, left, right, or full outer joins where the connectors allow them.

The usual risks of physical joins still apply. A one-to-many or many-to-many match can duplicate measures. An inner join can remove unmatched rows. A left join retains every left row but introduces nulls for unmatched right rows. Verify row counts and key totals before and after the join, and use relationships instead when tables have different grains and should retain their own level of detail.

Cross-database support depends on the connector and topology. Tableau may move data between systems or use local resources to complete a federated query, so large joins can incur transfer and compute costs. Prefer a governed warehouse model when the combination is broadly reused or too large for practical federation.

Data blending

Data blending keeps separate data sources. The first field placed in a worksheet establishes the primary source, marked with a blue check. A secondary source is marked with an orange check. Tableau queries each source and links the secondary result to the primary result through one or more fields, shown by active link icons. The primary source determines the domain of marks, so blending behaves conceptually like a left-side combination: secondary values with no matching primary mark do not create new marks by themselves.

Blending occurs after aggregation. That makes it useful when the sources cannot be joined directly, when a cube or another constrained source is involved, or when a small secondary source supplies targets at a different grain. It also creates important restrictions. Secondary fields are aggregated in the view, linking fields must have compatible data types and comparable values, and null or differently formatted keys do not match.

An asterisk produced by ATTR indicates that more than one secondary dimension value contributes to a primary mark. It is a grain diagnostic, not a literal value. Add the necessary linking field to the view, correct the relationship between grains, or aggregate to the intended level rather than replacing the asterisk with an arbitrary label.

Non-additive aggregates in a blend

COUNTD and MEDIAN from a secondary source are not categorically forbidden. Tableau can support these non-additive aggregates when the view includes the primary linking field and does not also use a nonaggregated secondary dimension that makes the required level ambiguous. If Tableau reports that a field cannot be used, expose the active linking field in the primary view, remove incompatible secondary detail, or reconsider which source should be primary. Treat the precise fields and grain in the scenario as decisive.

Published data sources

Older guidance often states that two published data sources must always be blended. Current Tableau 2026.2 capabilities allow authors to relate supported published data sources to one another and publish the resulting composite source when permissions and connector conditions are met. Blending remains available and may still be required for unsupported combinations or view-specific comparisons. When answering a version-neutral scenario, inspect whether it explicitly describes separate primary and secondary sources, link icons, or a supported composed data source.

Choosing the method

Example: sales and targets

Sales contains one row per order, while Targets contains one row per region and month. A physical join on Region alone repeats each monthly target for every matching order and inflates SUM(Target). A relationship on Region and Month keeps both grains and is usually the cleanest single-source design. A blend can also work: make Sales primary, link Region and Month, and aggregate Target in the view. If a region exists only in Targets, it will not appear until Targets becomes primary or a row-level model preserves it.

Validation checklist

Before approving a combination, state the grain of every table, confirm link or join field types, inspect unmatched keys, compare row counts, and reconcile an additive control total. Then test a dimension from each source, a non-additive aggregate, and the filters the final view will use. Correct output is more important than choosing the feature with the shortest setup time.