sqlx

General-purpose extensions to Go's database/sql, adding struct scanning, named queries, and more without breaking compatibility.

Library
Go
vv1.4.0
17,738 stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum. How we score it →
49 /100 Fair
Development Activity 0
Maintenance 20
Community 76
Maturity 60
Momentum 40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation. How we score it →
63 /100 Good
Architecture 75
Code Quality 78
Innovation 55
Learning Curve 45

sqlx extends Go’s standard database/sql library with a superset of its interfaces, so existing code that uses sql.DB, sql.Tx, and sql.Stmt keeps working unmodified when you switch to sqlx’s wrapped equivalents. It adds struct marshaling for query results (including embedded structs), named parameter binding for prepared statements, and Get/Select helpers that take a query straight to a struct or slice in one call, cutting out the manual Scan() boilerplate that database/sql normally requires.

Because it leaves the underlying driver interfaces untouched, sqlx works with any database/sql driver — PostgreSQL, MySQL, SQLite, Oracle, SQL Server — and lets teams adopt it incrementally in an existing codebase without a rewrite.

What You Get

  • Struct scanning via Get/Select, including embedded struct and slice/map destinations
  • Named parameter support (:name) for both ad hoc queries and prepared NamedStmt statements
  • Drop-in DB/Tx/Stmt/Row/Rows wrappers that remain fully compatible with database/sql
  • A reflectx sub-package for fast, tag-aware struct field mapping
  • A types sub-package with GzippedText, JSONText, and BitBool helper column types

Common Use Cases

  • Replacing repetitive rows.Scan() boilerplate with one-line Get/Select calls in a REST API’s data layer
  • Batch-inserting structs or maps via NamedExec without hand-building parameter lists
  • Migrating an existing database/sql codebase to richer query ergonomics without rewriting driver-specific code
  • Building lightweight internal tools and CLIs that need structured DB access without pulling in a full ORM

Under The Hood

Architecture

sqlx.go defines package-level wrapper types (DB, Tx, Stmt, Row, Rows, NamedStmt) that embed the corresponding *sql.X types plus extra fields (an unsafe flag, a *reflectx.Mapper), so every sqlx value remains a valid database/sql value. A lazily-initialized mapper() builds a singleton reflectx.Mapper keyed on the package-level NameMapper func and the “db” struct tag; StructScan/MapScan/SliceScan route through it to reflect struct fields during row scanning. bind.go keeps a driver-name-to-bindtype registry in a sync.Map so Rebind/BindNamed can rewrite ”?” placeholders into a driver’s native form ($N, :name, @pN); BindDriver lets callers register drivers sqlx doesn’t know about at runtime. named.go and named_context.go compile “:name” query strings into positional queries and delegate execution to a small Ext interface (binder + Queryer + Execer) satisfied by both DB and Tx. sqlx_context.go duplicates the whole surface for context.Context variants, favoring a straightforward layered, if repetitive, design over unifying interfaces. The reflectx sub-package is architecturally independent — a self-contained, tag-aware field mapper consumed only by sqlx.go for scanning, so it could be swapped without touching bind.go or named.go.

Tech Stack

go.mod pins a go 1.10 floor, and production code (sqlx.go, sqlx_context.go, bind.go, named.go, reflectx/reflect.go) imports only the standard library: database/sql, database/sql/driver, reflect, strings, sync, bytes, strconv, errors, fmt, io/ioutil, and path/filepath. The three go.mod requires (github.com/go-sql-driver/mysql, github.com/lib/pq, github.com/mattn/go-sqlite3) are test-only drivers used by the integration test suite, not runtime dependencies — sqlx itself ships driver-agnostic. Builds run through a plain Makefile and go test; the README references CircleCI for CI and Coveralls for coverage tracking. There is no bundled web framework, ORM, or database driver — sqlx is meant to sit directly on top of whichever database/sql driver the consuming application already imports.

Code Quality

Test coverage is extensive relative to the library’s size: sqlx_test.go (1925 lines) and sqlx_context_test.go (1427 lines) run integration-style tests against real sqlite3/MySQL/Postgres drivers, alongside bind_test.go, named_test.go, named_context_test.go, and reflectx/reflect_test.go. Error handling is idiomatic Go — functions return (T, error) throughout, with deliberate Must*-prefixed variants (MustExec, MustBegin) that panic instead, a documented ergonomic tradeoff rather than a swallowed error. Naming closely mirrors stdlib database/sql (DB, Tx, Stmt, Rows, Row), keeping the surface familiar to any Go developer. Because the library predates generics (go 1.10 floor) and its job is generic struct scanning, several APIs necessarily take interface{} and lean on reflection rather than static typing; no linter configuration is present in the repository root, though the coverage badge indicates coverage is tracked in CI.

What Makes It Unique

sqlx is not a new database technology — it is a deliberately narrow convenience layer over stdlib database/sql, and its most consistent design constraint is that every returned type still satisfies the equivalent database/sql interface, so adopting it never locks a codebase in. Two things are genuinely well-executed rather than novel: the reflectx sub-package is a tag-aware, embedded-struct-capable field mapper that is both faster and more capable than plain reflect.FieldByName, and is factored out as an independently reusable component; and the runtime BindDriver registry lets applications teach sqlx how to rebind placeholders for drivers it has never seen. sqlx explicitly stays out of query-building, relation management, migrations, and code generation — competitors to it are typically other thin scanning helpers, not full ORMs, and it makes that scope limitation a selling point rather than a gap.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers