Why a portfolio project beats another certificate
A certificate says "I was taught SQL." A portfolio project says "I used SQL to figure something out." Hiring managers for analyst roles are trying to predict one thing: can this person take a messy dataset and turn it into a decision someone can act on. A well-documented project is direct evidence of exactly that; a certificate is a proxy for it, several steps removed.
What makes a project actually get read
- A specific question, not a data dump. "Which product categories have the highest return rate, and does it correlate with a specific supplier?" reads as analysis. "Here's some SQL on the Olist dataset" reads as an exercise.
- The actual queries, visible. Not just a final chart — the SQL that produced it, so a reviewer can judge the skill directly, not just trust the conclusion.
- A short written finding. Two or three sentences per major query: what it showed, why it matters. This is the single most skipped step, and the one that separates "did the exercise" from "can communicate a finding."
- Visible reasoning about data quality. A line noting a handled edge case (duplicate rows, inconsistent categories, missing values) shows judgment a passing grade on a course doesn't.
8 project ideas, with datasets
| Project | Core skill demonstrated | Suggested dataset | Difficulty |
|---|---|---|---|
| E-commerce sales & RFM segmentation | Joins, aggregation, customer segmentation | Olist Brazilian E-Commerce (Kaggle) | Intermediate |
| NYC taxi trip analysis | Large-table aggregation, window functions, date/time handling | NYC TLC Trip Record Data | Intermediate |
| Retail store performance dashboard | CTEs, YoY/MoM growth, ranking | Superstore Sales (Kaggle) | Beginner → Intermediate |
| Music store sales (Chinook) | Multi-table joins, subqueries | Chinook sample database | Beginner |
| HR attrition analysis | Aggregation, CASE logic, cohort-style grouping | IBM HR Analytics Employee Attrition (Kaggle) | Intermediate |
| Movie ratings analysis | Joins, window functions, ranking | MovieLens dataset | Beginner |
| COVID-19 trend analysis | Time-series, running totals, YoY-style comparisons | Our World in Data COVID-19 dataset | Intermediate |
| Airbnb listings & pricing analysis | Geospatial-adjacent aggregation, outlier handling | Inside Airbnb (city-level datasets) | Intermediate → Advanced |
Pick one that maps to the industry you're targeting — a healthcare analyst role and an e-commerce analyst role will weigh these differently, even though the SQL skills overlap heavily.
How to structure it for GitHub
project-structure.txt
ecommerce-sales-analysis/
├── README.md -- the question, the finding, how to run it
├── schema.sql -- CREATE TABLE statements
├── queries/
│ ├── 01_top_products.sql
│ ├── 02_rfm_segmentation.sql
│ └── 03_monthly_revenue_trend.sql
├── erd.png -- a simple entity-relationship diagram
└── findings.md -- 3-5 short written insights, one per queryThe README.md is what gets read first — lead with the business question and the headline finding, not with setup instructions.
Turning a query into a story
Compare these two ways of presenting the same query:
| Query dump | Story |
|---|---|
| [SQL code block] Output: 47 rows. |
"The top 5% of customers by lifetime spend generate 38% of total revenue — but only 12% of them have made a purchase in the last 90 days, suggesting a re-engagement campaign targeted at this specific segment could be high-leverage." |
Same query, same data — but the second version is what an analyst is actually hired to produce. Every major query in a portfolio project deserves 2-3 sentences like this.
Where to find free datasets
| Source | Best for |
|---|---|
| Kaggle Datasets | Broadest variety, most already reasonably clean |
| UCI Machine Learning Repository | Smaller, well-documented classic datasets |
| Government open-data portals (data.gov, data.gov.uk) | Large, authoritative, genuinely messy — good for showing data-cleaning skill |
| Vendor sample databases (Chinook, Northwind, Sakila) | Pre-built relational schemas, good for join-heavy practice |
| Synthetic data generators | Sensitive-domain projects (healthcare, finance) where real data isn't appropriate to use publicly |
Common mistakes
- Using a toy dataset with too few rows. A 30-row spreadsheet can't produce a finding a reviewer finds credible; look for datasets with at least tens of thousands of rows.
- Showing only the final chart, not the SQL. The whole point of a SQL portfolio piece is showing the query-writing skill directly.
- Skipping the written finding. Queries without a "so what" read as an exercise, not analysis.
- Eight shallow projects instead of two or three deep ones. Depth and range of technique (joins, window functions, a small pipeline) matter more than sheer count.
- No visible handling of messy data. Real datasets have duplicates, nulls, and inconsistent categories — showing how they were handled is itself a skill signal.
Key takeaways
- A portfolio project is evidence of judgment, not just SQL syntax — pick a specific business question, not a generic exercise.
- Show the actual queries, and write 2-3 sentences of finding per major one.
- Real, sufficiently large free datasets (Olist, Chinook, NYC TLC, MovieLens, and similar) are available for every skill level.
- Two to four well-documented projects beat eight shallow ones.
- Never use a current or former employer's private data in a public portfolio.