Skip to main content
A merge query puts two or more explores side by side in one result. You pick the fields you want from each explore, say which field lines them up, and run. The merged result behaves like any other chart: you can configure it, save it, add it to dashboards, schedule it, and filter it from a dashboard. Use it when a question spans two explores that share a field at the same grain, such as review sentiment next to return rates for the same product, or orders next to payments for the same month.
Screen recording of adding a second explore to a query, choosing the join field and running the merged query

Merging Orders with Payments by month, from an explore to merged results

​
Before you start

Each source of a merge is a normal explore query with its own metrics, dimensions and filters. All explores must be in the same project, and the same explore can be used more than once. You need:
  • A shared field. A dimension that exists in every source with matching values, such as a product code or a month. This becomes the join key. A merge can join on more than one field.
  • Matching grain. Every dimension you select from a source must be one of the join keys. This keeps each source to one row per key, so the join never multiplies rows. See how the join stays honest.
Anyone who can run queries in the explore can merge. There is nothing to install and no change to your dbt project. AI agents can’t build a merge or change what one runs, and dashboards they generate leave out merged charts. On a saved merged chart, an agent can change only its name, description, chart, table and pivot settings, field formatting and space.

​
Merge two explores

1

Build the first side as usual

Open an explore and pick the fields you want from it. Filters you add here apply to this side only.
The Orders explore with Order date month and Total order amount selectedThe Orders explore with Order date month and Total order amount selected
2

Choose Merge another query

Open the query options menu, the ··· button next to the explore name at the top of the field panel, and choose Merge another query.
The query options menu with the Merge another query itemThe query options menu with the Merge another query item
3

Choose the second explore

The field panel switches to a Data sources view. Your first explore is listed with its selected fields, and a new card asks you to choose data to combine. Search the table list and pick the second explore.
The Data sources panel listing Orders and a Choose data to combine card above a searchable table listThe Data sources panel listing Orders and a Choose data to combine card above a searchable table list
4

Pick fields from the second side

You see the second explore’s field tree. Add at least one metric. The Relationship card tells you what is still missing.
Payments chosen as the second source, with the Relationship card asking for at least one metric from PaymentsPayments chosen as the second source, with the Relationship card asking for at least one metric from Payments
5

Set the join field on each side

In the Relationship card, each side has a field picker that offers dimensions only. The first side is prefilled with the dimension you already selected. Choose the matching field on the second side. Use Add join condition when the sides match on more than one field.
The Payments join field picker open, offering Order date monthThe Payments join field picker open, offering Order date month
6

Add more sources (optional)

To merge a third explore or more, choose Add source and repeat the previous two steps for it. Every source maps to the same join key, and one join type applies to the whole merge.
7

Choose the join type

The summary next to Relationship reads the join back in words. The default is All rows. See which join type to choose.
The Relationship card with both join fields set to Order date month and the Left join type selectedThe Relationship card with both join fields set to Order date month and the Left join type selected
8

Run the query

Results arrive as one table. The join key has a key icon, and every other column carries the name of the explore it came from. Configure the chart the way you would for any explore. Table calculations added to a merged result can reference fields from every source and have the usual format options. Drill-down and underlying data on a merged column open the source explore that column came from.
Merged results with Order date month, Total order amount from Orders and Unique payment count from PaymentsMerged results with Order date month, Total order amount from Orders and Unique payment count from Payments
9

Save the chart

Save chart works as it does for any chart. The saved chart shows the relationship at the top and can be added to dashboards and scheduled deliveries.
A saved merged chart with a header reading Orders + Payments, matched on Order date monthA saved merged chart with a header reading Orders + Payments, matched on Order date month

​
Which join type to choose

The three options answer one question: when a key exists in only some sources, what happens to it?

​
How the join stays honest

A merge is only safe when each source has exactly one row per join key. Because an explore query groups by its dimensions, that comes down to one rule: every dimension you select in a source must be a join key. Metrics are already one value per key, so any number of them is fine. When a selection breaks the rule, the query refuses with a message rather than multiplying rows. Either add that dimension as another join condition in every source, or remove it. For example, reviews by product merged with returns by product, joined on product, works. Reviews by product and month merged with returns by product, joined on product only, refuses, because the review side has many rows per product. Add month to both sides and to the join conditions and it works again.

​
Repeat values

Sometimes the extra rows are what you want, such as a product’s return rate shown on every month of its reviews. The refusal message offers to repeat the other sources’ values on every row of the finer-grained source. Their values then appear once per matching row, and their columns have no totals, because a sum would count each value once per repeat. Only one source can keep dimensions that are not join keys. Choose Stop repeating to go back.

​
Filters

Filters on a source apply to that source before the join. A dashboard filter on a merged chart is pushed into every source that has the field, so a date filter narrows every explore rather than only the merged output. A dashboard filter on a column that exists only in the merged result, such as a merge table calculation, is refused, because merges have no filter step after the join.

​
How a merge runs

A merge runs in two stages. Each source runs as its own query against your warehouse, with that source’s filters and row limit. Lightdash then joins the results in its own query engine, so the join needs no relationship in your dbt project and behaves the same on every warehouse. The SQL view of a merged chart shows both stages. You can run each source’s SQL in the SQL Runner, but not the final merge step: it reads the source results as merge_source_0, merge_source_1, and so on, and those tables exist only inside Lightdash, not in your warehouse.

​
Current limits