SQLMaxx
Sign in Start free
N013-H1 Tier 2 · Core SQL · hard ecommerce · Brightlane

Return both counts in one row

Part of Aggregate Functions (COUNT, SUM, AVG, MIN, MAX) in SQL

The problem

Brightlane's data team is auditing the customers table. They want the total number of customer records alongside the number of customers who have a city on file — in a single row, so the gap between the two figures is immediately visible.

Write a query to return both counts in one row.

Assumptions:

  • The customers table contains every customer Brightlane has on file.
  • Some customers have a recorded city value; many have a missing city.
  • Both figures come from the same set of customers; neither figure excludes the missing-city customers up front.

Output:

  • A single row with two columns, total_customers and customers_with_city. The two values will not be equal — the gap reflects how many customers are missing a city.
Schema · ecommerce 5 tables
categories
id integer
name text
parent_id? integer
products
id integer
name text
category_id integer
price numeric
stock_qty integer
attributes? jsonb
order_items
id integer
order_id integer
product_id integer
quantity integer
unit_price numeric
customers
id integer
name text
email text
city? text
country text
created_at timestamptz
is_active boolean
orders
id integer
customer_id integer
ordered_at timestamptz
status text
total_amount numeric
Check answerShift Ctrl ↵

Run previews · Check grades

Write a query, then run it to see results here.
Worked solution Try it yourself first
Solution query
SELECT
  COUNT(*) AS total_customers,
  COUNT(city) AS customers_with_city
FROM
  customers

The shape

COUNT(*) counts every row in customers. COUNT(city) counts only rows where city is not NULL. The difference between the two numbers — 70 minus 61, so 9 here — is exactly the number of customer records missing a city value. The two aggregates side by side make the data-quality gap immediately readable.

Clause by clause

  • FROM customers is the source set: every customer Brightlane has on file, regardless of how complete each record is.
  • COUNT(*) AS total_customers counts rows. The * form ignores every column's value, NULL or otherwise, and just tallies row existence. The result is the table's row count: 70.
  • COUNT(city) AS customers_with_city counts non-NULL values of the city column. PostgreSQL walks the table the same way, but this time it only adds to the running tally when the city value is something real. Rows with city IS NULL are skipped from the count. The result is 61.
  • The comma between the two aggregates puts both numbers in the same output row. A single pass over customers produces both counts simultaneously, which means they describe the same snapshot of the table.

Why this and not two separate queries

The total_customers - customers_with_city difference is the geocode-coverage gap, computable directly from the two numbers in the same result row. The data team gets the gap without running a third query, and the two counts are guaranteed to come from the same point in time — there's no concurrent customer creation landing between two passes.

The trap

The trap is confusing COUNT(*) and COUNT(col) and using them interchangeably. They are different aggregates with different inputs. COUNT(*) always returns the row count; COUNT(col) returns the count of non-NULL values in col. If every row has a value for col, the two numbers happen to match — but that's a coincidence of the data, and the two counts are still measuring different things. The moment a single NULL appears in col, the numbers diverge.

The way to keep them straight: COUNT(*) is for "how many rows are there?" COUNT(col) is for "how many rows have data in this column?" The audit question here is the second one, and the gap between the two answers is the story the team came to read.

You practiced contrasting COUNT(*) with COUNT(col) in a single row. The gap between them is the data-quality story for that column.

How you actually get good at SQL

Reading explains SQL. Writing it, over and over with instant feedback, is what makes you fluent.

That's the whole SQLMaxx loop: 600+ real problems, instant AI feedback, mastery you can actually see, and spaced review that won't let you forget.

A stack of SQL practice problem cards, the top card showing an employees table.
615 problems · 66 concepts

Real problems. Not toy examples.

615 hand-built problems spanning all 66 concepts, from basic SELECTs to window functions, built on real schemas and real business questions, the kind you'll actually get asked on the job. Enough reps to make SQL automatic.

A retro computer showing a SQL query marked correct with a green checkmark.
Instant AI feedback

Write a query. Know if it's right in one second.

No copying an answer and hoping it clicked. The AI grader checks your real query against real data, catches exactly what's wrong, and explains the fix in plain English, like a senior analyst reading over your shoulder on every problem.

A circular mastery progress dial filling from blue to green, the SQLMaxx diamond at its center.
Mastery tracking

Stop guessing whether you actually know it.

SQLMaxx tracks every concept and shows you what you've mastered and what's still shaky. Your skills fill in one concept at a time, so 'I think I get joins' becomes something you can prove.

A SQL query editor circled by a blue return arrow with a clock, scheduled to come back for review.
Spaced review

Learn it once. Keep it for good.

Most of what you learn this week fades by next week. So when a concept comes due for review, SQLMaxx hands you a fresh problem to solve from a blank editor, not a flashcard to re-read. A research-backed spaced-repetition algorithm (FSRS) times each return for right before you'd forget, so your SQL is still there months later, when the interview or the job actually needs it.

Practice, feedback, mastery, review. That's the loop that turns reading into real skill.

Start free

No account, no credit card. Start solving in under a minute.