Welcome to lesson one of the SQL Server course. If you’re reading this on a Thursday in 2026, somewhere on this planet there is a 20-year-old SQL Server instance powering a billing system that nobody wants to touch. There’s also a brand new Azure SQL Database spinning up in the background of an app you probably use every day. SQL Server has been around since 1989, which in software years is roughly forever, and it runs more of the banking, healthcare, and government infrastructure than any sane person would be comfortable knowing.
And yet if you ask ten developers “what is SQL Server, actually?” you’ll get ten fuzzy answers involving words like “database,” “Microsoft,” and “the thing SSMS connects to.” That’s not good enough. So let’s start at the beginning.
SQL Server in one sentence
SQL Server is a relational database engine made by Microsoft, which speaks a dialect of SQL called T-SQL, and which runs as a Windows service (or a Linux daemon, or a container) that you connect to over the network.
Let’s unpack that, because each word is doing work.
Relational database engine. It stores data in tables with rows and columns. Tables can reference each other with foreign keys. You write declarative queries in SQL (“give me all customers in Italy who spent more than €1000 last month”) and the engine figures out how to get the answer. This is in contrast to, say, MongoDB (documents), Redis (key-value), or Snowflake (a columnar analytics warehouse with a different execution model).
T-SQL. Stands for Transact-SQL. It’s SQL Server’s dialect of the SQL standard, with Microsoft-specific extensions for variables, procedural logic (IF, WHILE, TRY ... CATCH), stored procedures, and a bunch of functions that exist nowhere else (STRING_AGG, CONCAT_WS, etc.). Most SQL you know from Postgres or MySQL mostly works. The TOP keyword, the NVARCHAR data type, [square brackets] for identifiers, and the dreaded IIF() function are all T-SQL inventions.
A service you connect to over the network. SQL Server is not a file format like SQLite. You don’t just open a .db file and start running queries. It’s a server process that listens on a TCP port (usually 1433), authenticates you, keeps data in memory for speed, and hands back results. To talk to it you use a client: SSMS on Windows, Azure Data Studio on any OS, VS Code with the mssql extension, DBeaver if you already use it for everything else, or your application’s database driver.
Made by Microsoft, which matters. SQL Server is a commercial product. It’s tightly integrated with Windows (though it runs on Linux since 2017), with Active Directory for authentication, with Azure for cloud, with PowerShell for automation, with SSMS for management, and with a fifteen-year back-catalogue of DBA tools and scripts. If you’re in the Microsoft ecosystem, you’re probably already using SQL Server whether you know it or not. If you’re in the Google Cloud + Python + Postgres world, you’re probably not.
The family: not “SQL Server” but “several SQL Servers”
When people say “SQL Server,” they could mean any of the following, and it matters:
SQL Server (the on-prem product)
The classic. You install it on a server — physical, VM, or container — and manage it yourself. Current supported versions as of 2026: 2019, 2022, and 2025. You pay a per-core license (more on pricing in a moment), and you run it on your own hardware in your own data centre, or on a VM in Azure, AWS, or your dad’s basement.
Azure SQL Database
The managed cloud version. You don’t see the machine, the OS, or the service; you just get a database endpoint. Microsoft patches, backs up, and monitors the engine for you. You pick a pricing tier and pay per hour. Most features of on-prem SQL Server work, some don’t (SQL Agent is replaced by Elastic Jobs, cross-database queries are limited, etc.), and a few Azure-only features exist on top.
Azure SQL Managed Instance
Somewhere between the two. You get almost the full on-prem feature set (including SQL Agent, cross-database queries, the CLR), but Microsoft still manages the underlying infrastructure. Used mostly by shops moving a legacy on-prem estate to the cloud without rewriting everything.
SQL Server on Azure Virtual Machines (IaaS)
Literally “SQL Server the product, installed on a VM Microsoft happens to host.” You manage everything except the physical hardware. This exists for migrations where you want zero behavioural changes from your on-prem environment.
Azure Synapse / Microsoft Fabric
These are Microsoft’s analytics platforms that use a SQL-Server-flavoured query engine but are fundamentally different products optimized for data warehouse workloads. They speak T-SQL. They are not SQL Server. If you find yourself writing queries against Synapse Dedicated SQL Pool and a Stack Overflow answer says “just use sp_Blitz,” it will not work. Be careful what you call “SQL Server.”
Throughout this course we mean SQL Server 2019+ on any platform, or Azure SQL Database and Managed Instance where the feature exists. I’ll call out cloud-only or on-prem-only bits explicitly when they come up.
Editions, or “how Microsoft wants you to spend money”
Within on-prem SQL Server, there are several editions — the same engine, with features turned on or off depending on how much you paid.
Enterprise Edition. The full feature set. Online index rebuilds, Always On Availability Groups, compression, partitioning-with-everything, TDE, Query Store, Resource Governor, up to the OS max on RAM. Priced per core, and it is eye-watering. Roughly $14,000 per core per licence at list price as of 2025. A two-socket server with 32 cores is, checks notes, a used car.
Standard Edition. Most features, some with restrictions. RAM capped at 128 GB per instance. No Always On Availability Groups (until 2022 loosened this), no online index rebuilds below Enterprise. Priced per core at roughly $3,500 per core list. Most small-to-mid-sized businesses run Standard. It’s fine for 90% of workloads.
Web Edition. A cheaper Standard-ish edition that only web hosters are supposed to resell. If you’re not one, you can’t buy it.
Express Edition. Free. Capped at 10 GB per database, 1 socket / 4 cores, 1410 MB of buffer pool. Great for small apps and demos. No SQL Agent, no backups beyond manual, no online anything. This is the one you’d use in a tiny internal tool.
Developer Edition. Free, and has all the features of Enterprise. The catch: you legally cannot use it in production. It exists for developers to learn, build, and test against the same feature set they’ll use when their company eventually pays for Enterprise. This is the edition you want on your laptop for this course. We’ll install it in lesson 2.
Evaluation Edition. A 180-day trial of Enterprise. Exists so large orgs can test the full feature set before signing the licence.
If you ever read SQL Server docs and wonder “why does the tutorial mention Resource Governor and I don’t have it?” — you’re probably on Express or Standard. Check SELECT @@VERSION; and you’ll see the edition right there.
Licensing: the part the docs don’t explain
Microsoft licences SQL Server by core count for Enterprise and Standard, with a minimum of 4 cores per machine. There’s an older “Server + CAL” model that still exists for Standard Edition, priced per server plus one “client access licence” per user or device. Most large shops have moved to core licensing because cloud and virtual machines made per-CAL licensing impossible to audit.
A few gotchas worth knowing before you commit to Microsoft for your next project:
- Hyperthreading counts. On a physical server, each logical core typically gets licensed, which doubles your bill. Virtual machines licence per allocated vCPU.
- Azure Hybrid Benefit. If you already own SQL Server licences with Software Assurance, you can “bring your own licence” to Azure and save significantly. This is the one Microsoft programme that actually saves money.
- Software Assurance is not optional if you ever want to use Always On, Power BI Report Server, stretched databases, or cluster failover. SA is the subscription tax on top of the licence.
- Developer Edition for dev, Express or Standard for prod. Never ever ship Developer Edition to production; it’s contractually prohibited and Microsoft’s licensing audits are not a good time. Express in prod is fine and legal if your data fits under 10 GB.
None of this matters for the course. You’re going to install Developer Edition on your laptop and you’ll never see a licence dialog. But if you work in a company that uses SQL Server and you’ve ever wondered why the DBA flinches when someone asks about spinning up “one more instance,” it’s because the licence is watching.
When SQL Server is the right answer
SQL Server is an excellent choice when:
- You already have the Microsoft stack (.NET, Active Directory, Windows servers, Azure).
- You want deep OLTP + reporting from one engine, without bolting on another database.
- Your DBA knows SQL Server and you want to keep them sane.
- You need enterprise features: Availability Groups, TDE, fine-grained security, auditing, Query Store, Temporal Tables.
- You’re building on Azure and want a native managed database with deep ecosystem integration.
SQL Server is probably not the right answer when:
- You want something free and you don’t need the feature set. (Postgres is the obvious choice.)
- Your workload is pure analytics on petabyte-scale data. (Snowflake, BigQuery, or Synapse/Fabric.)
- You need multi-master geo-distributed writes across continents. (Cockroach, Spanner, DynamoDB.)
- You’re a one-person startup who doesn’t want to ever see an invoice from Microsoft. (Postgres, again.)
This isn’t a licensing rant, even though it kind of reads like one. The honest answer is: SQL Server is a very good database that costs real money, and you should use it when the money buys you something the alternatives don’t. Otherwise use Postgres and enjoy life.
Meet Runehold, the company you’ll be working for
Every lesson in this course uses the same fictional company as its running example, because abstract examples never stick the way real ones do.
Say hello to Runehold B.V. — a Dutch private company (“besloten vennootschap”) headquartered in Amsterdam, founded in 2019, now employing about 180 people and pulling in roughly €45 million in annual revenue. Runehold sells physical fantasy-themed goods across the EU: penguin-shaped desk lamps, self-folding (badly) laundry kits, “mildly cursed” tea towels, limited-edition collectibles, board games, and puzzles. The central warehouse is in Poznań, Poland, because the rent is sensible and the delivery carriers are efficient. There are three flagship physical stores — Amsterdam, Berlin, Milan — and two more planned for Paris and Madrid. Runehold sells through its own website (about 60% of revenue), through Amazon/eBay EU storefronts (25%), and in the physical stores (15%).
The subscription product is called Runeboxes — a monthly curated shipment in three tiers: Apprentice (€15/mo), Journeyman (€29/mo), and Loremaster (€55/mo). About 22,000 active subscribers across the EU.
Teams you’ll meet in the data throughout the course:
- Sales — B2C customers plus a growing B2B book-of-business
- Marketing — paid campaigns per country and channel
- Catalog — ~8,000 SKUs, product taxonomy, pricing
- Operations — warehouse, inbound, outbound, inventory counts
- Shipping — carriers, tracking, returns (including the special “haunted returns” queue for products that turn out to be actually enchanted, which happens more often than you’d expect)
- Retail — the three flagship stores, in-store POS
- Customer Support — multilingual, mostly English/Dutch/German/Italian
- Finance — invoicing, VAT (Runehold uses the EU One-Stop-Shop, more on that later), SEPA settlements, revenue recognition
- Engineering / Data — that’s us
- HR — employees, teams, costs
- Legal / Compliance — GDPR, Digital Services Act, consumer rights directives
As the course progresses, you’ll see tables like Sales.Order, Catalog.Product, Inventory.Stock, Shipping.Shipment, Finance.Invoice, Support.Ticket. Each one is a piece of Runehold’s actual operation. The acronyms that make the business run — CAC (Customer Acquisition Cost), LTV (Lifetime Value), AOV (Average Order Value), GMV (Gross Merchandise Value), NPS (Net Promoter Score), VAT (Value Added Tax), OSS (One-Stop-Shop), SEPA (Single Euro Payments Area), SKU (Stock Keeping Unit), OTIF (On Time In Full) — will show up as queries we actually run against this data, not as vocabulary lists.
This isn’t a textbook company with three tables and rainbows. It’s a real-ish EU retailer with real-ish problems. The SQL you learn writing queries for Runehold is the SQL you’d write on a real job.
What the course assumes about your setup
Starting in lesson 2 we’ll install SQL Server 2022 Developer Edition on your laptop (Windows, Mac, or Linux, all supported one way or another) and the SSMS or Azure Data Studio client. Every code example in the course will run on a plain Developer Edition install unless I say otherwise. A few lessons near the end (the First Responder Kit, sp_WhoIsActive, Query Store deep dives) will optionally benefit from a slightly beefier machine or a VM, but you can do the whole course on a modest laptop.
You do not need prior SQL experience. This course starts at “what is a table” and builds up, assuming you’re a technically-inclined person who’s never worked with a database before. If you already know SQL well, you can probably skip lessons 1 to 8 and start at 9 (joins). If you’re an intermediate SQL person who just wants the SQL-Server-specific bits, jump to module 4 (indexes). Lessons 37 through 40, the Emergency Kit, are worth their weight even if you’ve been doing this for ten years.
Run this on your own machine — well, almost
You don’t have anything installed yet, so we can’t run SQL quite yet. But you can already pick your path for lesson 2:
- You’re on Windows? Great. You’ll install SQL Server Developer Edition directly.
- You’re on Mac? You’ll run SQL Server in a Docker container. It works beautifully.
- You’re on Linux? Same Docker approach, or a native install on Ubuntu/RHEL.
- You want to skip local install entirely? Spin up an Azure SQL Database free tier. Every query in this course will run on it too.
All four paths take about 20 minutes end to end. Lesson 2 walks through each of them, with a note at the end on picking between SSMS and Azure Data Studio as your editor.
See you there.