Blog/How to Learn SQL for Jobs in India: A Practical Path

How to Learn SQL for Jobs in India: A Practical Path

A six-stage path to learn SQL for jobs, with tested example queries, official documentation and proof you can show.

Last updated: 21 September 2026 · By the Asuraa Team

How do you learn SQL for jobs?

Learn SQL by asking questions of a real database, in a fixed order: read rows, filter, sort, summarise, combine tables, then compare rows with window functions. The order matters because each stage uses the one before it.

Do not wait until you feel ready to type queries. Install a database first, load a tiny table and run every example yourself.

Where should you practise?

Use SQLite or PostgreSQL. Both are free, and both have official documentation you can trust.

The PostgreSQL tutorial says it is meant to give an introduction to PostgreSQL, relational database concepts and the SQL language, and that no particular programming experience is required. Its chapters cover installing and creating a database, the SQL language (tables, rows, queries, joins, aggregates, updates, deletions) and advanced features such as views, transactions and window functions.

SQLite needs no server, which makes it quick for a first week. Python includes a sqlite3 module, so you can run all the examples below from a script.

What are the stages, and what job task does each one match?

Every stage below maps to something an analyst or backend developer does at work. Use the table as a checklist.

StageYou learnA job task it covers
1SELECT, WHERE, ORDER BYPull the rows a manager asked for
2COUNT, SUM, AVG, GROUP BY, HAVINGCount openings by city, or find repeated values
3INNER and LEFT JOINCombine two tables, and keep rows with no match
4Subqueries, NOT EXISTSFind records that lack a related record
5Window functionsRank or number rows within a group
6Design basics, indexes, transactionsRead and write to a real application database

What does each stage look like in practice?

The example uses a small table of job openings and a table of applications. It is made-up data, used only as an illustration. We ran every query below in SQLite 3.45.1 before publishing.

Set up the data:

CREATE TABLE openings (id INTEGER PRIMARY KEY, title TEXT, city TEXT, skill TEXT, posted_on TEXT);
INSERT INTO openings VALUES
(1,'Data Analyst','Pune','SQL','2026-09-01'),
(2,'Data Analyst','Bengaluru','SQL','2026-09-03'),
(3,'Backend Developer','Pune','Python','2026-09-05'),
(4,'Data Analyst','Hyderabad','Excel','2026-09-07'),
(5,'ML Engineer','Bengaluru','Python','2026-09-08'),
(6,'Backend Developer','Chennai','Python','2026-09-10');
CREATE TABLE applications (id INTEGER PRIMARY KEY, opening_id INTEGER, status TEXT);
INSERT INTO applications VALUES (1,1,'applied'),(2,1,'interview'),(3,3,'applied'),(4,3,'rejected'),(5,3,'interview'),(6,5,'applied');

Stage 1: filter and sort. This returns the two openings that ask for SQL.

SELECT title, city FROM openings WHERE skill = 'SQL' ORDER BY city;

The output is Data Analyst in Bengaluru, then Data Analyst in Pune.

Stage 2: summarise. Count openings per city.

SELECT city, COUNT(*) AS n FROM openings GROUP BY city ORDER BY n DESC, city;

The output is Bengaluru 2, Pune 2, Chennai 1, Hyderabad 1. Add HAVING COUNT(*) >= 2 to a title-level version and you keep only titles that appear twice or more, which gives Backend Developer 2 and Data Analyst 3.

Stage 3: join. A LEFT JOIN keeps openings even when nobody has applied.

SELECT o.title, o.city, COUNT(a.id) AS n_apps
FROM openings o LEFT JOIN applications a ON a.opening_id = o.id
GROUP BY o.id ORDER BY n_apps DESC, o.id;

In our run, the Pune backend opening has 3 applications, the Pune analyst opening 2, the Bengaluru ML opening 1, and three openings have 0. An INNER JOIN would have dropped those last three rows.

Stage 4: find what is missing. This returns openings with no applications.

SELECT title, city FROM openings o
WHERE NOT EXISTS (SELECT 1 FROM applications a WHERE a.opening_id = o.id)
ORDER BY id;

