Return the number of unique customers who appear in the orders history, in a single column named `unique_customers`

The shape

COUNT(DISTINCT customer_id) counts how many unique customers have placed at least one order — collapsing repeat buyers into a single tally each, rather than counting orders. Brightlane has 200 orders from 62 distinct customers, which is what the CRM team's engagement report needs.

Clause by clause

• FROM orders is the source set. Every row represents one order, and the customer_id column on each order identifies the buyer.
• COUNT(DISTINCT customer_id) is the aggregate with a twist. COUNT(customer_id) on its own would count every order with a recorded customer ID, counting one customer multiple times if they have multiple orders. The DISTINCT keyword tells COUNT to de-duplicate the values first and then count the unique ones. The result is the number of distinct customers who have ever placed an order, regardless of how many times they came back.
• COUNT(customer_id), with or without DISTINCT, also skips rows where customer_id is NULL. The count only covers customers who have an actual ID on record.
• AS unique_customers labels the result with what's being counted: distinct customer identities, not rows and not orders.

Why this and not COUNT(*)

COUNT(*) would return the total number of order rows — every order Brightlane has processed, counted once each. That answers "how many orders" rather than "how many distinct customers." For an active-buyer headcount, the question is the latter, so the de-dup step is load-bearing.

The other near-miss is COUNT(customer_id) without DISTINCT. That counts orders-with-a-customer-ID, which is just the order count again (minus any orphan rows). A customer with five orders contributes five to that count, not one. The headcount the CRM team needs requires the DISTINCT step that collapses repeat buyers.