Is the comma join FROM orders o, customers c WHERE o.customer_id = c.id the same as INNER JOIN ... ON?

## The two spellings ```sql -- comma ("implicit") join SELECT o.id, c.name FROM orders o, customers c WHERE o.customer_id = c.id AND o.status = 'PAID'; -- explicit join SELECT o.id, c.name FROM orders o INNER JOIN customers c ON o.customer_id = c.id WHERE o.status = 'PAID'; ``` Both return the same rows. In standard SQL, a comma between two table references in `FROM` denotes a cross join: every row of the left paired with every row of the right. `WHERE` then keeps the pairs where the predicate is TRUE. "Cross product, then filter for TRUE" is exactly the definition of an inner join, so the two forms are the same query said two ways. The explicit form is sometimes called ANSI or SQL-92 join syntax; the comma form predates it. Note the scope of that equivalence: it holds for **inner** joins. Once outer joins enter the query, `ON` and `WHERE` stop being interchangeable, because an outer join adds NULL-extended rows *between* the two steps. ## Why explicit syntax won **Join conditions stop hiding among filters.** In the comma form, `o.customer_id = c.id` (structural: how the tables relate) and `o.status = 'PAID'` (a business filter) sit in the same list, separated by `AND`. With five tables you have four structural predicates mixed into whatever filters the report needs, and a reader has to reconstruct the join graph in their head. Explicit syntax puts each condition beside the table it belongs to. **A missing condition is visible.** Forgetting a comma-join predicate is silent: the query still parses, still runs, and returns the cross product — usually far too many rows, sometimes just slowly wrong. Forgetting an `ON` clause is a syntax error in the explicit form, because `JOIN` requires `ON` or `USING`. The stricter syntax turns a runtime data bug into a compile-time complaint. **Outer joins are inexpressible.** There is no comma spelling for "keep the unmatched left rows". You cannot mark a side as preserved in a `WHERE` predicate, because by then the pairing step is over. A codebase written in comma style has to be converted the first time a query needs to preserve unmatched rows — and mixing the two styles in one `FROM` clause is where readers get lost. Some engines historically offered proprietary operators inside `WHERE` for this; they are non-standard, not portable, and long discouraged. **Precedence is not what people assume.** A `JOIN` expression binds more tightly than a comma. So in ```sql FROM a, b JOIN c ON b.id = c.b_id ``` the `JOIN` pairs `b` with `c`, and the result is cross-joined with `a`. Readers who scan left to right often expect `a` to be involved. This is a real trap in half-migrated code, and a reason to convert a `FROM` clause wholesale rather than one join at a time. **Correlation names still behave the same.** Both forms alias tables the same way, and in both the alias replaces the table name for the rest of the query. That part is not a difference. ## What about more than two tables? Comma syntax scales grammatically — `FROM a, b, c, d WHERE …` is legal — but the readability cost grows with each table, and so does the chance that one structural predicate is missing. Explicit syntax makes the join order visible as a chain, one `JOIN … ON` per line, and each condition provably present. ## Is one faster? This question is about the language, not the engine, and the honest answer is that the two forms express the same logical result — a mature optimizer is free to execute either the same way. Choose the explicit form for clarity and for outer-join capability, not on a performance claim. ## The interview answer "They are equivalent for inner joins — a comma is a cross join and `WHERE` filters it. I still write explicit `JOIN … ON` because it separates structure from filters, makes a forgotten join condition a syntax error instead of a Cartesian product, and is the only syntax that can express outer joins. And I never mix the two, because `JOIN` binds tighter than the comma."