How is SQL used at work? In almost every department, to answer questions about the business directly from the data instead of waiting for someone else to build a report. Marketing, sales, finance, product and support all use the same small set of query patterns, just pointed at different tables.
Below are five real workplace questions, one per team, each with a sample table, the query and its output. You do not need to be an engineer to follow them.
In this guide
Want to run this yourself? Copy the setup SQL
CREATE TABLE campaigns (campaign_id INT, name VARCHAR(30), spend INT);
INSERT INTO campaigns VALUES (1, 'Search Ads', 20000), (2, 'Email', 5000), (3, 'Social', 12000);
CREATE TABLE signups (signup_id INT, campaign_id INT);
INSERT INTO signups VALUES (1,1),(2,1),(3,1),(4,1),(5,2),(6,2),(7,2),(8,2),(9,2),(10,3),(11,3),(12,3);
CREATE TABLE deals (deal_id INT, company VARCHAR(30), stage VARCHAR(20), days_in_stage INT);
INSERT INTO deals VALUES (1,'Acme','Negotiation',45),(2,'Globex','Negotiation',12),(3,'Initech','Proposal',60),
(4,'Umbrella','Negotiation',33),(5,'Hooli','Won',5);
CREATE TABLE invoices (invoice_id INT, customer VARCHAR(30), amount INT);
INSERT INTO invoices VALUES (1,'Acme',5000),(2,'Globex',3000),(3,'Initech',4500),(4,'Umbrella',2000);
CREATE TABLE payments (payment_id INT, invoice_id INT, amount INT);
INSERT INTO payments VALUES (1,1,5000),(2,2,2500),(3,4,2000);
CREATE TABLE users (user_id INT, completed_onboarding INT);
INSERT INTO users VALUES (1,1),(2,0),(3,1),(4,1),(5,0),(6,1),(7,1),(8,0);
CREATE TABLE tickets (ticket_id INT, browser VARCHAR(20), topic VARCHAR(20));
INSERT INTO tickets VALUES (1,'Chrome','checkout'),(2,'Safari','checkout'),(3,'Safari','checkout'),(4,'Chrome','login'),
(5,'Safari','checkout'),(6,'Firefox','billing'),(7,'Chrome','checkout');Works in MySQL, PostgreSQL and SQLite. Paste it into any of them, then run the queries from this guide.
Marketing: which campaign actually worked?
A marketing team runs several campaigns and needs to know which one brought signups at the lowest cost, not just which got the most clicks. That means joining campaign spend to signups and dividing.
| campaign_id | name | spend |
|---|---|---|
| 1 | Search Ads | 20000 |
| 2 | 5000 | |
| 3 | Social | 12000 |
SELECT c.name, c.spend, COUNT(*) AS signups, c.spend / COUNT(*) AS cost_per_signup
FROM campaigns c
JOIN signups s ON s.campaign_id = c.campaign_id
GROUP BY c.campaign_id, c.name, c.spend
ORDER BY cost_per_signup;
| name | spend | signups | cost_per_signup |
|---|---|---|---|
| 5000 | 5 | 1000 | |
| Social | 12000 | 3 | 4000 |
| Search Ads | 20000 | 4 | 5000 |
Email is the cheapest way to get a signup (1000 each), and Search Ads the most expensive (5000 each), even though Search Ads has the largest budget. A spreadsheet pivot would have to be rebuilt every week. The query just runs again. (The signups table has one row per signup.)
Sales and sales ops: which deals are stuck?
“Which deals have been in negotiation for over 30 days?” is a SQL question, not a dashboard question. Dashboards show what someone already thought to build. SQL answers whatever comes up this week.
| deal_id | company | stage | days_in_stage |
|---|---|---|---|
| 1 | Acme | Negotiation | 45 |
| 2 | Globex | Negotiation | 12 |
| 3 | Initech | Proposal | 60 |
| 4 | Umbrella | Negotiation | 33 |
| 5 | Hooli | Won | 5 |
SELECT company, days_in_stage
FROM deals
WHERE stage = 'Negotiation'
AND days_in_stage > 30
ORDER BY days_in_stage DESC;
| company | days_in_stage |
|---|---|
| Acme | 45 |
| Umbrella | 33 |
Two deals need a nudge. Change 30 to 14 or 'Negotiation' to 'Proposal' and you have a new report in seconds.
Finance: which invoices do not match the payments?
Reconciliation, checking that what was invoiced matches what was paid, is a “join and compare” problem, and it is much faster in SQL than lining up two spreadsheets by eye. A LEFT JOIN keeps every invoice, even the ones with no payment at all:
| invoice_id | customer | amount |
|---|---|---|
| 1 | Acme | 5000 |
| 2 | Globex | 3000 |
| 3 | Initech | 4500 |
| 4 | Umbrella | 2000 |
| payment_id | invoice_id | amount |
|---|---|---|
| 1 | 1 | 5000 |
| 2 | 2 | 2500 |
| 3 | 4 | 2000 |
SELECT i.customer, i.amount AS invoiced, p.amount AS paid
FROM invoices i
LEFT JOIN payments p ON p.invoice_id = i.invoice_id
WHERE p.payment_id IS NULL
OR p.amount <> i.amount;
| customer | invoiced | paid |
|---|---|---|
| Globex | 3000 | 2500 |
| Initech | 4500 | NULL |
Two problems found at once: Globex paid 2500 against a 3000 invoice, and Initech has not paid anything (NULL). This is the same pattern as the “find rows with no match” example in our SQL joins guide.
Product: is anyone actually using this feature?
Product managers decide what to build next from usage data. “What percentage of users finished onboarding?” is one query against a users or events table:
SELECT COUNT(*) AS users,
SUM(completed_onboarding) AS completed,
ROUND(100.0 * SUM(completed_onboarding) / COUNT(*), 1) AS pct_completed
FROM users;
| users | completed | pct_completed |
|---|---|---|
| 8 | 5 | 62.50 |
5 of 8 users, or 62.5%, finished onboarding. Because completed_onboarding is 1 or 0, adding it up counts the completions. Group the same query by signup week or by plan and you can see where it drops.
Support: where do the complaints come from?
One angry customer is an anecdote. A support lead who can count checkout complaints by browser turns it into a prioritised bug report instead of waiting for engineering to spot the pattern:
SELECT browser, COUNT(*) AS checkout_tickets
FROM tickets
WHERE topic = 'checkout'
GROUP BY browser
ORDER BY checkout_tickets DESC;
| browser | checkout_tickets |
|---|---|
| Safari | 3 |
| Chrome | 2 |
Safari has the most checkout tickets, so that is where to look first.
The pattern behind all five
| Team | Question | SQL used |
|---|---|---|
| Marketing | Cost per signup by campaign | JOIN, GROUP BY, COUNT |
| Sales ops | Deals stuck for over 30 days | WHERE with AND |
| Finance | Invoices with no or wrong payment | LEFT JOIN, IS NULL |
| Product | Share of users who finished onboarding | SUM, COUNT |
| Support | Checkout tickets by browser | WHERE, GROUP BY |
Every example is the same underlying skill: filter rows, join related tables, group and count. Learn it once and it applies wherever data lives, which is now almost every department.
How to start using SQL in your job
- Ask for read-only access. Many companies give analysts a reporting database or a replica for exactly this. A
SELECTquery only reads data, so it cannot change anything. - Start small. Begin with
SELECT,WHEREandLIMITso you never pull a huge table by accident. - Avoid
UPDATEandDELETEon live data until someone experienced has reviewed the query. - Check your result. Compare a total against a number you already trust before you share it. Our guides on WHERE vs HAVING and NULL in SQL cover the most common ways a query goes quietly wrong.
Practise on your own first in our free SQL editor, with no access to company data needed.
Frequently asked questions
Do non-technical people really use SQL at work?
Yes. Analysts, marketers, finance staff, product managers and support leads commonly use SQL, or BI tools that generate SQL, to answer their own questions. You do not need a computer science background.
Do I need special access to run SQL at work?
You need permission to query the company database or a reporting copy of it. Policies vary, so ask your data or IT team. Read-only access is common for non-engineering roles.
Is SQL or Excel better for office work?
They complement each other. Excel is great for small, visual, one-off analysis, while SQL is better for large data, data that lives in a database and reports you repeat. See our SQL vs Excel comparison.
Can running a SQL query break anything?
A SELECT query only reads data. Statements like UPDATE, DELETE and DROP change data, so avoid them on live systems until you are confident and have permission.
How much SQL do I need for these tasks?
The five examples above use SELECT, WHERE, JOIN, GROUP BY and basic aggregates. That core is enough for a large share of everyday business questions.
Related reading
- Why Learn SQL? 6 Practical Reasons – the case for learning it.
- Jobs You Can Get After Learning SQL – the roles where this becomes a full-time skill.
- SQL Joins Explained – the technique behind the marketing and finance examples.
Practice on realistic data
Run queries like these in a free SQL editor in your browser, with no install.
Want a structured path instead?
Structured SQL courses – built for real data roles.
Test yourself
Timed questions with an explanation for every answer.