How to write SQL cross joins and why they are so dangerous

How to write SQL CROSS JOINs and why they are so dangerous

Structured Query Language (SQL) provides several types of joins to combine data from multiple tables. Among these, the CROSS JOIN is arguably the most misunderstood and the most dangerous when used without caution.

Learn SQL online

For our instructor lead, more in depth look at learning to write a SQL SELECT, SORT BY and WHERE clauses why not check out our video course hosted on UDEMY or enjoy the free SQL course below.

In this article, we’ll explore:

  • What a CROSS JOIN is and how it works

  • How to write and interpret CROSS JOINs

  • Real-world examples with output

  • Why CROSS JOINs can be hazardous in practice

  • When it’s appropriate to use a CROSS JOIN

  • Best practices to avoid costly mistakes

Let’s dive into the world of Cartesian products in SQL.

What is a SQL CROSS JOIN?

A CROSS JOIN returns the Cartesian product of two tables. This means:

Every row from the first table is paired with every row from the second table, without any condition filtering the join.

Think of it as forming all possible combinations of the rows from both tables. It’s a brute-force operation and can scale in size very quickly.

Mathematical Definition

If:

  • Table A has m rows

  • Table B has n rows

Then:

  • The result of A CROSS JOIN B will have m × n rows.

This is computationally expensive and should only be done intentionally.

How to Write a CROSS JOIN

There are two syntaxes you can use to write a CROSS JOIN:

Explicit CROSS JOIN

				
					SELECT *
FROM table_a
CROSS JOIN table_b;
				
			

This form is clear and communicates the intent unambiguously.

Implicit CROSS JOIN (Comma Syntax)

 
 
				
					SELECT *
FROM table_a, table_b;
				
			

This older, comma-separated form of join syntax is functionally identical to a CROSS JOIN if no WHERE clause is provided. Unfortunately, this is where many accidental CROSS JOINs come from, especially when join conditions are forgotten.

Example: CROSS JOIN in Action

Let’s use two simple tables to demonstrate:

Table: Colors

idcolor
1Red
2Green
3Blue

Table: Sizes

idsize
ASmall
BMedium
CLarge

Now let’s run a CROSS JOIN between colors and sizes.

Query:

				
					SELECT c.color, s.size
FROM colors c
CROSS JOIN sizes s;
				
			

Output:

colorsize
RedSmall
RedMedium
RedLarge
GreenSmall
GreenMedium
GreenLarge
BlueSmall
BlueMedium
BlueLarge

This result includes every combination of color and size: 3 colors × 3 sizes = 9 rows.


Why CROSS JOINs Are Dangerous

Despite their simplicity, CROSS JOINs are one of the most dangerous tools in SQL. Here’s why.

Explosive Row Multiplication

CROSS JOINs scale multiplicatively. This might not be a problem with 3 or 4 rows, but in real-world systems, it can explode quickly.

Imagine joining:

  • 100,000 customers

  • 5,000 products

A CROSS JOIN here would produce:

100,000 × 5,000 = 500,000,000 rows.

If your database tries to materialize that in memory, you could:

  • Crash the query engine

  • Exhaust server memory

  • Cause serious performance degradation

They’re Easy to Write by Accident

Here’s a classic mistake:

				
					SELECT *
FROM employees, departments;
				
			

If the developer forgets to include a join condition (like ON employees.department_id = departments.id), this query becomes a CROSS JOIN, pairing every employee with every department. In large organizations, this mistake could create millions of unnecessary rows.

Hard to Debug and Understand

CROSS JOINs produce a lot of noise. Unless you specifically need a full pairing, the result set often contains meaningless or invalid combinations that pollute the data and confuse users.

Even worse, because the syntax of a CROSS JOIN can look like a regular join (especially in the implicit form), it may take a while before anyone notices something is wrong.

When to Use CROSS JOINs Intentionally

While most use cases don’t require a CROSS JOIN, there are some legitimate scenarios where it is the right tool.

Generating All Combinations

If you’re building a product catalog, testing system, or grid of all possibilities, CROSS JOIN is perfect.

Example:

				
					SELECT c.color, s.size
FROM colors c
CROSS JOIN sizes s;
				
			

his gives all combinations of colors and sizes, great for inventory planning or UI dropdown generation.

Creating Time/Slot Grids

Suppose you’re building a scheduling app where each day should offer multiple time slots.

Example:

				
					SELECT d.date, t.slot
FROM calendar_days d
CROSS JOIN time_slots t;
				
			

This gives every day/slot combination for a calendar view.

Synthetic Data Generation

Need to populate a table with test data or simulate a data environment?

CROSS JOIN can create combinations that simulate realistic workloads.

Example:

				
					SELECT users.name, test_cases.id
FROM users
CROSS JOIN test_cases;
				
			

Another useful operator is BETWEEN, which is great for checking if a value falls within a certain range. For instance, if you’re interested in employees who were hired between 2016 and 2019, you might write:

				
					SELECT *
FROM employees
WHERE hire_date BETWEEN '2016-01-01' AND '2019-12-31';
				
			

Now every user is assigned every test case—useful for load testing or algorithm trials.

Best Practices to Avoid CROSS JOIN Pitfalls

  1. Always Use Explicit JOINs
    Use INNER JOIN, LEFT JOIN, etc., with ON conditions to make join logic clear.

  2. Avoid Comma-Separated FROM Clauses
    Especially in legacy code or older SQL tutorials.

  3. Add LIMIT Clauses in Development
    While testing, always use LIMIT 10 or similar to inspect the output before running full queries.

  4. Check Execution Plans
    Most SQL engines (PostgreSQL, MySQL, SQL Server, etc.) let you inspect the query plan. If you see nested loops or massive estimates, recheck your joins.

  5. Monitor Query Size
    Especially in ETL pipelines or analytics workflows, monitor intermediate table sizes to prevent runaway joins.

  6. Consider Row Count Beforehand
    A quick count can warn you:

				
					SELECT COUNT(*) FROM a;  -- 10,000
SELECT COUNT(*) FROM b;  -- 25,000
-- Do you really want 250 million rows?
				
			

Summary

CROSS JOINs are a double-edged sword in SQL:

✅ Pros❌ Cons
Generates full combinationsCan create huge, unmanageable result sets
Useful for test dataEasy to write by accident
Ideal for calendar/data gridsDifficult to debug if misused

Used deliberately, CROSS JOINs can be powerful tools in a SQL developer’s toolkit. But if misapplied—or worse, written by mistake—they can become dangerous liabilities that tank performance and flood your system with meaningless data.

Treat CROSS JOINs with caution and respect.

Please see the other SQL video learning articles below as part of this learning SQL online course video. 

If you would like an instructor lead SQL course that goes into more detail with worked examples then we also provide a video course to learn SQL online hosted on UDEMY. 

Learning SQL programming with SQL server
Learn SQL Online