SQL Joins Practice Exercises: 15 Real Queries & Answers

In relational database systems, raw data is distributed across dozens of normalized tables to eliminate redundancy and maintain referential integrity. As an analyst or analytics engineer, your primary responsibility is assembling these decoupled tables back into unified, high-integrity analytical views.

Textbooks often introduce SQL joins using overlapping two-circle Venn diagrams. While Venn diagrams provide a basic geometric intuition for set overlap, they fail to explain true relational database operations. Real relational joins operate on Cartesian coordinate pairs, handle Cartesian fan-out, evaluate null-propagation flags, and require strict join predicate positioning.

This practice guide delivers 15 production-grade SQL join exercises across five progressively challenging tiers:

1. Level 1: INNER JOIN: Exact relational matching, multi-table order histories, and subscription billing runs.
2. Level 2: LEFT JOIN & Anti-Joins: Preserving base grains, detecting unengaged customers, and isolating dormant catalog inventory.
3. Level 3: RIGHT & FULL OUTER JOIN: Bidirectional ledger auditing, physical warehouse reconciliation, and catalog gap detection.
4. Level 4: SELF JOIN & Hierarchical Data: Managerial organizational trees, peer compensation variances, and consecutive activity detection.
5. Level 5: Advanced Multi-Table & Non-Equi Joins: Fan-out mitigation with Common Table Expressions (CTEs), promo code date-range matching, and Cartesian calendar spines.

For broader interview coverage, explore our companion compilation of 25 Real Business SQL Practice Questions or master fundamental querying in Topfolio SQL Basics Course. Every course on Topfolio is 100% free to learn, with an optional ₹99 verified certificate to validate your skills.

Visual Relational Architecture

The exercises in this guide query the enterprise schema below. Pay close attention to primary keys (PK), foreign keys (FK), and relationship cardinalities.

+----------------------------------------------------------------------------------------------------+
|                                    RELATIONAL JOIN ARCHITECTURE                                    |
+----------------------------------------------------------------------------------------------------+

    [ suppliers ]                              [ products ]
    +-------------------------+                 +-------------------------+
    | supplier_id (PK)        |<----------------| supplier_id (FK)        |
    | supplier_name VARCHAR   |                 | product_id (PK)         |
    | contact_email VARCHAR   |                 | product_name VARCHAR    |
    | country CHAR(2)         |                 | category VARCHAR        |
    +-------------------------+                 | price NUMERIC           |
                                                | stock_quantity INT      |
                                                +-------------------------+
                                                             ^
                                                             | (Foreign Key)
    [ customers ]              [ orders ]                    |
    +--------------------+     +--------------------+        |
    | customer_id (PK)   |<----| customer_id (FK)   |        |
    | first_name VARCHAR |     | order_id (PK)      |        |
    | last_name VARCHAR  |     | order_date DATE    |        |
    | email VARCHAR      |     | status VARCHAR     |        |
    | city VARCHAR       |     | total_amount NUM   |        |
    | state CHAR(2)      |     +--------------------+        |
    +--------------------+               ^                   |
                                         |                   |
                               [ order_items ]               |
                               +---------------------+       |
                               | order_item_id (PK)  |       |
                               | order_id (FK)-------+       |
                               | product_id (FK)-------------+
                               | quantity INT        |
                               | unit_price NUMERIC  |
                               +---------------------+

    [ employees ] (Self-Referencing Manager Hierarchy)
    +--------------------------------------------------------------------+
    | employee_id (PK) | first_name | last_name | department | salary    |
    | manager_id (FK) ---------------------------------------+ (Self-FK) |
    +--------------------------------------------------------|-----------+
                                                             v

Critical Cardinality Rules:

• customers to orders (1:N): One customer places zero, one, or many orders.
• orders to order_items (1:N): One order contains one or more line items.
• products to order_items (1:N): A product appears in zero or multiple order items.
• employees to employees (1:N Self-Join): One manager supervises multiple employees; employees have at most one manager.

SQL Join Operators Mechanics & NULL Behaviors

Before solving exercises, examine how PostgreSQL handles unmatched rows, NULL propagation, and join filters across each join type:

Part 1: Relational Foundations & Join Mechanics

Understanding joins requires looking at how relational engines process predicates during execution. When two tables join, PostgreSQL logically builds an intermediate virtual table.

