SQL Projects for Beginners: 15 Portfolio Projects for Data Analyst Roles

Introduction: what a SQL project should prove

A beginner SQL project should show more than syntax. It should show that you can turn a business question into tables, joins, aggregations, validation checks, and a short explanation that a stakeholder could understand.

Strong portfolio projects include a clear business question, realistic dataset, clean query logic, joins or aggregations, documented assumptions, validation checks, findings, and a small recommendation or next-step question. Do not present sample projects as paid client work or employer results.

• Show the business question before showing code.
• Use clear table grain: one row per order, customer, event, employee, product, or donation.
• Include at least one validation query so your result looks trustworthy.
• Write a short finding and limitation after the SQL output.

What makes a good beginner SQL project

A good beginner project is focused enough to finish but realistic enough to discuss in an interview. It should use a dataset with multiple fields or multiple tables, require filtering or grouping, and produce a result that helps answer a decision question.

The best beginner projects do not try to be advanced for the sake of being advanced. They use the right SQL concepts for the question and explain the result clearly.

• Realistic dataset or public/sample data with a clear source note.
• Business question with audience: sales manager, operations lead, HR manager, nonprofit director, or product team.
• Multiple tables or carefully explained single-table analysis.
• JOIN, GROUP BY, CASE, date filtering, and validation checks where appropriate.
• Short written findings, assumptions, and limitations.

Beginner SQL skills roadmap

Build skills in a sequence that produces portfolio evidence. Start by retrieving rows, then summarize them, then connect tables, then validate results, then document findings.

A beginner does not need every advanced SQL feature before building a portfolio. One clean project with assumptions, validation, and readable queries is stronger than a copied advanced query you cannot explain.

• SELECT and WHERE: return the right rows and columns.
• ORDER BY: sort outputs for review.
• GROUP BY and aggregate functions: calculate counts, revenue, averages, and rates.
• CASE: create segments such as high value, inactive, late, or risk category.
• JOINs: connect orders to customers, products, employees, campaigns, or events.
• CTEs: break analysis into readable steps.
• Window functions: rank, deduplicate, calculate previous-period values, or create running totals.
• Data quality checks: inspect nulls, duplicates, unmatched joins, and row-count changes.
• Documentation: explain assumptions, findings, and limitations in a README.

Project 1: Sales performance analysis

Difficulty: Beginner. Dataset idea: sample ecommerce or retail sales data with orders, order_items, products, and customers tables.

Business question: Which months, regions, and product categories drive revenue, and where should the business investigate performance changes?

• Tables needed: orders, order_items, products, customers.
• Key SQL concepts: JOIN, GROUP BY, SUM, date filtering, CASE for order status.
• Sample questions: monthly revenue trend, top categories, average order value, completed vs cancelled orders.
• Example query: SELECT DATE_FORMAT(order_date, "%Y-%m") AS month, SUM(quantity * unit_price) AS revenue FROM orders JOIN order_items USING(order_id) WHERE status = "completed" GROUP BY month ORDER BY month;
• Validation checks: compare total revenue before and after category joins; count cancelled orders separately; check duplicate order_id values.
• Portfolio deliverable: one README, revenue summary table, trend chart, and three business findings.
• Resume bullet: Analyzed sample retail orders with SQL joins and aggregations to calculate monthly revenue, category performance, and validation checks for completed orders.

Project 2: Customer order behavior

Difficulty: Beginner to intermediate. Dataset idea: orders and customers from an ecommerce sample.

Business question: Which customers buy repeatedly, which customers appear inactive, and how does average order value differ by customer segment?

