Data Analyst Portfolio Projects in 2026: 6 Builds With Free Datasets, SQL and a Real Conclusion

You finish the course, you have four notebooks, and nobody replies. The notebooks are fine. They load a clean CSV, drop two columns, plot a histogram, and stop exactly where the interesting part starts. The person who got the interview published one repo about why a logistics dashboard disagreed with the finance number, and could defend that disagreement for twenty minutes.

What Makes Data Analyst Portfolio Projects Actually Work

Picture a specific reader. A hiring manager at a mid size insurer in Pune opens twelve GitHub profiles on a Thursday evening with thirty minutes to spend. She scans for four things in order: the question, the data source, what went wrong and how you handled it, and what you decided. A 200 word README answering all four beats a 600 cell notebook.

Where most data analyst project ideas go wrong

Three failure modes repeat. The tutorial clone, meaning Titanic, Iris or an IMDB walkthrough, which a reviewer spots in two seconds; delete those. The dashboard with no question, where fourteen visuals sit on one page because the tool made them easy. And the analysis that stops at the chart.

Now the honest caveat. A portfolio rarely gets you past the first screen in India, where applications are filtered on years of experience, title and keyword match before anyone clicks a link. Projects do not fix that funnel. They fix the interview, where one real build gives you forty minutes of material.

The Six Projects at a Glance

Each build is scoped to be finishable, assuming basic SQL and a Power BI Desktop install. The stack column is deliberately boring: an hour spent choosing a tool is an hour not spent on the analysis.

Project 1: The Power BI Portfolio Project That Starts With a Star Schema

Almost everyone building a Power BI portfolio project loads one flat CSV and starts dragging fields. Do the opposite. Take the Olist set, which ships as nine files, and model it: a fact table of order items, dimensions for customers, products, sellers and dates, one relationship path from each dimension to the fact.

That choice is the project. When the interviewer asks why your delay measure is correct, you point at a one to many relationship and a table marked as the date table instead of guessing. Our Pune hiring manager asks this first, because it is what breaks in real reports.

Late Deliveries % =
VAR Late =
    CALCULATE (
        COUNTROWS ( 'Orders' ),
        FILTER (
            'Orders',
            'Orders'[order_delivered_customer_date]
                > 'Orders'[order_estimated_delivery_date]
        )
    )
RETURN
    DIVIDE ( Late, COUNTROWS ( 'Orders' ) )

Note DIVIDE instead of a slash. A reviewer notices, because it means you have hit a divide by zero inside a slicer before. Modelling and DAX of this kind are the backbone of 360DT's Data Analyst course, which builds this star schema live before touching a visual.

Deliverable: a .pbix file, three screenshots, and one paragraph naming the worst region for late delivery and what you would check next. Expect to be asked: why a star schema and not one wide table, what the date table does, and how the measure behaves when a filter returns no rows.

Also read: Power BI Tutorial for Beginners 2026 if you have never published a report, and Star Schema Explained for the modelling step in detail.

Project 2: Cohort Retention in One SQL File

The cheapest high signal project here. No dashboard, no notebook, no Python: one .sql file that runs against DuckDB and prints a retention matrix, plus a README explaining the numbers.

What SQL projects for data analyst roles should prove

Not JOIN syntax. The SQL projects for data analyst roles that land prove you can define a cohort without double counting, and that you reach for a window function where the alternative is a self join. Run it with duckdb :memory: < retention.sql from the folder holding the CSVs:

CREATE OR REPLACE VIEW ord AS
SELECT c.customer_unique_id                              AS cust,
       date_trunc('month', o.order_purchase_timestamp)   AS m
FROM read_csv_auto('olist_orders_dataset.csv')    o
JOIN read_csv_auto('olist_customers_dataset.csv') c USING (customer_id)
WHERE o.order_status = 'delivered';

WITH first_month AS (
  SELECT cust, min(m) AS cohort FROM ord GROUP BY cust
)
SELECT f.cohort,
       datediff('month', f.cohort, o.m)      AS month_index,
       count(DISTINCT o.cust)                AS actives,
       round(100.0 * count(DISTINCT o.cust)
             / max(count(DISTINCT o.cust))
                 OVER (PARTITION BY f.cohort), 1) AS pct_retained
FROM ord o
JOIN first_month f USING (cust)
GROUP BY 1, 2
ORDER BY 1, 2;

The subtlety worth writing up: Olist gives you customer_id, unique per order, and customer_unique_id, which identifies the person. Cohort on the wrong one and retention is near zero in every month. Document that bug. A project explaining a bug you found is worth three that never hit one.

Deliverable: retention.sql, the output table, two sentences on what the curve implies for a marketplace. Expect to be asked: why DISTINCT, what happens to the denominator if someone orders twice in month zero, and how you would make it incremental.

Project 3: The Data Quality Audit Nobody Else Is Building

This is the one I would build first if I had time for only one, because it shows what is hardest to fake. Pick an open dataset with real provenance, something off data.gov.in or a state transport feed, and write assertions that fail loudly.

# checks.py (run with: python -I checks.py)
import duckdb, sys

RULES = {
    "order_id is unique":
        "SELECT count(*) - count(DISTINCT order_id) FROM o",
    "delivery is never before purchase":
        "SELECT count(*) FROM o WHERE order_delivered_customer_date "
        "< order_purchase_timestamp",
    "freight is never negative":
        "SELECT count(*) FROM i WHERE freight_value < 0",
    "every item maps to a real order":
        "SELECT count(*) FROM i LEFT JOIN o USING (order_id) "
        "WHERE o.order_id IS NULL",
}

con = duckdb.connect()
con.execute("CREATE VIEW o AS SELECT * FROM "
            "read_csv_auto('olist_orders_dataset.csv')")
