NULL vs Empty String: Why "No Data" Isn't Always the Same Thing

17 Jul, 2026

If you've worked with databases for more than a week, you've probably hit this moment: a text field has no data, and you have to decide: do I leave it NULL, or do I set it to an empty string ''? It looks like a trivial choice. It isn't. Pick wrong (or pick inconsistently) and you'll spend years explaining weird bugs in your reports.

Let's break down what each one actually means, why most well-designed systems lean toward NULL, and where empty strings sneak in anyway.

First, What Are We Even Comparing?

NULL means "unknown" or "not applicable." It's the database's way of saying we don't have this information, not "we checked and there's nothing there."

Empty string ('') means "this value is known, and it happens to be zero characters long." That's a real, defined value; it's just an empty one.

These sound similar in casual conversation but they are semantically different claims about the world. NULL is an absence of a fact. '' is a fact that happens to be blank.

Example: think about a MiddleName column.

• NULL → we don't know if this person has a middle name.
• '' → we asked, and this person genuinely has no middle name.

Most systems can't actually tell these two situations apart, which is exactly the problem.

Why NULL Is Usually the Better Default

1. It's honest about missing data

If a field is NULL, anyone querying it knows immediately: this information isn't here. An empty string implies someone already resolved the question and the answer was "nothing," which is rarely true in practice. Most of the time an empty string in a LastName field doesn't mean the person has no last name; it means a form was submitted without one, or a script defaulted to '' instead of leaving the field untouched.

2. Aggregate functions behave the way you'd expect

SELECT COUNT(LastName) FROM users;

COUNT() ignores NULL values automatically. So this query tells you how many users have a recorded last name. If those missing values were empty strings instead, they'd get counted too, and your "how many records have this field filled in" number would just be wrong.

3. Filtering is cleaner

With NULL, you write:

WHERE LastName IS NULL

Clean, explicit, and every SQL engine agrees on what this means.

With empty strings, people often forget to handle both cases and end up needing:

WHERE LastName IS NULL OR LastName = ''

or worse, they only check LastName = '' and silently miss all the actual NULL rows. This is a very common, very quiet bug: it doesn't throw an error, it just returns incomplete results.

4. Storage and indexing

Most database engines store NULL more efficiently than an empty string. A NULL is typically just a flag bit, with no string overhead at all. Indexes also tend to handle NULL more predictably than a bunch of empty strings that all "look the same" but technically aren't nothing.

5. Tools expect NULL, not blank strings

Reporting tools, BI dashboards (Power BI, Tableau, Looker), and most ORMs have built-in handling for missing data, and that handling is built around NULL. Feed those tools an empty string instead, and you'll often get a mystery category like a blank slice in a pie chart, or a "missing" group that doesn't get filtered out the way you'd expect.

So Why Do Empty Strings Show Up Everywhere Anyway?

If NULL is clearly the better default, why do so many production systems end up full of empty strings? A few very common reasons:

• CSV has no concept of NULL. The moment data gets exported to CSV, a NULL value becomes nothing, which often gets re-imported later as ''. Round-trip a dataset through enough CSV exports/imports and NULLs quietly turn into empty strings forever.
• Frontend forms default to empty strings. A form field that's left blank usually submits "", not null, unless someone specifically coded around that. JavaScript in particular has a long-standing habit of treating "no value" as "".
• NOT NULL constraints added without a real migration plan. Someone adds a NOT NULL constraint to a column that used to allow nulls, the migration needs something to put in the empty rows, and '' is the path of least resistance, even though it quietly changes the meaning of every row that was previously NULL.
• Some engineers just don't think about the distinction. It's an easy thing to overlook, especially under deadline pressure, and once a table has a mix of both, cleaning it up later is a genuinely annoying task.

The Practical Takeaway

• Default to NULL for "we don't have this data."
• Reserve '' for cases where you've genuinely confirmed the value is blank (rare, but it happens, e.g. a "middle name" field where the user explicitly typed nothing after being asked).
• Pick one convention and enforce it consistently across your schema, your API layer, and your frontend forms. Mixing both in the same column is where most of the pain comes from, not from choosing one over the other.
• If you're stuck maintaining a table that already has both, don't just find-and-replace blindly. Understand what each blank actually means in context before you decide whether it should become NULL or stay ''.

At the end of the day, this isn't really a database trivia question; it's a data modeling question. NULL and '' are answering two different questions ("do we know?" vs. "do we know, and it's nothing"), and most of the time, the question you're actually trying to answer is the first one.