WHERE vs HAVING in SQL: The Interview Answer

If you have interviewed for anything touching data in the last year, you have probably been asked to explain WHERE vs HAVING in SQL. It is one of the most predictable technical screens out there, and it doubles as a quick test of whether you understand how a query actually runs. Here is the short version, then the example, the execution order, and a spoken answer you can deliver in about twenty seconds.

WHERE vs HAVING in one sentence

WHERE filters individual rows before any grouping happens, and it cannot use aggregate functions like COUNT or SUM. HAVING filters groups after GROUP BY has run, and it is built specifically for conditions on aggregates. Rows before grouping, groups after grouping. That distinction is the whole answer, and most interviewers just want to hear you say it cleanly.

The reason it comes up so often is that it separates people who memorized syntax from people who understand the query pipeline. A candidate who tries to put WHERE COUNT(*) > 5 into a query is signaling a weak foundation, and interviewers know it.

A side-by-side query example

Take a single orders table with columns for customer_id, order_id, order_total, and order_date. Here is WHERE doing a row-level filter:

SELECT customer_id, order_id, order_total FROM orders WHERE order_date >= '2026-01-01';

That keeps only recent orders. No grouping, no aggregation, just individual rows that match the condition.

Now HAVING, filtering aggregated groups:

SELECT customer_id, COUNT(*) AS order_count FROM orders GROUP BY customer_id HAVING COUNT(*) > 5;

That returns only customers with more than five orders. The count does not exist until after GROUP BY runs, which is exactly why the condition has to live in HAVING and not WHERE.

And yes, you can and often should use both in the same query. This is the answer to the common follow-up, "Can you use HAVING and WHERE together?"

SELECT customer_id, COUNT(*) AS order_count FROM orders WHERE order_date >= '2026-01-01' GROUP BY customer_id HAVING COUNT(*) > 5;

WHERE trims the data down to recent orders first, then GROUP BY buckets what remains by customer, then HAVING keeps only the buckets with more than five orders. Each clause does the job it is designed for.

Where each clause fires in SQL execution order

The cleanest way to lock this in is the logical execution order. SQL does not run in the order you write it. It runs like this:

1. FROM and JOIN: build the working set of rows.
2. WHERE: filter individual rows (no aggregates yet).
3. GROUP BY: group the remaining rows.
4. HAVING: filter groups using aggregate conditions.
5. SELECT: compute expressions and apply column aliases.
6. ORDER BY: sort the result.
7. LIMIT: truncate the output.

Once you know this, everything about WHERE and HAVING follows. WHERE runs before GROUP BY, so aggregate values literally do not exist yet, which is why aggregates are illegal there. HAVING runs after GROUP BY, so the aggregates are computed and available. A related gotcha some interviewers throw in: column aliases you create in SELECT are not available in WHERE, because SELECT runs later. Learn the order once and you can derive every one of these rules on the spot instead of memorizing them separately. This kind of reasoning-from-first-principles is the same instinct that carries you through a system design interview, where showing your thinking matters more than reciting a fact.

Performance: does WHERE vs HAVING matter?

It does, and it is worth a sentence in your answer. The rule of thumb: filter early with WHERE to cut down the number of rows before aggregation, and only put aggregate conditions in HAVING. If you push a plain row filter (like a date range or a status) into HAVING, the database still does the aggregation work for groups it is about to throw away. WHERE reduces the rows first, so GROUP BY has less to chew through.

So the practical guidance is simple: row-level conditions go in WHERE, aggregate thresholds go in HAVING. If you can express a condition without an aggregate, it belongs in WHERE. Saying this out loud in an interview shows you think about cost, not just correctness.

The 20-second spoken answer to nail in the interview

Interviewers score clarity. The pattern that lands: state the difference crisply, give the rule of thumb, then offer a quick example. Here is a copy-ready version you can read aloud and adapt:

"In SQL, WHERE filters individual rows before any grouping, and it can't use aggregates like COUNT or SUM. HAVING filters groups after GROUP BY, and it's designed for conditions on aggregated values. My rule of thumb is: use WHERE for row-level filters and HAVING for filters on totals or other aggregates. In a lot of queries you'll use both, WHERE first to cut down the data, then HAVING to keep only the groups whose aggregates meet the condition. For example, to find customers with more than five orders this year, I'd filter the date range in WHERE, group by customer, then use HAVING COUNT(*) greater than five."