• Tables needed: customers, orders, order_items.
• Key SQL concepts: COUNT DISTINCT, GROUP BY customer, CASE segmentation, date difference, CTEs.
• Sample questions: repeat customer count, average order value, days since last order, high-value customer segment.
• Example query: WITH customer_orders AS (SELECT customer_id, COUNT(DISTINCT order_id) AS orders_count, MAX(order_date) AS last_order_date FROM orders WHERE status = "completed" GROUP BY customer_id) SELECT CASE WHEN orders_count >= 2 THEN "repeat" ELSE "one_time" END AS segment, COUNT(*) AS customers FROM customer_orders GROUP BY segment;
• Validation checks: compare distinct customers in customer_orders against completed orders; inspect customers with missing email or region.
• Portfolio deliverable: customer segment table and short retention-style interpretation.
• Resume bullet: Built SQL customer segments using order count, recency, and average order value to summarize repeat-purchase behavior in a sample ecommerce dataset.

Project 3: Product revenue and category analysis

Difficulty: Beginner. Dataset idea: product catalog joined to transaction lines.

Business question: Which products and categories contribute most to revenue, margin, or units sold?

• Tables needed: products, order_items, orders.
• Key SQL concepts: JOIN, GROUP BY category, ORDER BY, calculated fields.
• Sample questions: top 10 products by revenue, revenue by category, units sold by category, discount impact if discount exists.
• Example query outline: join order_items to products, filter completed orders, group by product_category, calculate revenue and units, order by revenue descending.
• Validation checks: find order_items with missing product_id matches using LEFT JOIN; compare item counts before and after product join.
• Portfolio deliverable: category revenue table and product insight summary.
• Resume bullet: Queried sample product and order tables to identify top categories, missing product matches, and revenue concentration patterns.

Project 4: Inventory and stock risk analysis

Difficulty: Beginner to intermediate. Dataset idea: inventory snapshots, product catalog, and sales history.

Business question: Which products are at risk of stockout or overstock based on recent sales and current quantity?

• Tables needed: products, inventory, order_items, orders.
• Key SQL concepts: JOIN, aggregation, CASE risk labels, date filtering.
• Sample questions: current stock by product, 30-day units sold, days of supply, stock risk category.
• Example query outline: calculate recent_units_sold by product in a CTE, join to inventory, create CASE WHEN stock_on_hand < recent_units_sold THEN "stockout risk".
• Validation checks: count products without inventory rows; confirm sales period date range; inspect negative or null stock values.
• Portfolio deliverable: stock risk table with recommended review list.
• Resume bullet: Created SQL stock-risk flags by comparing recent sample sales to inventory quantities and identifying products needing reorder review.

Project 5: Website traffic and conversion funnel

Difficulty: Intermediate beginner. Dataset idea: website events with users, sessions, event_type, page, and timestamp.

Business question: Where do users drop off between visit, product view, signup, cart, and purchase?

• Tables needed: events, users, sessions or a single event table.
• Key SQL concepts: conditional aggregation, COUNT DISTINCT, CASE, funnel stages.
• Sample questions: users by funnel stage, conversion rate by source, drop-off between signup and purchase.
• Example query outline: group by traffic_source and count distinct user_id for each event_type using SUM(CASE WHEN event_type = "purchase" THEN 1 ELSE 0 END) or COUNT(DISTINCT CASE WHEN ... THEN user_id END).
• Validation checks: inspect duplicate events, bot-like sessions, missing source values, and timezone assumptions.
• Portfolio deliverable: funnel table and short recommendation on where to investigate.
• Resume bullet: Built SQL funnel metrics from sample web events to compare traffic sources, conversion stages, and drop-off points.

Project 6: Employee attendance or HR analysis

Difficulty: Beginner. Dataset idea: employee table, attendance logs, department table, and leave records.

Business question: Which departments have high absence, late arrival, or overtime patterns that need review?

• Tables needed: employees, attendance, departments, leave_requests.
• Key SQL concepts: date filtering, GROUP BY department, CASE flags, averages.
• Sample questions: absenteeism rate, late arrivals by department, overtime hours by month.
• Example query outline: create daily attendance flags, group by department and month, calculate late_count and absence_count.
• Validation checks: check employees without attendance rows; separate approved leave from unexplained absence; inspect missing department IDs.
• Portfolio deliverable: HR trend summary with privacy-safe sample data note.
• Resume bullet: Analyzed sample HR attendance logs with SQL to summarize absence, lateness, and overtime trends by department.

Project 7: School or student performance analysis

Difficulty: Beginner. Dataset idea: anonymized/sample student assessments, classes, attendance, and subjects.

Business question: Which subjects or groups need academic support based on scores, attendance, and trend changes?

• Tables needed: students, assessments, classes, attendance.
• Key SQL concepts: GROUP BY, averages, CASE pass/fail flags, joins.
• Sample questions: average score by subject, attendance vs performance band, improvement over term.
• Example query outline: join assessments to classes, group by subject and term, calculate AVG(score), pass rate, and count of students.
• Validation checks: confirm no real student personal data; inspect missing scores; check duplicate assessment attempts.
• Portfolio deliverable: anonymized academic summary with limitations.
• Resume bullet: Used SQL on sample education data to calculate subject-level performance, attendance bands, and support-priority indicators.

Project 8: Nonprofit donation analysis

Difficulty: Beginner. Dataset idea: donors, donations, campaigns, and payment status.

Business question: Which campaigns attract repeat donors and what donation patterns can guide outreach?

• Tables needed: donors, donations, campaigns.
• Key SQL concepts: joins, SUM, COUNT DISTINCT, first/last donation dates, CASE donor tiers.
• Sample questions: donations by campaign, repeat donor count, average donation amount, donor tier distribution.
• Example query outline: aggregate donations by donor_id, create donor tiers with CASE, join campaign summaries for campaign performance.
• Validation checks: exclude failed payments; check duplicate donation IDs; count donors without campaign attribution.
• Portfolio deliverable: donor and campaign summary with ethical data note.
• Resume bullet: Built SQL donation summaries for sample nonprofit data, including campaign revenue, donor segments, and repeat donor indicators.

Project 9: Event registration analysis

Difficulty: Beginner. Dataset idea: events, registrations, attendees, ticket types, and check-ins.

Business question: Which events convert registrations into attendance and where are no-shows highest?

• Tables needed: events, registrations, attendees, checkins.
• Key SQL concepts: LEFT JOIN, conversion rate, grouping, date filters.
• Sample questions: registration count, attendance count, no-show rate, ticket type mix.
• Example query outline: LEFT JOIN registrations to checkins, group by event_id, calculate attended_count and no_show_rate.
• Validation checks: identify registrations without attendee records; inspect duplicate check-ins; confirm cancelled registrations are excluded.
• Portfolio deliverable: event performance table and follow-up questions.
• Resume bullet: Analyzed sample event registrations with SQL to calculate attendance conversion, no-show rates, and ticket-type patterns.

Project 10: Job market postings analysis

Difficulty: Beginner to intermediate. Dataset idea: job postings with title, company, location, skills, salary range, and posted date.

Business question: Which skills and locations appear most often in entry-level data analyst postings?

• Tables needed: job_postings, companies, skills or a flattened postings table.
• Key SQL concepts: text filtering, GROUP BY, CASE role categories, date filters.
• Sample questions: top required skills, remote vs onsite share, entry-level posting count, salary availability.
• Example query outline: classify postings using CASE WHEN title LIKE "%data analyst%" THEN "data_analyst"; count postings by skill and country.
• Validation checks: remove duplicates by URL or source ID; check expired postings; document text-search limitations.
• Portfolio deliverable: job market summary and skill-priority checklist.
• Resume bullet: Queried sample job-posting data to summarize common SQL, Excel, Power BI, Tableau, and Python requirements for entry-level analyst roles.

Project 11: Data cleaning audit with SQL

Difficulty: Beginner. Dataset idea: messy customer, order, or CRM export.