con.execute("CREATE VIEW i AS SELECT * FROM "
            "read_csv_auto('olist_order_items_dataset.csv')")

failures = 0
for name, sql in RULES.items():
    bad = con.execute(sql).fetchone()[0]
    print(f"{'PASS' if bad == 0 else 'FAIL'}  {name}  ({bad} rows)")
    failures += bad > 0

sys.exit(1 if failures else 0)

Wire it into GitHub Actions so the README badge goes red when a rule breaks. Now the repo is not a snapshot, it holds an opinion about the data. Testing data you do not control is a core data engineering habit, and a live Microsoft Fabric program drills the same pattern inside pipelines.

Deliverable: checks.py, a CI workflow, and a one page scorecard giving each rule, its pass rate and the consequence of it failing.

Project 4: Incremental Parquet Ingestion When the Schema Moves

The New York City Taxi and Limousine Commission publishes trip records as Parquet, one file per month, and its data page says releases run roughly two months behind to allow for vendor submissions. It also warns that columns have changed, with a congestion fee field added from 2025. A naive glob across all years therefore breaks, which is why this makes a good project.

-- Columns differ across years, so union by name instead of position.
SELECT strftime(tpep_pickup_datetime, '%Y-%m') AS month,
       count(*)                                AS trips,
       round(avg(trip_distance), 2)            AS avg_miles
FROM read_parquet('tlc/yellow_tripdata_202*.parquet',
                  union_by_name = true)
WHERE trip_distance BETWEEN 0.1 AND 100
GROUP BY 1
ORDER BY 1;

Then make it incremental: a Python wrapper that records which months are loaded, fetches only new files, and refuses to load a month twice. Idempotency comes up in nearly every data interview, and you will have an answer with a file path in it.

Deliverable: a loader, a manifest of loaded months, and a note on how many rows the distance filter drops and why. Expect to be asked: what happens when a month is republished with corrections.

Project 5: Kill a Manual Monthly Excel Report

State the scenario honestly as invented: a two person MIS team rebuilds a branch performance workbook by hand on the first working day of every month, taking six hours. Your project replaces it. Generate plausible source data, write the transformation in Python, and emit the workbook they expect, with their sheet names and number formats, because that is what real users refuse to compromise on.

Least glamorous build on the list, most likely to get a callback. Most analyst work is not a model. It is taking something somebody does badly every month and making it happen on its own. Coming from finance or operations, your domain knowledge does the heavy lifting.

Deliverable: the script, a sample workbook, a before and after timing note, and a paragraph on what you would still do by hand. Expect to be asked: how you handle the month the branch list changes.

Project 6: One Decision Memo, Published as an App

The hardest and most differentiating build, because it ends in a recommendation rather than a visual. Pick one question with a real answer, such as whether free shipping above a threshold pays for itself on the Olist data, and write two pages: question, method, number, uncertainty, recommendation. Then publish a Streamlit app that lets a reader move the threshold.

Streamlit's docs cap a Community Cloud app at 2.7 GB of memory and 2 CPU cores, and apps with no traffic for 12 hours go to sleep. Both are fine here. Precompute aggregates into a DuckDB file instead of reading raw CSVs at startup and the sleeping app wakes in seconds.

My view on the AI angle: bolting a chatbot onto this adds nothing a reviewer values, because the hard part was the margin maths. To show you can work with large language models, make that a separate project with its own retrieval and evaluation story, which the AI Engineer course covers properly.

Deliverable: memo.md, the app URL, and the DuckDB file behind it. Expect to be asked: what would change your recommendation.

How to Choose Data Analyst Portfolio Projects If You Have 30 Hours

Thirty spare hours a month is roughly what a working professional has. That buys two projects done properly, and my recommendation is specific: build project 1 and project 3. One shows you can model and present, the other that you find problems nobody pointed you at. If you work in operations, finance or MIS, swap project 1 for project 5.

Data analyst projects for beginners: what to fix first

Most data analyst projects for beginners fail on presentation, not analysis. Fix these four before you add a fifth repo.

How These Projects Map to the PL-300 Exam

These builds double as revision for the Microsoft Power BI Data Analyst exam. The Microsoft Learn study guide for PL-300 lists four skill areas, and the version effective 20 April 2026 renames the fourth to "Manage and secure Power BI" at 15 to 20%, with the other three at 25 to 30% each.

That last row is the honest gap. Workspace roles, row level security and deployment pipelines are hard to practise alone on a free tenant, which is where structured certification training earns its fee. Our certification versus projects comparison weighs the exam against more build time. If your builds pull you toward pipelines, a live AWS architecture and DevOps program beats a seventh dashboard.

Related guides

• Data Analyst Roadmap 2026 the learning sequence these projects sit inside.
• PL-300 Exam Prep 2026 a six week plan for the one skill area your projects will not cover.
• Data Analyst Salary in India 2026 what these roles actually pay.
• Power BI vs Tableau in 2026 decide which tool your portfolio uses.
• Data Analyst Jobs in Pune 2026 one real market, with a 90 day application plan.

Frequently asked questions

In your position with a month of evenings, I would build the star schema dashboard, write the quality audit, and spend the last weekend on the two READMEs rather than starting a third repo. The modelling gets you shortlisted; the audit is what you talk about in the room. To have someone check the model before you publish, the live Data Analyst course runs these builds in class on weekends, and a free webinar tests the teaching first.

About this guide. 360 Digital Transformation is an Anthropic Partner and a Microsoft Authorized Training Partner. Other certification bodies, vendors and employers named here are not affiliated with us. Tools and versions change quickly; commands and figures cited were checked on 27 October 2026.