SQL Basics: The Queries Every Beginner Should Actually Know

You don't need to be a backend developer to benefit from SQL — a marketer who can pull their own numbers, a product manager who can check a user count directly, and a data analyst all lean on the same handful of queries. Here are the ten that cover most real-world use.

Setting Up a Free Practice Database

You don't need to install anything to start. SQLite's online playground, or a free PostgreSQL instance on a platform like Neon or Supabase, both let you run real queries against sample data in a browser within minutes.

1. SELECT — Get Data From a Table

SELECT name, email FROM users;

Pulls specific columns instead of everything. Avoid SELECT * in real applications — it pulls columns you don't need and breaks silently if the table structure changes later.

2. WHERE — Filter Rows

SELECT * FROM orders WHERE status = 'delivered';

Combine conditions with AND / OR: WHERE status = 'delivered' AND total > 500.

3. ORDER BY — Sort Results

SELECT * FROM products ORDER BY price DESC;

DESC for highest first, ASC (the default) for lowest first.

4. LIMIT — Cap the Results

SELECT * FROM users ORDER BY created_at DESC LIMIT 10;

Combined with ORDER BY, this is how you get "the 10 most recent" anything — one of the most common real query patterns.

5. COUNT, SUM, AVG — Aggregate Functions

SELECT COUNT(*) FROM orders WHERE status = 'delivered';
SELECT SUM(total) FROM orders WHERE status = 'delivered';
SELECT AVG(total) FROM orders;

Answers "how many," "how much in total," and "what's the average" — the three questions behind most basic reporting.

6. GROUP BY — Aggregate Per Category

SELECT status, COUNT(*) FROM orders GROUP BY status;

Instead of one total, this returns a count for each distinct status — delivered, pending, cancelled — in one query.

7. JOIN — Combine Data From Two Tables

SELECT orders.id, users.name
FROM orders
JOIN users ON orders.user_id = users.id;

Real data is rarely in one table. This pulls the customer's name alongside their order by matching user_id in orders to id in users — the single most-used query type once your data has any real structure.

8. DISTINCT — Remove Duplicates

SELECT DISTINCT country FROM users;

Returns each unique value once — useful for answering "which countries do we have users in" without a repeated row per user.

9. INSERT, UPDATE, DELETE — Changing Data

INSERT INTO users (name, email) VALUES ('Asha', 'asha@example.com');
UPDATE users SET email = 'new@example.com' WHERE id = 42;
DELETE FROM users WHERE id = 42;

Always pair UPDATE and DELETE with a specific WHERE clause. Running either without one changes or removes every row in the table — a mistake that has taken down real production databases.

10. Subqueries — A Query Inside a Query

SELECT name FROM users
WHERE id IN (SELECT user_id FROM orders WHERE total > 5000);

Finds users who have at least one order over ₹5,000, by nesting an "orders" query inside a "users" query. This is where SQL starts feeling less like memorized syntax and more like a genuine problem-solving tool.

A Practice Exercise to Try

Using a sample orders/users database (most free SQL playgrounds include one), try writing: "the top 5 customers by total amount spent." It requires a JOIN, a GROUP BY, a SUM, an ORDER BY, and a LIMIT — nearly everything above, in one query.

Mistakes Beginners Make

• Forgetting WHERE on an UPDATE or DELETE — always run a SELECT with the same condition first to confirm which rows you're about to affect
• Using SELECT * in real applications instead of naming the columns you actually need
• Mixing up WHERE and HAVING — WHERE filters rows before grouping, HAVING filters after a GROUP BY
• Not indexing columns used in WHERE and JOIN clauses on large tables, which slows queries down as data grows

Frequently Asked

Next Steps

These ten queries cover a genuine majority of day-to-day SQL work. From here, practice against a real dataset rather than reading more syntax — writing queries against actual messy data is what makes the concepts stick.