sqlc — Dependencies#

Module info#

  • Module: github.com/sqlc-dev/sqlc
  • Go version: 1.26.0
  • Direct dependencies: 25
  • Indirect dependencies: 30 (from go.mod // indirect entries)
  • go.sum entries: 314 lines (~157 unique resolved modules)

Dependency categories#

Core infrastructure#

  • github.com/spf13/cobra v1.10.2 — CLI framework powering the sqlc command and all its subcommands (generate, vet, compile, etc.)
  • github.com/spf13/pflag v1.0.10 — flag parsing; pulled in directly alongside cobra for extended flag handling
  • gopkg.in/yaml.v3 v3.0.1 — parses sqlc.yaml / sqlc.json configuration files (project uses both YAML and JSON config formats)
  • github.com/xeipuuv/gojsonschema v1.2.0 — validates the sqlc config file against a JSON schema at startup, providing actionable error messages for misconfigured projects
  • github.com/sqlc-dev/doubleclick v1.0.0 — a first-party micro-package (sqlc-dev org); likely a guard for idempotent or mutually exclusive CLI operations (“confirm before overwriting” style safety)

SQL Parsing — the project’s core value#

This is the most distinctive dependency cluster in the codebase. sqlc maintains separate parsers for each supported database engine:

  • github.com/pganalyze/pg_query_go/v6 v6.2.2 — CGo wrapper around libpg_query, which bundles the actual PostgreSQL parser. Gives sqlc access to a 100%-faithful Postgres parse tree. Requires CGo; cannot run in sandboxed environments.
  • github.com/wasilibs/go-pgquery v0.0.0-20250409022910-10ac41983c07 — pure-Go alternative Postgres parser that runs the same libpg_query C code compiled to WASM via Wazero. Provides CGo-free portability (CI runners, WASM plugins). Having both in go.mod means sqlc can choose at build/runtime.
  • github.com/pingcap/tidb/pkg/parser v0.0.0-20250324122243-d51e00e5bbf0 — TiDB’s MySQL dialect parser; reused rather than implementing a MySQL grammar from scratch. Brings in the TiDB error handling, failpoint, and logging packages as indirect deps.
  • github.com/antlr4-go/antlr/v4 v4.13.1 — ANTLR4 Go runtime; required by TiDB’s parser which generates its grammar using ANTLR4.
  • github.com/ncruces/go-sqlite3 v0.32.0 — SQLite via a WASM-compiled SQLite library (no CGo). Used for the SQLite engine integration, consistent with sqlc’s broader embrace of WASM for portability.

Plugin system (WASM + gRPC/Protobuf)#

  • github.com/tetratelabs/wazero v1.11.0 — pure-Go WASM runtime; executes community-written code generator plugins (Kotlin, Python, TypeScript, etc.) in a sandboxed WASM environment without requiring a system WASM runtime
  • google.golang.org/protobuf v1.36.11 — Protocol Buffers; the IR (intermediate representation) passed between the sqlc compiler core and all code generator plugins is defined in .proto files (protos/plugin/, protos/analysis/, protos/vet/)
  • google.golang.org/grpc v1.79.3 — gRPC used for remote plugin communication (plugins can also run as separate processes over gRPC, not just embedded WASM)
  • github.com/riza-io/grpc-go v0.2.0 — a fork of grpc-go maintained by Riza, Inc. (the commercial entity behind sqlc); likely adds WASM-compatible transport or custom interceptors needed for the plugin protocol

Code generation utilities#

  • github.com/fatih/structtag v1.2.0 — parses Go struct tag strings (e.g., `db:"name" json:"name"`); used in the Go codegen layer to emit correct struct tags on generated types
  • github.com/jinzhu/inflection v1.0.0 — English word inflection (singularize/pluralize); used to derive idiomatic Go type names from SQL table names (e.g., users → User)

Static analysis (vet engine)#

  • github.com/google/cel-go v0.27.0 — Google Common Expression Language runtime; powers sqlc vet, which allows users to write policy rules in CEL that are evaluated against query metadata (e.g., “warn if a SELECT query has no WHERE clause”). An unusual embedded policy engine for a developer tool.

Database drivers (integration testing & schema introspection)#

  • github.com/jackc/pgx/v4 v4.18.3 and github.com/jackc/pgx/v5 v5.8.0 — both pgx major versions are listed as direct deps, supporting both in the generated code and for end-to-end test execution
  • github.com/lib/pq v1.12.0 — legacy database/sql PostgreSQL driver; included for users generating code targeting lib/pq
  • github.com/go-sql-driver/mysql v1.9.3 — MySQL database/sql driver (note: replaced by a sqlc-dev fork, see Notable Decisions below)

Testing#

  • github.com/google/go-cmp v0.7.0 — deep equality comparison for structured test assertions (comparing generated code output against golden files)
  • github.com/davecgh/go-spew v1.1.1 — pretty-printer for Go values; used in tests for human-readable diff output on failures

Utilities#

  • github.com/cubicdaiya/gonp v1.0.4 — Go implementation of the O(NP) diff algorithm; likely used in the end-to-end test harness to produce meaningful diffs between expected and actual generated output
  • golang.org/x/sync v0.20.0 — provides errgroup for concurrent processing of SQL files and packages during compilation

Stdlib reliance#

sqlc has high stdlib reliance for its core logic. The compiler (internal/compiler/) and SQL AST packages use almost exclusively stdlib: context, errors, fmt, io, os, path/filepath, strings, sort, unicode. The CLI layer (internal/cmd/) adds encoding/json, runtime/trace, and sync. Third-party deps are concentrated in specific subsystems (parsers, plugin runtime, CLI framework) rather than scattered throughout. This makes the internal compiler packages portable and lightweight.

Most-used stdlib packages (inferred from code reading):

  • fmt, errors, strings — universally across all packages
  • os, io, path/filepath — file handling in compiler and config
  • context — threading cancellation through the compilation pipeline
  • encoding/json — config parsing (JSON format) and plugin IR serialization
  • sync — protecting shared state in the compiler’s catalog

Shared dependencies#

Dependencies shared with other projects in the 50-project set:

  • github.com/spf13/cobra — ubiquitous CLI framework; used by Kubernetes, Hugo, Traefik, Caddy, and most other CLI tools in the set
  • google.golang.org/grpc and google.golang.org/protobuf — used by Kubernetes, etcd, and any project with plugin/RPC architecture
  • gopkg.in/yaml.v3 — standard config parsing; used by Prometheus, Grafana, Hugo
  • github.com/google/go-cmp — testing utility; common across Kubernetes ecosystem projects
  • golang.org/x/sync — near-universal in projects doing concurrent work
  • go.uber.org/zap (indirect, via TiDB parser) — appears in many infrastructure projects

Vendoring#

Not vendored. No vendor/ directory. sqlc relies on the Go module proxy and go.sum checksums for reproducible builds. The CLAUDE.md file mentions GOPROXY=direct as a workaround for CI environments with restricted network access — this is the only concession to vendoring constraints. Given the project’s S/M-sized team and active dependency updates (especially TiDB parser pins to recent commit hashes), vendoring would add significant maintenance overhead.

Notable dependency decisions#

  1. Dual PostgreSQL parsers (CGo + WASM): Maintaining both pg_query_go (CGo) and go-pgquery (pure-Go WASM) gives sqlc a portability escape hatch. CGo binaries cannot run in WASM contexts or certain CI/sandboxed environments; the WASM variant covers those cases. This dual-path architecture is a deliberate engineering investment in portability.

  2. Forked MySQL driver (replace directive): go.mod replaces github.com/go-sql-driver/mysql with github.com/sqlc-dev/mysql. The fork is unpublished with no explanation in the visible code. This is likely for MySQL test harness compatibility or a driver-level fix needed for sqlc’s specific usage (e.g., multi-statement support, custom connection attributes, or a bug fix not yet upstream).

  3. Riza-io’s gRPC fork over upstream: Using github.com/riza-io/grpc-go rather than google.golang.org/grpc alone signals that the commercial backer has customized the gRPC implementation — most likely to support running gRPC communication inside a WASM plugin sandbox, which standard gRPC-go cannot do.

  4. CEL for policy rules (not a custom DSL): Rather than designing a bespoke rule language for sqlc vet, the team adopted Google’s CEL. This is a significant dependency for a developer tool but eliminates an entire language implementation problem. CEL is also used in Kubernetes admission webhooks, so Go developers are increasingly familiar with it.

  5. No ORM, no logging framework (direct): A tool that helps developers avoid ORMs predictably uses no ORM itself. Direct logging deps are also absent — only stdlib and what leaks in transitively from TiDB (go.uber.org/zap). This keeps the binary lean and avoids dependency conflicts for users who embed sqlc programmatically.

  6. Two pgx versions simultaneously: Having both pgx/v4 and pgx/v5 as direct dependencies is unusual. It reflects sqlc’s role as a code generator: it must support generating code for users on either pgx version, and the test suite validates both output paths with live database connections.

Backward sqlc — Structure sqlc — Architecture Forward