LEFT JOIN preserves all rows from the left table. RIGHT JOIN does the opposite: it preserves all rows from the right table and fills in NULLs for the left side when no match exists.

Every RIGHT JOIN can be rewritten as a LEFT JOIN by swapping the table order, which makes RIGHT JOIN rare in practice. But understanding it matters because it shows up in interviews and in legacy codebases.

Insert the following rows to follow along:

User 6 (frank_j) has no rows in streams. Track 10 (Pulse) has no streams. These gaps drive the examples in this chapter.

RIGHT JOIN is the mirror image of LEFT JOIN. It compares rows from both tables using the ON condition, combines matched rows, and preserves every row from the right table. When a right-table row has no match in the left table, the left-side columns are filled with NULLs.

This returns all 15 stream rows for the five users who have streams, plus one row for frank_j where stream_id and track_id are NULL. The users table is on the right side of the join, so RIGHT JOIN preserves every user.

Compare this with the equivalent LEFT JOIN from the previous chapter:

Both queries produce the same rows. The only difference is which table appears on which side of the JOIN keyword.

The following diagram shows the matching process. All right-table rows are preserved. Unmatched right rows get NULLs for the left side:

The red node shows the key behavior: frank_j has no matching stream, but RIGHT JOIN keeps the row with NULLs for the left (streams) columns.

RIGHT JOIN vs RIGHT OUTER JOIN

Just like LEFT JOIN, the word OUTER is optional. RIGHT JOIN and RIGHT OUTER JOIN are identical. Most developers use the shorter form.

Every RIGHT JOIN can be rewritten as a LEFT JOIN by swapping the table order, and vice versa. The two forms are logically equivalent.

The Rule

is the same as:

Swap the tables and change RIGHT to LEFT (or LEFT to RIGHT). The ON condition stays the same.

Example 1: Preserving All Artists

This RIGHT JOIN keeps every artist and shows their album count:

The equivalent LEFT JOIN swaps the table order:

Both return all five artists with their album counts. In our sample data every artist has exactly one album, so both queries return the same five rows with album_count = 1. If an artist had no albums, they would still appear with album_count = 0.

Example 2: Anti-Join with RIGHT JOIN

Finding tracks that have never been streamed, using RIGHT JOIN:

The equivalent LEFT JOIN:

Both return Pulse (track 10), the only track with no streams. The anti-join pattern works identically with RIGHT JOIN. You check for NULL on the opposite table's key, the left table in this case.

Example 3: Multi-Table Conversion

When a query uses multiple joins, converting a RIGHT JOIN means you only need to swap the two tables involved in that specific join:

Both queries return all four genres with their album counts.

The conversion is mechanical: swap the two table positions, change the join direction, keep the ON condition as-is.

In practice, RIGHT JOIN is uncommon. Most SQL style guides recommend LEFT JOIN because it reads naturally: "start with this table, and optionally bring in data from that table." The preserved table comes first, which matches how most people think about the query.

That said, there are a few situations where RIGHT JOIN appears:

Legacy or Generated Code

Older queries, auto-generated SQL from ORMs or reporting tools, and stored procedures sometimes use RIGHT JOIN. Being able to read and convert them is a practical skill.

Preserving a Later Table in a Join Chain

When a query joins several tables in sequence and you want to preserve all rows from the last table in the chain, RIGHT JOIN avoids rearranging the entire FROM clause.

Consider a query that starts with streams, joins through tracks and albums, and needs to preserve all artists:

With LEFT JOIN, you would need to restructure the query to start from artists and reverse the join direction:

The LEFT JOIN version is more readable and is what most developers would write from scratch. But if you are modifying an existing query that already starts with streams and joins several tables, adding a RIGHT JOIN at the end can be simpler than rewriting the entire query.

Readability Is the Deciding Factor

There is no performance difference between LEFT JOIN and RIGHT JOIN. The database engine treats them identically after resolving the table order. The choice is purely about readability. In almost every case, rewriting a RIGHT JOIN as a LEFT JOIN makes the query clearer, which is why most teams prefer LEFT JOIN.