Business question: What data-quality issues must be fixed before building a dashboard or report?

• Tables needed: one messy source table plus optional reference tables.
• Key SQL concepts: NULL checks, TRIM, standardization checks, duplicate detection, invalid values.
• Sample questions: missing email rate, invalid dates, inconsistent categories, blank names, unexpected statuses.
• Example query outline: SELECT COUNT(*) AS rows_total, SUM(CASE WHEN email IS NULL OR TRIM(email) = "" THEN 1 ELSE 0 END) AS missing_email FROM customers;
• Validation checks: compare raw and cleaned row counts; list top inconsistent category values; document assumptions.
• Portfolio deliverable: data-quality audit table and cleaning recommendations.
• Resume bullet: Audited sample customer data with SQL to quantify missing fields, inconsistent categories, duplicate keys, and dashboard-readiness issues.

Project 12: Duplicate and missing value investigation

Difficulty: Beginner to intermediate. Dataset idea: CRM leads, order records, or support tickets.

Business question: Which records are duplicated or incomplete, and how could that affect analysis?

• Tables needed: leads, orders, tickets, or customer records.
• Key SQL concepts: GROUP BY HAVING, ROW_NUMBER, CTEs, null checks.
• Sample questions: duplicate email addresses, duplicate order business keys, missing customer_id, missing closed_date.
• Example query: WITH ranked AS (SELECT *, ROW_NUMBER() OVER (PARTITION BY email ORDER BY created_at DESC) AS rn FROM leads) SELECT * FROM ranked WHERE rn > 1;
• Validation checks: compare duplicate definitions; inspect duplicates with different dates or statuses; document which copy would be kept.
• Portfolio deliverable: duplicate issue summary and remediation logic.
• Resume bullet: Used SQL ROW_NUMBER and null checks to identify duplicate and incomplete records in a sample operational dataset.

Project 13: Monthly KPI dashboard dataset preparation

Difficulty: Intermediate beginner. Dataset idea: orders, customers, products, and monthly targets.

Business question: What clean monthly KPI table should feed a dashboard?

• Tables needed: orders, order_items, customers, products, targets.
• Key SQL concepts: CTEs, monthly aggregation, joins, KPI definitions, target comparison.
• Sample questions: revenue, orders, active customers, average order value, target attainment.
• Example query: WITH monthly AS (SELECT DATE_FORMAT(order_date, "%Y-%m") AS month, COUNT(DISTINCT order_id) AS orders, SUM(revenue) AS revenue FROM clean_orders GROUP BY month) SELECT month, revenue, orders, revenue / NULLIF(orders, 0) AS avg_order_value FROM monthly;
• Validation checks: compare dashboard table revenue to source revenue; check missing target months; document excluded statuses.
• Portfolio deliverable: BI-ready monthly KPI table and dashboard wireframe.
• Resume bullet: Prepared a BI-ready monthly KPI dataset with SQL CTEs, revenue metrics, target comparisons, and validation checks.

Project 14: Cohort-style customer retention analysis

Difficulty: Intermediate. Dataset idea: customers and completed orders by date.

Business question: How many customers return after their first purchase month?

• Tables needed: customers, orders.
• Key SQL concepts: first purchase date, cohort month, month difference, COUNT DISTINCT, CTEs.
• Sample questions: first-purchase cohort size, returning customers by month number, retention percentage.
• Example query outline: find each customer first_order_month, join later orders, calculate months_since_first_order, group by cohort_month and month_number.
• Validation checks: ensure first purchase uses completed orders only; compare cohort customer count to customer-level table; handle same-month repeat orders consistently.
• Portfolio deliverable: retention matrix table and interpretation.
• Resume bullet: Built a SQL cohort analysis from sample customer orders to measure return behavior by first-purchase month.

Project 15: Simple BI-ready reporting table

Difficulty: Intermediate beginner. Dataset idea: any transactional dataset that needs a dashboard-ready output table.