The ON Clause vs The WHERE Clause Filter Trap

The single most common bug in intermediate SQL interviews involves putting filter predicates on the right table inside the WHERE clause instead of the ON clause:

-- WRONG: Inadvertently turns a LEFT JOIN into an INNER JOIN!
SELECT c.customer_id, c.first_name, o.order_id, o.status
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
WHERE o.status = 'completed';

Why this fails: A customer who has never ordered generates a row where o.status IS NULL. The WHERE o.status = 'completed' filter evaluates NULL = 'completed', which yields FALSE in three-valued SQL logic. As a result, all customers with zero orders are silently eliminated!

-- CORRECT: Preserves all customers while filtering joined orders
SELECT c.customer_id, c.first_name, o.order_id, o.status
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
                   AND o.status = 'completed';

In the correct version, if a customer has no completed orders, the customer row is still preserved with NULL in the order fields. For a deeper study of logical execution order, review our guide to SQL Order of Execution.

Part 2: 15 Comprehensive SQL Join Exercises

Each exercise includes sample input data, the business problem statement, the PostgreSQL query, an explanation of the join mechanics, and the expected output table.

Exercise 1: Customer Order History & Fulfillment Status (INNER JOIN)

Business Scenario: The customer support portal requires an order lookup tool. For all orders with a status of 'completed' or 'shipped', retrieve the customer's full name, email address, order ID, order date, and total dollar amount.

Input Tables:

customers (sample rows):

orders (sample rows):

PostgreSQL Solution Query:

SELECT 
    c.first_name || ' ' || c.last_name AS customer_name,
    c.email,
    o.order_id,
    o.order_date,
    o.status,
    o.total_amount
FROM customers AS c
INNER JOIN orders AS o ON c.customer_id = o.customer_id
WHERE o.status IN ('completed', 'shipped')
ORDER BY o.order_date DESC;

Logic Breakdown:

• c.customer_id = o.customer_id matches customers to their specific orders.
• Customer 102 placed order 5002, but its status is 'pending', so it is excluded by the WHERE clause.
• Order 5004 belongs to customer 104 (not in our customer table snippet); an INNER JOIN discards any order lacking a valid matching customer record.

Expected Output Table:

Exercise 2: Supplier Catalog & Product Sourcing (INNER JOIN)

Business Scenario: Procurement needs to renegotiate vendor contracts. Generate a list of all active products whose unit price exceeds $100.00, showing product name, category, unit price, supplier company name, and supplier contact email.

Input Tables:

suppliers (sample rows):

products (sample rows):

PostgreSQL Solution Query:

SELECT 
    p.product_id,
    p.product_name,
    p.category,
    p.price,
    s.supplier_name,
    s.contact_email
FROM products AS p
INNER JOIN suppliers AS s ON p.supplier_id = s.supplier_id
WHERE p.price > 100.00
ORDER BY p.price DESC;

Logic Breakdown:

• Joins the child table products to parent table suppliers on p.supplier_id = s.supplier_id.
• The Basic Mouse Pad matches supplier 10, but its price ($14.99) fails the p.price > 100.00 filter.
• Returns only high-value catalog items linked with verified supplier contact information.

Expected Output Table:

Exercise 3: Active Subscription Billing Run (Multi-Table INNER JOIN)

Business Scenario: SaaS Finance needs to audit the monthly recurring billing batch. Join user accounts, subscription records, and plan tiers to calculate the monthly invoice amount for all users whose subscription status is 'active'.

Input Tables:

users (sample rows):

subscriptions (sample rows):

plans (sample rows):

PostgreSQL Solution Query:

SELECT 
    u.user_id,
    u.user_name,
    u.billing_email,
    p.plan_name,
    p.monthly_fee
FROM users AS u
INNER JOIN subscriptions AS s ON u.user_id = s.user_id
INNER JOIN plans AS p ON s.plan_id = p.plan_id
WHERE s.status = 'active'
ORDER BY p.monthly_fee DESC;

Logic Breakdown:

• Two sequential INNER JOIN operations: users links to subscriptions on user_id, and subscriptions links to plans on plan_id.
• User 802 has a subscription record, but its status is 'cancelled', so it is excluded by the WHERE clause.
• Only active accounts with valid plan configurations are output.

Expected Output Table:

Exercise 4: Unengaged Customer Detection (LEFT Anti-Join)

