When working with SQL, one of the key skills that separates intermediate developers from advanced database professionals is knowing how and when to use different query structures.

Three of the most commonly misunderstood SQL components are subqueries, Common Table Expressions (CTEs), and stored procedures. While they might seem similar at first glance — all allow you to organize or modularize your logic — they serve different purposes and have different performance implications.

In this article, I’ll break down each concept, highlight where it shines, and show some real-world examples from my own experience.

1. Subquery — A Query Within a Query

A subquery is simply a query nested inside another SQL statement. It’s often used to filter, calculate, or compare values dynamically.

Example
SELECT
EmployeeName,
Salary
FROM Employees
WHERE Salary > (
SELECT AVG(Salary) FROM Employees
);

In this example, the inner query calculates the average salary, and the outer query selects only employees earning more than that.

This pattern is great for short, inline calculations or when you don’t want to repeat the same logic elsewhere.

When to Use a Subquery

When you need a quick, one-off result from another table or calculation.

When joining tables would make the main query unnecessarily complex.

When readability and simplicity are more important than reusability.

Limitations

Subqueries can be less efficient than joins in some databases because they execute repeatedly for each row (depending on the optimizer).

They can’t always be reused elsewhere in the same query.

Deeply nested subqueries can make debugging painful.

1. CTE (Common Table Expression) — A Temporary Result Set

A CTE, introduced in SQL Server 2005 and supported by most modern databases, allows you to define a temporary, named result set that can be referenced within the same statement.

Example

WITH DepartmentAverage AS (
SELECT DepartmentID, AVG(Salary) AS AvgSalary
FROM Employees
GROUP BY DepartmentID
)
SELECT
e.EmployeeName,
e.DepartmentID,
e.Salary,
d.AvgSalary
FROM Employees e
JOIN DepartmentAverage d
ON e.DepartmentID = d.DepartmentID
WHERE e.Salary > d.AvgSalary;

Here, the CTE DepartmentAverage calculates each department’s average salary once, and the outer query uses it to find above-average earners.

This approach is more readable and maintainable than embedding multiple subqueries.

When to Use a CTE

When you want to organize complex queries into readable logical blocks.

When you need to reference the same derived result multiple times within one query.

When working with recursive queries (e.g., hierarchical data like org charts).

Limitations

CTEs exist only during the execution of the query; they are not stored permanently.

They don’t automatically improve performance (they’re mainly about readability and structure).

For very large datasets, a temporary table might perform better.

1. Stored Procedure — Precompiled Logic on the Server

A stored procedure is a precompiled, reusable block of SQL logic stored in the database. Unlike subqueries or CTEs, which are part of a single query, a stored procedure is a stand-alone database object.

Example

CREATE PROCEDURE GetHighEarners
@MinSalary INT
AS
BEGIN
SELECT EmployeeName, Salary, DepartmentID
FROM Employees
WHERE Salary > @MinSalary;
END;

EXEC GetHighEarners @MinSalary = 80000;

This approach is efficient and scalable, especially for complex business logic that runs frequently.

When to Use a Stored Procedure

When you need to encapsulate logic and reuse it across multiple applications.

When you want to improve performance through precompilation.

When enforcing security or access control — users can execute procedures without seeing the underlying tables.

When building ETL processes, batch jobs, or automated reporting.

Limitations

Stored procedures require database-level maintenance — not ideal for ad-hoc queries.

They can become hard to version-control if business logic changes often.

They’re specific to a database engine (e.g., T-SQL for SQL Server, PL/pgSQL for PostgreSQL).

1. My Take — Choosing the Right One

In practice, I use all three, depending on the situation:

Subqueries for quick filters or checks.

CTEs when readability matters and I want to logically break a big query into parts.

Stored procedures when I’m implementing repeatable or parameterized business logic.

There’s no universal “best” — it depends on whether you’re optimizing for performance, maintainability, or reuse.

The key is to understand how each behaves under the hood so you can choose the right tool for the job.

Final Thoughts

Think of it like this:

A subquery is a snippet of logic.

A CTE is a named snippet.

A stored procedure is a function you can call again and again.

Mastering when to use each will make your SQL code not only faster but also more elegant and maintainable.