Course outline

01 · Getting Started6/6

02 · Variables, Types & Control Flow6/6

03 · Functions & Composite Types6/6

04 · Methods, Interfaces & Errors6/6

05 · Packages, Modules & Concurrency Intro6/6

06 · Your First Real Program6/6

07 · Testing & Debugging in Go6/6

08 · Capstone — Ship a Real Tool7/7

09 · Generics6/6

10 · Concurrency in Practice6/6

11 · Language Depth II6/6

12 · Standard Library Toolkit6/6

13 · Building Web Services6/6

14 · Working with Databases6/6

15 · Advanced Runtime & Tooling6/6

16 · Building a Terminal Dashboard with Bubble Tea5/5

17 · Closing the Loop2/2

Stage 1 · Code

Working with Databases

SQL Basics with database/sql

Learn the standard library's database layer the calm, practical way: how drivers attach themselves, how queries turn back into Go values, and why safe parameters are non-negotiable.

13 min readThe Complete Go EngineerCode

Why database/sql Feels Different

Most Go code you've written so far works entirely inside one process. You call a function, pass a value, get a result, and stay inside your own program's memory. A database call is different. Now your program is sending a request to another system, waiting for that system to run SQL, and then translating the answer back into Go values you can use.

A helpful picture is a restaurant pass-through window. Your Go program writes the order ticket. The database kitchen does the actual work. database/sql is the counter in the middle: it knows how to hand orders across, receive finished plates back, and keep the conversation organized. It does not cook the meal itself, and it does not decide your menu. That is why it feels more mechanical than packages like fmt or strings.

What `database/sql` really gives you

The standard library gives you a common interface for talking to SQL databases. It does not contain a built-in PostgreSQL, MySQL, or SQLite engine. Instead, it defines the rules, and a driver package plugs a specific database into those rules.

Tool	Use it when	What comes back
`QueryRow`	You expect exactly one row, or zero rows	A single row handle that you later `Scan`
`Query`	You expect many rows	A `*sql.Rows` cursor you loop through
`Exec`	You are not reading rows back	A result describing affected rows or insert metadata

Opening a DB and Loading a Driver

When you call sql.Open, you are not opening a single permanent wire and pinning your whole program to it. You are creating a *sql.DB value that knows which driver to use, how to build connections, and later how to manage a pool of them. The actual network connection may happen lazily when you run the first real query, which is why many programs call Ping right after setup to fail early if the configuration is wrong.

That mysterious blank import is part of the setup story. A driver package usually registers itself in its init function. You may never call that package directly, but you still need its side effect. Writing _ 'some/driver/package' means, 'compile and run this package's setup code, even though I will not refer to it by name later.'

Gothe-driver-registration-pattern.go

22 linesLn 1, Col 1Go

The blank import exists only so the driver can call `sql.Register(...)` during startup. After that, `sql.Open` looks up the registered driver by the name you pass as its first argument.

Blank import does not mean 'unused by mistake'

Normally, Go rejects unused imports because they often signal dead code. A blank import is the deliberate exception: you are saying the value names are unused, but the package's startup side effects are required.

Querying, Exec, and Scan

Once the database is open, the everyday rhythm is simple: send SQL, pass any input values separately, then scan the returned columns into ordinary Go variables. The database speaks in rows and columns. Your Go code speaks in ints, strings, bools, and structs. Scan is the bridge between those two shapes.

Gotracing-one-real-query-from-sql-to-go-variables.go

33 linesLn 1, Col 1Go

If the query returns no row, `Scan` will return `sql.ErrNoRows`. If the column types do not fit the destination variables, `Scan` returns a conversion error. Either way, the failure becomes visible at the scan step.

Go`query`-for-many-rows-and-`exec`-for-writes.go

53 linesLn 1, Col 1Go

Use `Query` when you must loop. Use `Exec` when you only care that a write happened. In both cases, the input values stay separate from the SQL text.

Why Parameters Beat String Concatenation

String concatenation feels tempting because it looks quick. But the moment untrusted input gets pasted directly into SQL text, the user is no longer just providing a value. They are helping write the query itself. That is the door SQL injection walks through.

Gounsafe-query-building-versus-parameterized-queries.go

29 linesLn 1, Col 1Go

If `email` is `' OR 1=1 --`, the unsafe SQL becomes `SELECT id, email FROM customers WHERE email = '' OR 1=1 --'`. The condition `1=1` is always true, so the query can return every row. With parameters, the database receives that same text as a plain value, not as extra SQL instructions.

Different drivers use different placeholder styles. Many use ?. Some use numbered placeholders such as $1, $2, and so on. The safety idea is identical either way: the SQL statement stays fixed, and the values travel separately.

Quiz and Practice

Quiz & Practice

Question 1 / 3

Why do many Go programs call `Ping` right after `sql.Open`?

Hands-On Project

Load shelf units safelyEasy

Implement `LoadShelfUnits`. It should call `QueryRow` with a parameterized query, scan the returned `units` value into an `int`, and return that value plus any scan error.

Gosolution.go

Summary and Key Takeaways

database/sql is the shared interface layer between your Go code and a specific SQL driver.
A blank import is how many drivers register themselves for later use by sql.Open.
QueryRow, Query, and Exec are three different shapes of database work, not interchangeable spelling variations.
Scan copies database columns into ordinary Go variables in column order.
Parameterized queries are the baseline safe habit; string concatenation lets untrusted input rewrite your SQL.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.