go-sql-driver/mysql: the pure-Go MySQL driver for database/sql

What go-sql-driver/mysql actually solves

Go's database/sql package is an abstraction: it defines the interfaces, but it ships no driver for any specific database. go-sql-driver/mysql is the implementation that connects that abstraction to MySQL and MariaDB. Import it for its side effects, hand sql.Open the driver name "mysql", and the rest of your code talks to database/sql rather than to the driver.

The audience is narrow and specific. This is for Go developers who want to write SQL against MySQL without pulling in an ORM or a C library. The README states the driver is a native Go implementation with no C bindings, which means no cgo, no libmysqlclient on the build machine, and cross-compilation that behaves like the rest of a Go program. If your project already depends on database/sql, this is the layer that makes it work.

How the driver fits between your code and the server

The repository layout shows the shape of the thing. driver.go and connector.go implement the database/sql/driver interfaces; connection.go and packets.go handle the wire protocol; dsn.go parses the connection string; auth.go handles authentication. There is a single non-standard dependency in go.mod, filippo.io/edwards25519, alongside a go directive of 1.25.0.

Data flow is the ordinary database/sql path. You call a method on *sql.DB, database/sql picks a pooled connection, the driver serializes the statement into MySQL protocol packets, reads the response, and hands rows back through rows.go. Connection pooling is not the driver's job: the README attributes it to database/sql. What the driver adds is the transport layer and the encoding, including zlib compression, support for queries larger than 16MB, sql.RawBytes, and optional time.Time parsing.

Connections can run over TCP/IPv4, TCP/IPv6, Unix domain sockets, or a custom protocol through the DialFunc hook. That last option is the escape hatch for environments where the standard transports do not apply.

Installing the driver and making a first connection

Installation is one command. The README notes that Git must be installed and on your PATH, because the go tool fetches the module from source.

go get -u github.com/go-sql-driver/mysql

The import is deliberately blank, since you never call the package directly. The README's example shows the driver registered under the name "mysql" with a DSN of the form user:password@/dbname.

import (
	"database/sql"
	"time"

	_ "github.com/go-sql-driver/mysql"
)

db, err := sql.Open("mysql", "user:password@/dbname")
if err != nil {
	panic(err)
}
db.SetConnMaxLifetime(time.Minute * 3)
db.SetMaxOpenConns(10)
db.SetMaxIdleConns(10)

Those three settings are not decoration. The README calls SetConnMaxLifetime required, because middlewares can close idle connections after about five minutes, and recommends a timeout shorter than that. SetMaxOpenConns limits how many connections your application opens. SetMaxIdleConns is recommended to match SetMaxOpenConns, since a smaller value causes connections to open and close far more often than you might expect.

The DSN format is [username[:password]@][protocol[(address)]]/dbname[?param1=value1&...]. Only the database name is required, so /dbname is a valid minimal DSN, and a bare / selects no database. Since v1.8.0 the database name is escaped with PathEscape, so a name containing a slash is written as /dbname%2Fwithslash. Passwords need no escaping.

Where the support boundary sits

The README is unusually blunt about what the maintainers will and will not stand behind. MySQL 8.0+ and MariaDB 10.11+ are supported by maintainers. TiDB is supported by PingCAP, and the README says explicitly not to ask TiDB questions in the project's issue tracker or forum. Percona Server, Google CloudSQL and Sphinx are described as likely to work, with the note that maintainers will not support them and that issues there should be investigated by the reporter and fixed by pull request.

That is a real constraint, not a formality. If you run Percona or CloudSQL, you are on your own for driver bugs, and the project says so before you file anything. The Go version floor is equally hard: go.mod declares go 1.25.0, and the README states the project aims to support the three latest Go releases. On an older toolchain, the module will not build.

One more boundary is worth naming. The README does not document rollback behaviour, retry policy, or what happens to an in-flight transaction when a connection breaks. It mentions automatic handling of broken connections as a feature, but the recovery semantics are not spelled out there. If your application depends on precise failure behaviour, read transaction.go and conncheck.go rather than assuming.

How it differs from an ORM such as GORM

The obvious alternative is an ORM built on top of this driver, and GORM is the common one in Go. The difference is where the abstraction sits. GORM maps structs to tables, generates SQL, and manages migrations and associations. go-sql-driver/mysql does none of that: it hands you database/sql and expects you to write the queries.

That trade is worth being honest about. With the driver alone you get no query builder, no automatic schema handling, and no model layer, so a large application will accumulate hand-written SQL and manual scanning code. In exchange, the SQL that reaches MySQL is the SQL you wrote, and there is no generated query to debug. For a service with a handful of queries, or a team that wants the database to be visible in the code, the driver is the smaller and more predictable choice.

A second alternative is a MySQL driver that uses cgo bindings to libmysqlclient. The README's claim of a native Go implementation is the dividing line: no C toolchain in the build, and cross-compilation that works the way other Go builds do. If your environment already links the C client and you need its exact behaviour, the pure-Go driver is a different set of trade-offs.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-19. The most recent release listed is v1.10.1 on 2026-09-02, following v1.10.0 on 2026-04-29 and v1.9.3 on 2025-06-13. That is a steady cadence rather than a burst, and the CHANGELOG.md at the repository root is the place to read what moved between them.

The upgrade cost is mostly the Go version floor. Because go.mod declares go 1.25.0, adopting a current release means your build environment has to be on Go 1.25 or higher, and the README states the project targets the three latest Go releases. A team pinned to an older toolchain has to move the toolchain before it can move the driver.

Licensing is MPL-2.0, the Mozilla Public License 2.0. It is a file-level copyleft licence: modifications to files covered by it carry obligations, while larger works that combine it with other code are treated differently. That is a summary of the identifier, not legal advice. If your organisation has rules about copyleft dependencies, route the actual LICENSE file to whoever handles that.

Editorial conclusion

Adopt go-sql-driver/mysql if you are writing Go against MySQL 8.0+ or MariaDB 10.11+ and want the standard database/sql surface rather than an ORM. Do not adopt it if you need TiDB or Percona support from the maintainers, or if you are not on Go 1.25 or higher. Before shipping, verify that db.SetConnMaxLifetime is set below five minutes, that SetMaxIdleConns matches SetMaxOpenConns, and that the server version you target is one the README names as supported.

Frequently asked questions

Official sources

1. go-sql-driver/mysql on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases