I already had the certificate. It didn't matter.
I got a certificate from one of those online SQL courses even before starting my MSc at Ivey. You know the type. Thirty modules, a progress bar, a certificate at the end that looks nice on LinkedIn.
I finished it. Learned SELECT, WHERE, GROUP BY. Did some practice exercises on fake tables with fake data. Felt productive.
Then I closed the tab and genuinely never thought about it again.
The problem wasn't the syntax. I just couldn't figure out where I'd ever use this. Filter rows in a table? What table? Where? For what? Nobody in any job I'd had ever said "hey can you write us a quick query." It felt like learning to drive a car I didn't own in a city I didn't live in.
Certificate went on LinkedIn. Collected dust.
Then a course at Ivey made it real.
Data Management with Prof Derrick Neufeld (one of the best profs, ever) had us build a database for a real organization. A real place with real problems and real people who can't get answers to basic questions because their data lives on paper or in silos.
I went from "I know what a JOIN is in theory" to writing queries that answer real questions in a real organization. The gap between knowing syntax and understanding why it matters turned out to be massive. The certificate didn't cross it. Getting my hands dirty did. You can read more about my project if you are curious.
OK but why should a business student care.
I'm in a management program. My classmates are probably going into consulting, sales, marketing, product, strategy. For the most part, nobody expects us to write SQL. We could probably get through entire careers without it.
But here's what I keep noticing. Most companies, in every case study, in every job posting I've looked at, is sitting on data they're barely using. Marketing has campaign numbers in one system. Sales has pipeline data somewhere else. Finance has a spreadsheet from Q2 that nobody's updated. The information is all there. Getting to it is the problem.
And getting to it usually means submitting a request to the data team. Waiting a few days. Getting a CSV back. Realizing it's not quite what you asked for. Clarifying. Waiting again.
I'm not that patient. And honestly, you shouldn't be either. Not when the answer is sitting right there in a database and the only thing between you and it is a query you could learn to write in a weekend.
It's also not just me saying this. Business-adjacent roles are quietly starting to list SQL in their job postings. Analyst roles, operations roles, even some marketing and product roles. It's not a hard requirement yet. But it's showing up. And the people who already have it won't be scrambling when it becomes expected.
SQL also sometimes changes how you think.
This part I wasn't expecting and I still can't fully articulate it.
Before SQL, someone says "customers are churning" and my instinct is to brainstorm. Talk it through, grab a whiteboard, jot down ideas. Very business school energy.
Now I hear the same sentence and my brain goes: which customers? Since when? What were they doing before they left? What are the ones who stayed doing differently? Are we even measuring this right?
There's this more grounded, more analytical lens that kicks in. Less "let's discuss this" and more "let's find out what's actually happening first."
Each of those questions is a query. Each answer makes the original problem smaller. More specific. More solvable.
I don't know if this makes me better at my job or just more annoying in meetings. Probably both.
You don't need to be a coding guru.
I want to be clear about this because I think the "coding" part scares some people off. I am not some SQL wizard who has every function memorized. I Google syntax for things I've written before. My queries take multiple iterations, going back and forth until they work. They get the job done but they are definitely not elegant.
Doesn't matter.
The bar for a business person isn't "write production-grade code." It's "can you get to the data yourself instead of waiting for someone else." That's it. Even messy, Googled, probably-inefficient SQL is faster and better than being left helpless or dependent on someone else's timeline.
In a stack of 200 applications from grads who can all make a polished slide deck and present a recommendation, the one who can also pull the data behind that recommendation stands out. Most people won't bother learning SQL. That's exactly the reason it's worth learning.
I'm still in the middle of learning.
I'm not writing this from the finish line. I went from a certificate that sat dead on my LinkedIn for months to actually building things with SQL and understanding why data is structured the way it is. Still a lot I don't know. Still a lot I'm figuring out.
But if you're in a business program and you're debating whether this is worth your time: it is.
The first time you pull your own data, write your own query, find proof for something you suspected but couldn't verify, and realize you didn't have to wait for anyone or take anyone's numbers on faith, something clicks.
And you kind of just can't go back.