Business Scenario: Lifecycle marketing is preparing a re-engagement email series. Identify all registered customers who have never placed an order. Return their customer ID, full name, email, and registration date.

Input Tables:

customers (sample rows):

orders (sample rows):

PostgreSQL Solution Query:

SELECT 
    c.customer_id,
    c.first_name || ' ' || c.last_name AS customer_name,
    c.email,
    c.signup_date
FROM customers AS c
LEFT JOIN orders AS o ON c.customer_id = o.customer_id
WHERE o.order_id IS NULL
ORDER BY c.signup_date ASC;

Logic Breakdown:

• The LEFT JOIN preserves every customer in the output. For customers without matching orders (Ford Prefect and Marvin Android), the engine creates a virtual row where all columns from orders are set to NULL.
• The predicate WHERE o.order_id IS NULL filters out customers who have placed orders, leaving only the unengaged cohort.
• This is the standard relational anti-join pattern.

Expected Output Table:

Exercise 5: Dormant Catalog Inventory / Products Never Ordered (LEFT Anti-Join)

Business Scenario: Warehouse inventory managers want to identify dormant stock. Find all products in the catalog that have never been purchased in any order line item. Display the product ID, product name, category, unit price, and current stock count.

Input Tables:

products (sample rows):

order_items (sample rows):

PostgreSQL Solution Query:

SELECT 
    p.product_id,
    p.product_name,
    p.category,
    p.price,
    p.stock_quantity
FROM products AS p
LEFT JOIN order_items AS oi ON p.product_id = oi.product_id
WHERE oi.order_item_id IS NULL
ORDER BY p.stock_quantity DESC;

Logic Breakdown:

• Joins products to order_items using LEFT JOIN.
• Products 501 and 502 have matching line items, so oi.order_item_id contains numeric IDs.
• Products 503 and 504 have zero sales history, yielding NULL for oi.order_item_id.
• The WHERE oi.order_item_id IS NULL clause extracts the dormant inventory items.

Expected Output Table:

Exercise 6: Churn Detection with ON-Clause Temporal Predicates (LEFT JOIN)

Business Scenario: Retention managers need a list of active enterprise accounts that have logged zero user events over the past 30 days (from cutoff date 2024-04-30).

Input Tables:

accounts (sample rows):

usage_events (sample rows):

PostgreSQL Solution Query:

SELECT 
    a.account_id,
    a.company_name,
    a.plan_type
FROM accounts AS a
LEFT JOIN usage_events AS e 
    ON a.account_id = e.account_id
   AND e.event_date >= '2024-04-01'
   AND e.event_date <= '2024-04-30'
WHERE a.plan_type = 'Enterprise'
  AND e.event_id IS NULL
ORDER BY a.account_id ASC;

Logic Breakdown:

• The date range filter is intentionally placed inside the ON clause. This ensures accounts with events outside the 30-day window (like Globex, whose event was in February) evaluate to NULL for the join without getting filtered out of the left table.
• Account 1 has events inside April, so e.event_id is not null.
• Accounts 2 and 3 have no April events; their e.event_id is null, correctly flagging them as inactive.

Expected Output Table:

Exercise 7: Warehouse Inventory vs Central Catalog Audit (FULL OUTER JOIN)

Business Scenario: A supply chain team is reconciling physical warehouse scanner counts against the central ERP product catalog. Identify all discrepancies: products present in the catalog but missing from warehouse scans, and uncataloged barcode items found in the warehouse.

Input Tables:

central_catalog (sample rows):

warehouse_inventory (sample rows):

PostgreSQL Solution Query:

SELECT 
    COALESCE(c.sku, w.sku) AS resolved_sku,
    c.product_title,
    c.catalog_price,
    w.physical_count,
    w.bay_location,
    CASE 
        WHEN c.sku IS NOT NULL AND w.sku IS NOT NULL THEN 'Matched / Verified'
        WHEN c.sku IS NOT NULL AND w.sku IS NULL THEN 'Missing in Warehouse'
        WHEN c.sku IS NULL AND w.sku IS NOT NULL THEN 'Uncataloged Inventory'
    END AS audit_status
FROM central_catalog AS c
FULL OUTER JOIN warehouse_inventory AS w ON c.sku = w.sku
ORDER BY resolved_sku ASC;

Logic Breakdown:

• A FULL OUTER JOIN preserves all rows from both tables.
• COALESCE(c.sku, w.sku) returns the valid SKU regardless of which side matched.
• The CASE WHEN statement uses NULL checks to categorize each item into one of three audit buckets: verified, missing stock, or untracked stock.

Expected Output Table:

Exercise 8: Omnichannel Transaction Ledger Reconciliation (FULL OUTER JOIN)

Business Scenario: Financial audit requires reconciling payment processor credit card authorizations against bank settlement deposits. Find all unmatched transaction references (authorized charges with no bank deposit, or bank deposits with no matching processor authorization).

Input Tables:

gateway_transactions (sample rows):

bank_settlements (sample rows):

PostgreSQL Solution Query:

SELECT 
    COALESCE(g.ref_num, b.ref_num) AS reconciliation_reference,
    g.auth_amount,
    b.settled_amount,
    CASE 
        WHEN g.ref_num IS NULL THEN 'Unmatched Bank Deposit'
        WHEN b.ref_num IS NULL THEN 'Unsettled Gateway Charge'
    END AS discrepancy_reason
FROM gateway_transactions AS g
FULL OUTER JOIN bank_settlements AS b ON g.ref_num = b.ref_num
WHERE g.ref_num IS NULL OR b.ref_num IS NULL
ORDER BY reconciliation_reference ASC;

Logic Breakdown:

• The FULL OUTER JOIN pairs matching transaction references.
• The WHERE g.ref_num IS NULL OR b.ref_num IS NULL clause strips away matched transactions (TXN-101 and TXN-103), isolating only the unbalanced ledger exceptions.

Expected Output Table:

Exercise 9: Regional Sales Territories vs Active Sales Reps (RIGHT JOIN)

Business Scenario: Sales leadership is restructuring geographic regions. List all designated sales territories along with the name of the assigned sales representative. Include any territory that currently has no assigned rep.

Input Tables:

sales_reps (sample rows):

territories (sample rows):

PostgreSQL Solution Query:

SELECT 
    t.territory_id,
    t.territory_name,
    t.target_quota,
    COALESCE(r.rep_name, 'Unassigned Territory') AS assigned_rep
FROM sales_reps AS r
RIGHT JOIN territories AS t ON r.territory_id = t.territory_id
ORDER BY t.territory_id ASC;

Logic Breakdown:

• The RIGHT JOIN guarantees that every record in territories is preserved in the output, even if no sales rep is assigned to that territory ID.
• Territory 30 (Great Lakes) has no matching row in sales_reps, so r.rep_name evaluates to NULL.
• COALESCE provides a clean label for unassigned regions.
• Senior Engineering Tip: Most data teams refactor RIGHT JOIN queries to LEFT JOIN (FROM territories t LEFT JOIN sales_reps r ...) because reading queries from left to right improves code maintainability.

Expected Output Table:

Exercise 10: Complete Management Reporting Hierarchy (SELF JOIN)

Business Scenario: HR requires a company directory mapping every employee to their direct supervisor. The top executive has no manager (manager_id IS NULL) and should display 'Executive Leadership'.

Input Table:

employees (sample rows):

PostgreSQL Solution Query:

SELECT 
    e.employee_id,
    e.first_name || ' ' || e.last_name AS employee_name,
    e.department,
    COALESCE(m.first_name || ' ' || m.last_name, 'Executive Leadership') AS manager_name
FROM employees AS e
LEFT JOIN employees AS m ON e.manager_id = m.employee_id
ORDER BY e.employee_id ASC;

Logic Breakdown:

• A self-join queries the same table twice using two distinct table aliases: e represents the individual employee, and m represents their respective manager.
• The join condition e.manager_id = m.employee_id links the subordinate's foreign key to the supervisor's primary key.
• A LEFT JOIN preserves the CEO (Bruce Wayne), whose manager_id is null.

Expected Output Table:

Exercise 11: Peer Salary Discrepancies within Departments (SELF JOIN)

Business Scenario: Compensation analysts are auditing salary equity. Find all instances where an employee earns strictly less than a colleague in the same department who was hired in the exact same calendar year.

Input Table:

employees (sample rows):

PostgreSQL Solution Query:

