From Reader to Practitioner — What to Learn Next

You made it. Seven posts ago, SELECT * FROM employees was a strange incantation. Now you can filter, sort, group, join, and read a query like a sentence — and you know how to use AI as a co-pilot instead of a crutch. That's not a small thing.

This final post is your roadmap: a recap of what you've built, where to practise for free, what to learn next, and a peek at how we use all of this at River.

What you've actually learned

Let's name it, because it's easy to underestimate. You now know:

1. Why data matters — the shift from gut feel to spreadsheets to databases, and why data literacy is the skill of the moment.
2. The query skeleton — SELECT ... FROM ..., the two words that unlock any database.
3. Filtering — WHERE, AND, OR, and LIKE, to pull out exactly the right rows.
4. Ordering — ORDER BY and LIMIT, to turn a pile of rows into a ranking.
5. Summarizing — COUNT, SUM, AVG, MIN, MAX, GROUP BY, and HAVING, to see the big picture.
6. Joining — INNER JOIN and LEFT JOIN, to connect customers to orders to payments.
7. AI co-piloting — how to prompt for SQL and, more importantly, how to verify it.

That's the complete foundation of practical SQL. Everything else — and there's a lot of it — is built on these same bones.

Free places to practise

SQL is a doing skill, and the only way it sticks is reps. Here's where to get them, all free:

• SQLBolt (sqlbolt.com) — the browser-based lessons we've referenced all series. Work through all of them; they're quick and they click.
• Mode Analytics SQL Tutorial (mode.com/sql-tutorial) — a clean, business-flavoured course that takes you from SELECT to subqueries and window functions, with a live query editor.
• LeetCode SQL (leetcode.com/problemset/database) — hundreds of real interview-style problems, ranked by difficulty. Start with the "Easy" ones; they're excellent drills.
• SQLZoo (sqlzoo.net) — an old-school but surprisingly good set of interactive exercises.

The habit that matters more than any specific site: practise a little, often. Fifteen minutes a day for two weeks beats one four-hour cram session, and you'll remember it longer.

What to learn next

Once the foundations feel automatic, here's your next tier — with the one-line version of each:

• Subqueries — a query inside a query. "Show me customers who spent more than the average customer." Powerful, and a natural next step after GROUP BY.
• CTEs (Common Table Expressions) — giving a name to an intermediate result using WITH. It's how you keep complex queries readable, and it's the difference between a query you can debug and one you can't.
• Window functions — ROW_NUMBER(), RANK(), and running totals. Instead of collapsing rows with GROUP BY, these compute values across rows while keeping them all. "Show each order and its rank by size" is a window-function job.
• Indexes and query performance — once your data gets big, this is what keeps it fast. A one-session topic that pays off forever.

Don't rush into these. Get genuinely comfortable with the seven posts above first. Depth before breadth, always.

Common beginner mistakes (and how to avoid them)

As you practise, you'll hit the same handful of snags everyone does. Here they are, so you can skip the confusion:

• Forgetting the quotes around text. WHERE city = Nairobi fails, because SQL reads Nairobi as a column name. Text values always go in single quotes: WHERE city = 'Nairobi'.
• Using = when you mean LIKE. WHERE name = 'A%' won't match "Achieng" — = is exact, while LIKE is pattern matching.
• Filtering groups with WHERE instead of HAVING. After a GROUP BY, filter the groups with HAVING, not WHERE. WHERE runs before grouping, HAVING after.
• Mixing up INNER and LEFT joins. If a customer might have no orders, INNER JOIN silently drops them. Ask yourself: do I need the unmatched rows? If yes, use LEFT JOIN.
• Forgetting that clause order is fixed. It's always SELECT, FROM, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT. The database rejects any other order.

None of these are "maybe this isn't for you" moments. They're just the same five potholes on a road everyone drives. Hit them, remember them, move on.

How River uses this stuff internally

Since you're reading this on our blog, a quick peek behind the curtain. At River, data isn't a separate team's problem — it's how we build the product. We query databases to answer questions like:

• How many businesses signed up this week, and how many started accepting M-Pesa payments?
• What's our average transaction value, and how does it differ between Nairobi and upcountry?
• Which features do people use most, and where do they drop off?

And here's the honest part: when a non-technical teammate learns even the basics of SQL, they stop asking other people to "pull some numbers" and start answering their own questions. That's a real superpower — and it's exactly why we wrote this series.

We built River to help East African businesses get paid and understand their money. Payments, orders, customers, earnings — it all lives in a database, and the businesses that ask their data good questions are the ones that grow. If you run a shop or a service business and want that clarity for yourself, that's what we do. But even if you never touch River, the skill you've just learned works everywhere.

Your first real project

Here's a concrete next step, because "keep practising" is too vague to be useful:

Take something you already have — a shop's sales, a savings-group's records, a school's fee payments, anything — put it in a spreadsheet, and ask yourself three questions a week that SQL could answer. Then write the query. Even if you run it in your head or on SQLBolt, the act of translating a business question into a query is the skill itself.

Do that for a month and you'll have quietly become the person in the room who can answer their own questions. That's the whole game.

Your first 30 days

If a concrete schedule helps more than vague advice, here's one that works:

• Week 1 — Finish SQLBolt end-to-end. Re-read posts 2–4 of this series alongside it.
• Week 2 — Work through Mode's tutorial up to the joins section. Re-read posts 5–6.
• Week 3 — Solve fifteen "Easy" LeetCode SQL problems. Re-read post 7 and start asking AI for every query — then verifying it.
• Week 4 — Take a real dataset (your sales, your records, your chama's books) and answer five business questions with SQL. Write the questions and the queries down.

The exact schedule matters less than the habit: a little every day beats a lot once a month.

A last word

SQL isn't flashy. It doesn't get the headlines that "AI" or "machine learning" do. But it's been the quiet backbone of how businesses understand themselves for fifty years, and in the age of AI it's more relevant, not less — because someone has to know whether the numbers are right.

You're now that someone, or well on your way. Thanks for reading the whole series. Go ask your data a question.

— The River Team