It returns Data Analyst in Bengaluru, Data Analyst in Hyderabad and Backend Developer in Chennai.

Stage 5: window functions. Number each title's openings from newest to oldest.

SELECT title, city, posted_on,
       ROW_NUMBER() OVER (PARTITION BY title ORDER BY posted_on DESC) AS recency
FROM openings ORDER BY title, recency;

The SQLite documentation on window functions describes a window function as one where input values come from a "window" of one or more rows in the result set, and says it is marked by an OVER clause. It also notes that SQLite added window function support in version 3.25.0, released 2018-09-15.

Why does the order of clauses trip people up?

Because SQL is written in one order and processed in another. The SQLite SELECT documentation describes the logical order for a simple query: FROM, then WHERE, then GROUP BY and HAVING, then the result columns, then DISTINCT, then ORDER BY, then LIMIT.

That is why WHERE cannot filter on an aggregate such as COUNT(*), while HAVING can. The same page adds that this is illustrative, because no engine is required to follow it literally. Still, it is the right mental model for reading errors.

How long should each stage take?

Move on when you can write the stage's queries from a blank screen, not after a fixed number of days. Most learners spend the longest on joins and on NULL, which is why we suggest extra practice there. This is editorial advice, and your pace will differ.

For proof, finish with a project. Take a public dataset, write six to ten questions in plain English, answer each with a query, and store the queries plus a short written finding in a repository. Our post on data analyst portfolio projects shows how to package this.

What do most guides on learning SQL for jobs get wrong?

Many guides list clauses and stop. These are the common gaps.

  • They teach syntax with no database. Reading queries teaches recognition, and only running them teaches recall.
  • They skip NULL and duplicates. In a quick SQLite check, WHERE a = NULL returned no rows while WHERE a IS NULL found the row, and duplicate rows silently change counts.
  • They treat all dialects as identical. SQLite, PostgreSQL and other systems differ in details, so check the manual for the one your target employer uses.
  • They stop before joins. Most job tasks need more than one table, so joins deserve the most practice. See our list of SQL interview questions for what to rehearse.

FAQ

How long does it take to learn SQL for a job?

It depends on your starting point and hours per week, so no fixed number is reliable. Plan by stages instead: filtering, aggregation, joins, subqueries and window functions. Move on when you can write each stage's queries from a blank screen, then finish with a small project.

Is SQL enough to get a job?

Sometimes, but it is usually one skill among several. Postings for analyst roles often list SQL alongside a spreadsheet tool, a visualisation tool or Python. Read the postings for your target role and treat SQL as the base you build on.

Which SQL database should a beginner use?

SQLite is the quickest way to start because it needs no server, and Python ships a module for it. PostgreSQL is a fuller system with an official tutorial that covers tables, joins, aggregates and window functions. Either is fine for learning the core.

Do I need to learn window functions for jobs?

They are worth learning after joins and grouping. The PostgreSQL tutorial includes window functions in its advanced features, and SQLite supports them from version 3.25.0. They help with ranking and comparisons inside groups, which analyst tasks and interviews often involve.

Should I learn SQL or Python first?

Start with the one your target role names most often, and learn the other soon after. Analyst roles often use both, and short alternating sessions work for many people. Our Python learning guide has a matching path.

How do I show SQL skills to a recruiter?

Publish a small project: a public dataset, six to ten plain-English questions, the query answering each, and a short written finding. Put it in a repository with a README. A recruiter can then read your queries and judge your reasoning directly.

Final thoughts

Learning SQL for a job means running queries in stages, from SELECT to joins to window functions, and proving it with one small analysis. Keep the official PostgreSQL and SQLite documentation open as your reference.

To see how your SQL projects read against a real posting, try the AI resume reviewer on asuraa.in. You can also read about SQL jobs in India and pair this guide with learning Python for jobs.

Related articles

Share this article

Continue Reading

Data Science Career Paths

Explore different career trajectories in data science and find your perfect fit.

Read article →

Building Your DS Portfolio

Learn how to create projects that impress hiring managers and showcase your skills.

Read article →

Salary Negotiation Guide

Get the compensation you deserve with our proven negotiation strategies.

Review Your Resume →