SELECT 
    e.employee_id,
    e.first_name AS employee_name,
    e.department,
    e.salary AS employee_salary,
    peer.first_name AS higher_earning_peer,
    peer.salary AS peer_salary,
    peer.salary - e.salary AS salary_difference
FROM employees AS e
INNER JOIN employees AS peer 
    ON e.department = peer.department
   AND EXTRACT(YEAR FROM e.hire_date) = EXTRACT(YEAR FROM peer.hire_date)
   AND e.salary < peer.salary
ORDER BY e.department, salary_difference DESC;

Logic Breakdown:

• Joins employees to itself using multiple predicates: matching department, matching hire year via EXTRACT(YEAR FROM ...), and a non-equi condition e.salary < peer.salary.
• Alice and Bob were both hired in 2023 in Engineering; because Alice earns less than Bob, a row is generated showing the $15,000 difference.
• Charlie was hired in 2022, so he has no peers from his cohort in this dataset.

Expected Output Table:

Exercise 12: Consecutive Day User Activity Detection (SELF JOIN)

Business Scenario: Gaming analytics tracks user retention streaks. Identify all users who logged into the platform on two consecutive calendar days, without relying on window functions.

Input Table:

user_logins (sample rows):

PostgreSQL Solution Query:

SELECT DISTINCT 
    curr.user_id,
    curr.login_date AS first_day,
    next_day.login_date AS consecutive_day
FROM user_logins AS curr
INNER JOIN user_logins AS next_day 
    ON curr.user_id = next_day.user_id
   AND next_day.login_date = curr.login_date + INTERVAL '1 day'
ORDER BY curr.user_id, first_day ASC;

Logic Breakdown:

• Joins user_logins to itself on matching user_id.
• The temporal join predicate next_day.login_date = curr.login_date + INTERVAL '1 day' tests for records on the following calendar day.
• User 501 logged in on both April 10 and 11, satisfying the join condition. User 502 logged in on April 10 and 12 (a two-day gap), so no row is returned.

Expected Output Table:

Exercise 13: Multi-Table Revenue Aggregation without Fan-Out (Advanced CTE Join)

Business Scenario: Executive reporting requires customer order counts alongside their total units purchased. Avoid the join fan-out trap that inflates parent order totals when joining child line-item records.

Input Tables:

customers (sample rows):

orders (sample rows):

order_items (sample rows):

PostgreSQL Solution Query:

WITH customer_orders AS (
    SELECT 
        customer_id,
        COUNT(order_id) AS total_orders,
        SUM(order_total) AS true_order_revenue
    FROM orders
    GROUP BY customer_id
),
customer_items AS (
    SELECT 
        o.customer_id,
        SUM(oi.quantity) AS total_units_purchased
    FROM orders AS o
    INNER JOIN order_items AS oi ON o.order_id = oi.order_id
    GROUP BY o.customer_id
)
SELECT 
    c.customer_id,
    c.customer_name,
    COALESCE(co.total_orders, 0) AS total_orders,
    COALESCE(co.true_order_revenue, 0.00) AS true_order_revenue,
    COALESCE(ci.total_units_purchased, 0) AS total_units_purchased
FROM customers AS c
LEFT JOIN customer_orders AS co ON c.customer_id = co.customer_id
LEFT JOIN customer_items AS ci ON c.customer_id = ci.customer_id
ORDER BY true_order_revenue DESC;

Logic Breakdown:

• In naive queries that join orders directly to order_items, order 201 is duplicated across its two child rows, multiplying order_total from $100.00 to $200.00!
• Pre-aggregating orders and line items into separate Common Table Expressions (CTEs) before joining them back to the customer preserves data grains and prevents inflation.
• For a deep dive into this interview pattern, read our dedicated guide on SQL JOIN Fan-Out: Fixing Duplicate Rows & Broken SUM.

Expected Output Table:

Exercise 14: Promotional Pricing Discount Range Matching (Non-Equi BETWEEN Join)

Business Scenario: The marketing operations team launched several targeted discount campaigns. Re-evaluate customer purchases by joining orders to the promotions table to find the applicable discount percentage based on order date and product category.

Input Tables:

orders (sample rows):

promotions (sample rows):

PostgreSQL Solution Query:

