SQL databases treat NULL as unequal to another NULL

Why ordinary equality cannot find missing data

SQL uses `NULL` as a marker that a value is absent or unknown—not as a special value meaning zero, an empty string, or “the same as every other missing value.” If a customer’s birth date is unknown, for example, the database has no date it can compare with another date.

That uncertainty changes what a comparison means. In SQL’s logic, `birth_date = NULL` does not evaluate to true or false; it evaluates to unknown. Even comparing two rows whose dates are both `NULL` leaves the result unknown, because the database cannot tell whether the absent dates would match if they were known.

The third result changes query behavior

SQL conditions can produce three outcomes: true, false, or unknown. A `WHERE` clause returns only rows for which its condition is true. So a filter such as `WHERE birth_date = NULL` finds no rows—not because SQL has proved that their dates differ, but because the comparison never becomes true.

The same issue can surprise developers using `NOT`: if `birth_date = NULL` is unknown, negating it is still unknown, not true. A query intended to find missing dates therefore needs the dedicated test `WHERE birth_date IS NULL`. To find dates that are present, use `IS NOT NULL`.

A missing value is not a match

This distinction matters in joins and other filters: a row with an unknown key will not match another row merely because that row’s key is also unknown. Treating missing information as a match would make an assumption the data itself does not support.

The practical rule is simple: use equality to compare known values, and `IS NULL` to ask whether a value is missing. That small change prevents a query from silently excluding the very rows it was meant to find.