What sqlc is, and why your engineers keep bringing it up.

Imagine you run a team that publishes contracts in three languages. Today, every time legal updates the master document, three translators have to redo their versions by hand. They mostly get it right. But sometimes a clause shifts, someone's translation lags by a week, and a customer ends up signing slightly different agreements. You don't notice until something breaks.

That's roughly the situation engineers are in when their application code talks to a database. The database speaks SQL. The application speaks Go, or Python, or TypeScript. Someone has to keep the two in sync, and that someone is usually a developer, doing it by hand, on every change.

sqlc is the auto-translator. The team writes the master document once, in SQL. sqlc produces, and re-produces, every time the SQL changes, perfectly faithful versions in whichever language the app uses. If the master and the translations ever drift, the build fails loudly instead of failing quietly in production.

What it actually does

The mechanics are simple enough to describe without pictures, but pictures help. Here is the entire workflow:

The tool runs at build time: meaning, before the application is packaged up and shipped. If the SQL refers to a column that doesn't exist, or expects a number where the database stores text, the build halts and tells the developer exactly where the mismatch is. That same mistake, without sqlc, would typically be discovered by a customer at three in the morning.

Today sqlc generates code for the four most common languages on backend teams, Go, Python, TypeScript, and Kotlin, and supports the three most common databases, PostgreSQL, MySQL, and SQLite.

Why the world needed it

Before sqlc, teams building database-backed software essentially picked between two doors. Both had costs your finance team would recognize.

The shift here is small but meaningful. A whole category of work, translating between the database and the app, moves from a thing humans do every day to a thing the build does every build. The humans get that time back. The bugs that come from doing it by hand simply stop appearing.

What it looks like, concretely

You don't need to read code to follow this. The left side is the SQL a developer writes. The right side is what sqlc produces, automatically, on every build. The point is that the right side is no longer something a human has to maintain.

-- name: GetUser:one
SELECT id, name, email
FROM users
WHERE id = $1;

// auto-generated; do not edit
func GetUser(id int64) (User, error) {
  //...checked code that runs the query...
}

type User struct {
  ID    int64
  Name  string
  Email string
}

Why it's pretty sweet

For an ops leader, the technical mechanism matters less than the operational consequences. There are six worth knowing.