How long does it take to learn SQL?
About 47 hours of focused work covers 26 skills, from a first SELECT to window frames and query plans. At five hours a week that is around ten weeks; at one hour a week it is closer to a year. Hours are the honest unit here. The calendar is not.
Tell it how many hours a week you actually have and it prices the same 26 skills against your pace, in weeks, with the checkpoints dated.
Put your own hours inThe number is hours, and only you own the second number
Every "learn SQL in X weeks" headline is doing the same trick: it picks a weekly pace for you, hides it, and prints the result. The pace is the part that varies by a factor of ten between two real people, so the result is the least reliable half of the sentence.
Our own SQL course is 47 hours across 26 skills. That figure is the sum of the per-skill estimates in the course itself, not a marketing number — it moves when the course does. What it turns into on a calendar is entirely about the hours you genuinely have, and the honest version of the answer shows its working.
- Ten hours a week — about five weeks, if the ten hours are real.
- Five hours a week — about ten weeks. This is the common case.
- Two hours a week — about six months.
- One hour a week — about a year, and you will lose ground between sessions unless you review.
Why the published estimates are all wrong in the same direction
They measure exposure, not retention. Sitting through 47 hours of SQL video is not 47 hours of learning SQL, and the gap is not small.
Memory for material you have merely read decays fast and it decays on a curve that has been measured repeatedly since 1885 — the modern replication puts most of the loss inside the first day, with a discontinuity around the 24-hour mark that the authors attribute to sleep.1 So an estimate built on hours-in-front-of-material is counting something that partly evaporates before the next session.
The two techniques that survive review as reliably useful are practice testing and spreading study out over time; rereading and highlighting, which is what most self-paced study actually consists of, come out with surprisingly low utility.2 An honest hours figure therefore has to be hours of doing, which is what ours counts and why it looks larger than a course catalogue's.
What "I know SQL" has to mean before the number means anything
"Learned SQL" is not one thing, which is the real reason the estimates disagree. Writing a SELECT with clear aliases is an hour. Joining three tables at the right grain and proving the totals were not inflated by fan-out is three, and it is the skill that separates someone who can query from someone you can trust with a number.
The course states a can-do sentence for every one of its 26 skills, and the sentence is the bar — each one is written so it can be settled by looking at a piece of work rather than by asking someone whether they feel confident. The heaviest ones are worth naming, because they are where the hours actually go.
The last of them is the one people underestimate most. Reading a query plan is a separate skill from writing queries, it is documented rather than intuited, and the documentation is free.4 Budget the three hours; it is what turns a query that works into a query you can put in front of a database somebody depends on.
- Grain — state what one row of your result represents, and write the GROUP BY that produces it. 2.5 hours.
- Join grain — join three tables without inflating the totals, and prove it. 3 hours.
- Cohort analysis — build a retention table from a raw event log. 3 hours.
- Query performance — read an EXPLAIN plan, name why it is slow, and fix it. 3 hours.
How to find out where you actually are
The fastest way to shorten the number is to stop paying for the parts you already know. Our skill check runs in about ten minutes, needs no account, and reports per skill rather than as a single score — so what comes out is a list of what to skip, not a percentage.
Then the hours that remain are the ones worth spending, and the estimate stops being about SQL in general and starts being about you. There are 4 graded briefs in this course, each with its marking checklist published before you start, which is what makes "finished" a thing somebody can check rather than a thing you decide.
Sources, and what each is worth
Questions that come with this one
Can I learn SQL in a weekend?
You can learn to write a SELECT with a filter and a sort in a weekend, and that is a real, useful thing. You cannot get to joins at the right grain, window frames or query plans, which is about 47 hours of work in total.
Is SQL harder than Python?
Different, and shorter. Our SQL course is 47 hours against 30 for Python fundamentals. SQL has fewer concepts but they interact — NULLs, grain and joins go wrong together, and that interaction is where the time goes.
Do I need to learn SQL if I already use Excel well?
The concepts transfer better than people expect — a pivot table is close to a GROUP BY, and a VLOOKUP to a join with one row on one side. What does not transfer is grain, and NULL: comparing anything to NULL yields neither true nor false, so a filter can silently drop rows rather than complain.3 That is our reading of where spreadsheet users trip, and the NULL half of it is documented behaviour rather than opinion.
How do I know when I have actually finished?
When you can hand in work that clears the published checklist for it. There are 4 graded briefs on this course, and the rubric for each is on its page before you start, so finishing is something a marker agrees with rather than something you declare.
Put this into practice
Reading about how to learn is the easy half. Tell us what you are actually trying to get good at, and we will build the path — the skills in the order they depend on each other, and marked work to prove you got there.
Build my path