If you want a shorter fallback for when the interviewer is moving fast:

"WHERE filters rows before grouping and can't use aggregates. HAVING filters groups after GROUP BY and can. Row conditions go in WHERE, aggregate conditions go in HAVING, and you'll often use both together."

Deliver it at a normal pace, pause after the first two sentences, and offer the example only if they want it. That structure reads as confident and organized rather than rushed.

This question shows up more than you think

This is not a textbook curiosity. Multiple 2026 interview guides list "What is the difference between WHERE and HAVING?" among their core SQL questions, and one data science prep resource notes that Google commonly uses a version of this exact question to test whether candidates understand that WHERE operates on the pre-aggregation rows while HAVING operates on the result of GROUP BY. It stays relevant because relational SQL stays central to the job: the 2024 database trends survey found PostgreSQL was the most widely used database, at 48.7% of all users and 51.9% of professional developers, and a 2025 developer skills guide ranks SELECT and WHERE among the highest daily-use commands.

We see the same pattern in our own data. Across the interviews recorded with MeetAssist, the WHERE vs HAVING question came up with six different candidates between mid-July and late August, and the broader opener "Have you worked with databases?" appeared with five more. Both sit in the technical category. The database opener is the on-ramp: answer it well and the specific clause questions follow. For live technical rounds where these fire back-to-back, MeetAssist surfaces answer suggestions in real time on Zoom, Meet, and Teams, and stays invisible during screen sharing. It is worth knowing what these tools do and don't do before you rely on one, which is covered in our roundup of whether interviewers can tell if you use AI in an interview.

Related follow-up questions to prepare

If you get "Have you worked with databases?" as the opener, expect the interviewer to drill into specifics. Have short answers ready for these:

• Can HAVING use multiple conditions? Yes, combine them with AND or OR, for example HAVING COUNT(*) > 5 AND SUM(order_total) > 1000.
• Can you use both WHERE and HAVING together? Yes, and good queries often do, WHERE first to trim rows, HAVING after to filter groups.
• Does this differ across SQL Server, MySQL, and Oracle? The core behavior is the same across dialects; the differences are mostly in syntax edge cases, not in what WHERE and HAVING do.
• What does GROUP BY actually do? Be ready to explain that it collapses rows into groups so aggregate functions can run per group.
• Can HAVING run without GROUP BY? Yes, and it treats the whole result as a single group (more on that below).

These follow-ups reward the same habit: reason from the execution order and you can answer questions you never explicitly rehearsed. If you want a wider sense of what actually gets asked in technical screens, our breakdown of the most common interview questions from 340 real interviews is a useful map, and if you are still breaking in, getting into IT in 2026 covers the fundamentals worth drilling.

Frequently asked questions

Can you use WHERE and HAVING in the same query?

Yes, and many well-written queries do. WHERE runs first to filter individual rows before grouping, then HAVING runs after GROUP BY to filter the resulting groups. A typical pattern is WHERE to limit a date range or status, then HAVING to apply a threshold on a COUNT or SUM.

When should you use HAVING instead of WHERE?

Use HAVING when your condition depends on an aggregate value like COUNT, SUM, or AVG, because those are only computed after GROUP BY. Use WHERE for any condition on raw column values. If a filter does not involve an aggregate, it belongs in WHERE.

Is WHERE or HAVING faster in SQL?

WHERE is generally cheaper because it reduces the number of rows before grouping and aggregation happen, so GROUP BY has less work to do. HAVING filters after aggregation is already done, so pushing a plain row filter into HAVING wastes effort. Filter early with WHERE whenever the condition allows it.

Can HAVING be used without GROUP BY?

Yes. Without GROUP BY, HAVING treats the entire result set as a single group and filters based on an aggregate over all rows. It returns either the aggregated result or nothing, which surprises candidates who assume HAVING always requires GROUP BY.

What's the difference between WHERE and HAVING in simple terms?

WHERE filters rows, HAVING filters groups. WHERE runs before grouping and cannot see aggregates; HAVING runs after grouping and is made for them. That one line, plus a quick example, is enough for most interviews.