Tier 2 · Core SQL

Joining Multiple Tables in SQL

By Owen Middleton · Updated September 2026 · Examples run on PostgreSQL 17

How do you join multiple tables in SQL?

You can chain as many JOINs as you need in a single query, adding one table at a time.

Most reporting queries need more than two tables. A full order report needs customer names, product names, quantities, and order totals — each piece of data in a different table. You add one JOIN per table, each with its own ON clause. Each new table connects to something already in the query: to the driving table, or to a table you already joined.

How do you join three tables in one SQL query?

The approach scales to as many tables as you need. Here is what three tables joined together looks like: orders, customers, and order line items in one query:

SELECT o.id AS order_id, c.name AS customer_name, oi.quantity
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id

The first JOIN connects orders to customers via customer_id. The second JOIN connects orders to order_items via order_id. Each JOIN adds columns from a new table, and the query now has all three tables' data in each result row.

Add another JOIN to pull in product names:

SELECT o.id AS order_id, p.name AS product_name, oi.quantity, oi.unit_price
FROM orders o
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id

Here the second JOIN connects to order_items, not to orders — because order_items has the product_id foreign key. Each ON clause specifies which columns match between two tables already in the query.

Can you mix INNER JOIN and LEFT JOIN in one query?

You can mix JOIN types. Some tables in the chain may have nullable foreign keys. Categories might be missing for some products; use LEFT JOIN for those:

SELECT c.name AS customer_name, p.name AS product_name, cat.name AS category_name
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
LEFT JOIN categories cat ON p.category_id = cat.id

Products with no category still appear. Their category_name column is NULL. The three INNER JOINs before it ensure orders, customers, line items, and products are all matched; the LEFT JOIN only relaxes the constraint for categories.

What goes wrong when a JOIN ON clause is wrong?

The one thing that trips people up: getting the ON clauses wrong.

Each JOIN's ON clause must connect a column from the new table to a column from a table already in the query. A common mistake is connecting two tables that don't share a direct relationship — JOIN products p ON p.id = c.id accidentally matches product IDs to customer IDs. Check your foreign key relationships before writing the ON clause, and verify that the row counts in the result look reasonable before relying on the output.

Practice Joining Multiple Tables in SQL

Practice · easy ecommerce · Brightlane

Brightlane's sales team needs a line-item report showing each order alongside the customer who placed it and the quantity of each item in that order.

Write a query to return the order ID, customer name, and quantity for every order line.

Assumptions:

  • The result row count is one row per order line item (not one row per order).

Output:

  • One row per order line, with columns order_id, customer_name, and quantity.
Schema · ecommerce5 tables? = nullable
categories
idinteger
nametext
parent_id?integer
products
idinteger
nametext
category_id?integer
pricenumeric
stock_qtyinteger
attributes?jsonb
order_items
idinteger
order_id?integer
product_id?integer
quantityinteger
unit_pricenumeric
customers
idinteger
nametext
emailtext
city?text
countrytext
created_attimestamptz
is_activeboolean
orders
idinteger
customer_id?integer
ordered_attimestamptz
statustext
total_amountnumeric

Run previews · Check grades

Write a query, then run it to see results here.

Worked solution

The full breakdown walks through the shape, each clause, why this approach beats the alternatives, and the trap to avoid.

See the full worked solution

9 Joining Multiple Tables practice problems

Start learning to practice all 9 Joining Multiple Tables problems, with instant grading and mastery tracking.

Common questions about Joining Multiple Tables

Does the order you write the JOINs in change the result?

Not for inner joins, which return the same rows whichever order you chain them in. The order matters for readability, and it matters a great deal once outer joins are involved, because a LEFT JOIN placed after a filter behaves differently from one placed before it.

Does each JOIN have to connect back to the first table?

No. Each ON clause has to reference something already in the query, which can be any table joined so far. Line items attach to orders and products attach to line items, so the chain reaches products without products ever naming orders.

How do you know a multi-table join is correct?

Count the rows before you aggregate anything. If joining to a second table multiplies the row count, any total computed over that result is inflated, and the number will look plausible while being wrong. Check the count first and the totals afterwards.

How you actually get good at SQL

Reading explains SQL. Writing it, over and over with instant feedback, is what makes you fluent.

That's the whole SQLMaxx loop: 600+ real problems, instant AI feedback, mastery you can actually see, and spaced review that won't let you forget.

A stack of SQL practice problem cards, the top card showing an employees table.
615 problems · 66 concepts

Real problems. Not toy examples.

615 hand-built problems spanning all 66 concepts, from basic SELECTs to window functions, built on real schemas and real business questions, the kind you'll actually get asked on the job. Enough reps to make SQL automatic.

A retro computer showing a SQL query marked correct with a green checkmark.
Instant AI feedback

Write a query. Know if it's right in one second.

No copying an answer and hoping it clicked. The AI grader checks your real query against real data, catches exactly what's wrong, and explains the fix in plain English, like a senior analyst reading over your shoulder on every problem.

A circular mastery progress dial filling from blue to green, the SQLMaxx diamond at its center.
Mastery tracking

Stop guessing whether you actually know it.

SQLMaxx tracks every concept and shows you what you've mastered and what's still shaky. Your skills fill in one concept at a time, so 'I think I get joins' becomes something you can prove.

A SQL query editor circled by a blue return arrow with a clock, scheduled to come back for review.
Spaced review

Learn it once. Keep it for good.

Most of what you learn this week fades by next week. So when a concept comes due for review, SQLMaxx hands you a fresh problem to solve from a blank editor, not a flashcard to re-read. A research-backed spaced-repetition algorithm (FSRS) times each return for right before you'd forget, so your SQL is still there months later, when the interview or the job actually needs it.