Business question: What cleaned, joined, documented table should a BI tool use for reporting?

• Tables needed: transactional fact table plus customer, product, date, or target dimensions.
• Key SQL concepts: clean CTE, dimension joins, calculated fields, grain documentation, validation.
• Sample questions: one row per order-item or one row per monthly category; which fields are needed for dashboard filters?
• Example query outline: build a final SELECT with business-friendly column names, date parts, category fields, revenue calculation, and status filters.
• Validation checks: verify row grain, compare source row count, check unmatched dimension keys with LEFT JOIN, document exclusions.
• Portfolio deliverable: final reporting table, data dictionary, and dashboard-ready CSV.
• Resume bullet: Designed a SQL reporting table for a sample BI dashboard with documented grain, cleaned fields, and validation queries.

Useful SQL snippets for beginner projects

Keep snippets short, readable, and validated.

Use short query snippets as building blocks. In your portfolio, explain what each snippet proves instead of pasting code without context.

• GROUP BY revenue summary: SELECT category, SUM(quantity * price) AS revenue FROM order_items JOIN products USING(product_id) GROUP BY category ORDER BY revenue DESC;
• LEFT JOIN missing match check: SELECT COUNT(*) FROM order_items oi LEFT JOIN products p ON oi.product_id = p.product_id WHERE p.product_id IS NULL;
• CTE monthly trend: WITH monthly AS (SELECT DATE_FORMAT(order_date, "%Y-%m") AS month, SUM(revenue) AS revenue FROM orders GROUP BY month) SELECT month, revenue FROM monthly ORDER BY month;
• CASE segmentation: CASE WHEN total_revenue >= 1000 THEN "high_value" WHEN total_revenue >= 250 THEN "mid_value" ELSE "low_value" END AS customer_segment;
• ROW_NUMBER duplicate check: ROW_NUMBER() OVER (PARTITION BY email ORDER BY updated_at DESC) AS duplicate_rank;

How to present SQL projects on a resume and in interviews

A beginner SQL project becomes stronger when you can explain it in business language. Do not only say that you used joins and GROUP BY. Say what question you answered, what tables you used, what validation you ran, and what limitation remained.

For interviews, prepare a five-minute walkthrough: business question, dataset, table grain, query steps, validation, finding, and next analysis.

• Resume formula: Analyzed [sample dataset] with SQL to calculate [metric], identify [pattern], and validate [data-quality issue].
• Portfolio README formula: business question, dataset source, table descriptions, queries used, validation checks, findings, limitations, next steps.
• Interview explanation formula: I started by defining the metric, checked table grain, built CTEs for each step, validated totals, and summarized the result.

Common beginner SQL project mistakes

Most weak SQL portfolio projects fail because they show code without analysis. A hiring manager or interviewer needs to see that you can reason through the data, not just run a query.

Be honest about sample data and limitations. A clear sample project is better than an exaggerated project that sounds like fake client work.

• No business question.
• No data-source note.
• No validation checks.
• Joining tables without checking row multiplication.
• Counting rows when the metric requires distinct customers, orders, or users.
• Using advanced syntax you cannot explain.
• Writing resume bullets that imply real employer impact when the work was sample practice.

SQL portfolio project checklist

Before publishing a SQL project, review it like an analyst would review a report. The project should be understandable without the reader guessing your assumptions.

• Business question is clear.
• Dataset source and sample-purpose limitation are stated.
• Tables and grain are documented.
• Queries are formatted and readable.
• At least one JOIN or meaningful aggregation is included.
• Validation checks are included.
• Findings are written in plain language.
• Resume bullet is honest and specific.
• Next-step analysis is suggested.

Recommended next resources

Internal resources to continue learning.

Use these DataCareerHub resources to connect your SQL project to interview preparation, resume wording, and dashboard portfolio work.

Practice Exercise Cards

Frequently Asked Questions