SELECT 
    o.order_id,
    o.category,
    o.order_date,
    o.gross_amount,
    COALESCE(p.promo_name, 'No Promotion Applied') AS promotion_applied,
    COALESCE(p.discount_pct, 0.00) AS discount_percentage,
    ROUND(
        o.gross_amount * (1.0 - COALESCE(p.discount_pct, 0.00) / 100.0), 
        2
    ) AS net_discounted_amount
FROM orders AS o
LEFT JOIN promotions AS p 
    ON o.category = p.category
   AND o.order_date BETWEEN p.start_date AND p.end_date
ORDER BY o.order_id ASC;

Logic Breakdown:

• This is a non-equi join: the join condition uses BETWEEN p.start_date AND p.end_date alongside category equality.
• Order 1 falls within the Spring Audio Fest window (March 15) and receives a 15% discount.
• Order 2 is in the Audio category, but was placed in April (after the promo ended), so it receives no discount.
• COALESCE handles orders without matching promotions by falling back to 0% discount.

Expected Output Table:

Exercise 15: Zero-Filled Sales Calendar Spine (CROSS JOIN + LEFT JOIN)

Business Scenario: Executive dashboards require a daily sales trend for the launch week of April 1–4, 2024. If a category had zero sales on a given day, it must display $0.00 rather than disappearing from the report.

Input Tables:

calendar_days (generated via PostgreSQL generate_series):

categories (sample rows):

orders (sample rows):

PostgreSQL Solution Query:

WITH date_spine AS (
    SELECT generate_series(
        '2024-04-01'::DATE, 
        '2024-04-04'::DATE, 
        INTERVAL '1 day'
    )::DATE AS report_date
),
category_list AS (
    SELECT DISTINCT category AS category_name FROM orders
),
reporting_matrix AS (
    -- CROSS JOIN builds every date × category combination
    SELECT 
        d.report_date,
        c.category_name
    FROM date_spine AS d
    CROSS JOIN category_list AS c
)
SELECT 
    m.report_date,
    m.category_name,
    COALESCE(SUM(o.amount), 0.00) AS daily_revenue
FROM reporting_matrix AS m
LEFT JOIN orders AS o 
    ON m.report_date = o.order_date
   AND m.category_name = o.category
GROUP BY m.report_date, m.category_name
ORDER BY m.category_name, m.report_date ASC;

Logic Breakdown:

• Real-world transactional tables omit rows for days with no activity. Joining raw orders directly would skip those dates entirely.
• A CROSS JOIN between a date spine and a category list generates a baseline grid containing every combination (4 days × 2 categories = 8 rows).
• A LEFT JOIN from this reporting matrix to orders attaches transaction totals where they exist.
• COALESCE(SUM(o.amount), 0.00) replaces NULL values with $0.00 for zero-sales days, producing a complete time series ready for visualization.

Expected Output Table:

4 Common SQL Join Interview Traps

During technical interviews, hiring teams evaluate whether you understand edge cases and performance trade-offs:

1. The Cartesian Explosion (Missing Join Condition): Omitting the ON clause or joining on non-unique keys without sufficient constraints causes a full Cartesian product ($N \times M$ rows), exhausting database memory.
2. Accidental Inner Joins via WHERE Predicates: As covered in Part 1, filtering nullable right-table columns in the WHERE clause strips out unmatched left rows, defeating the purpose of a LEFT JOIN.
3. Double-Counting Aggregate Fan-Out: Summing parent amounts across a one-to-many join multiplies values by the number of matching child rows. Always pre-aggregate in CTEs first.
4. Three-Valued Logic in Anti-Joins: When using NOT IN (SELECT id FROM ...) with subqueries, if the subquery returns a single NULL, the entire predicate evaluates to UNKNOWN and returns zero records! Use NOT EXISTS or LEFT JOIN ... WHERE right.id IS NULL instead.

Master Advanced SQL Joins with Topfolio

True SQL proficiency comes from diagnosing query errors, reviewing query plans, and practicing joins against live relational schemas.

Continue your journey with Topfolio's guided curricula:

• SQL Basics Course: Master table creation, filtering, aggregations, and joins.
• Advanced SQL Analytics Course: Master window functions, CTE recursion, and query plan optimization.
• Free SQL Course Sandbox: Solve live challenges directly in your browser with automated grading.

Every lesson and practice exercise on Topfolio is 100% free to learn. You can also earn an optional ₹99 verified certificate to showcase your technical SQL capabilities to hiring managers on LinkedIn.