jackc/pgx: the Go PostgreSQL driver that skips database/sql

The problem pgx solves, and who it is for

Go ships database/sql as a generic interface over many databases. That abstraction has a cost: it hides PostgreSQL-specific capabilities. The pgx README is explicit that the pgx interface is faster and that features such as LISTEN/NOTIFY and COPY are not available through database/sql. So the project exists in two layers. The driver is a low-level, high performance interface that speaks PostgreSQL directly. The toolkit is a set of packages that parse the wire protocol and map types between PostgreSQL and Go, and the README notes those packages can be used to build alternative drivers, proxies, load balancers and logical replication clients.

The intended audience is narrow and stated: applications that only target PostgreSQL, with no other library in the process requiring database/sql. If you are writing a service that talks to one Postgres cluster, pgx removes a translation layer you were paying for anyway. If you are writing an ORM-adjacent library that must support MySQL, SQLite and Postgres behind one handle, database/sql is still the right surface and pgx is not the tool.

How the driver, the pool and the stdlib adapter fit together

The repository layout mirrors the three documented entry points. The root package is the base driver, with conn.go, rows.go, tx.go, batch.go and copy_from.go carrying the query, transaction, batch and COPY paths. pgxpool/ is the concurrency-safe connection pool, and the README points at pgxpool.New alongside pgx.Connect for connection configuration. stdlib/ is the database/sql compatibility adapter, so code that must keep the standard interface can still run on pgx underneath.

Two details matter more than the package list. First, connection configuration is shared: both pgx.Connect and pgxpool.New accept PostgreSQL connection URLs and key=value strings, and the README sends readers to pgconn.ParseConfig for the supported options and environment variables. That means the same DATABASE_URL string works whether you open a single connection or a pool. Second, the interface choice is not permanent. The README states it is possible to use the database/sql interface and convert a connection to the lower-level pgx interface as needed, which lets a codebase adopt pgx incrementally instead of rewriting its data layer.

Underneath, pgconn/ handles the connection and pgproto3/ the wire protocol, with pgtype/ doing the PostgreSQL-to-Go type mapping. The README counts roughly 70 supported PostgreSQL types, automatic statement preparation and caching, batch queries, a single-round trip query mode, binary format support for custom types, and mappings such as inet and cidr to netip.Addr and netip.Prefix.

Installing pgx and running a first query

Installation is a single module fetch. The README gives this command, and there is no server-side component to deploy, no daemon and no configuration file:

go get github.com/jackc/pgx/v5

The README example connects with pgx.Connect using a DATABASE_URL environment variable, then runs a parameterised query with a positional placeholder and scans two columns into Go variables:

conn, err := pgx.Connect(context.Background(), os.Getenv("DATABASE_URL"))
if err != nil {
	fmt.Fprintf(os.Stderr, "Unable to connect to database: %v\n", err)
	os.Exit(1)
}
defer conn.Close(context.Background())

var name string
var weight int64
err = conn.QueryRow(context.Background(), "select name, weight from widgets where id=$1", 42).Scan(&name, &weight)

On success the program prints the name and weight for id 42. Note the placeholder syntax: $1, not ?. That is the PostgreSQL wire format, and it is the first thing that trips up developers arriving from other drivers. The connection string itself can be a URL such as postgres://username:password@localhost:5432/database_name or a key=value string, and the README points at the PostgreSQL connection string documentation for the full set of options. For a longer walkthrough, the README links a getting started guide on the project wiki.

Where pgx is the wrong tool

The clearest limitation is stated by the project itself: the pgx interface only makes sense when the application targets PostgreSQL alone. The moment a second database enters the picture, or a dependency hands you a *sql.DB that you cannot change, you are on the stdlib adapter, where LISTEN/NOTIFY and COPY are not available unless you convert a connection to the lower-level pgx interface. That is not a defect, it is the boundary of the design, but it is easy to miss when reading the feature list.

Version support is the second constraint. pgx follows the support windows of Go and PostgreSQL rather than pinning to older releases: the README states Go 1.25 and higher and PostgreSQL 14 and higher, and go.mod carries the line go 1.25.0. A team on an older toolchain or an older server cannot simply take the latest v5.

Third, the testing story is heavier than a plain go test. The README describes per-checkout PostgreSQL 14 to 18 clusters plus a CockroachDB node, driven through mise tasks and a test.sh script, with only PostgreSQL 18 left running by default. That is a deliberate investment in confidence, and it is also a setup cost for anyone who wants to run the full matrix locally.

pgx versus lib/pq, and what the difference actually is

The natural comparison is lib/pq, the older PostgreSQL driver most Go developers met first. The difference is not a matter of degree in the same API; it is a difference in which interface you are programming against. lib/pq is a database/sql driver. You get sql.DB, sql.Rows and sql.Tx, and you get whatever the standard interface exposes. pgx offers that same surface through stdlib/, but its own interface is the primary one, and that is where PostgreSQL-specific behaviour lives.

Concretely, the README lists COPY protocol support for faster bulk data loads and LISTEN/NOTIFY as features of the pgx interface, and states plainly that they are not available through database/sql. If your application streams bulk inserts or uses Postgres as a notification bus, that sentence decides the choice for you. The same applies to the type layer: pgx maps PostgreSQL arrays to Go slices for integers, floats and strings, maps inet and cidr to netip.Addr and netip.Prefix, and supports hstore, json and jsonb, with binary format for custom types. Those are toolkit capabilities, and the toolkit is the part of pgx that has no equivalent in a thin database/sql driver.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-10-31. The most recent release listed is v5.11.0, dated 2026-09-07. The version policy is stated: pgx follows semantic versioning for the documented public API on stable releases, and v5 is the latest stable major version.

The licence is MIT, which is permissive and imposes no copyleft obligation on the surrounding application. That is a statement about the licence identifier, not legal advice; if your organisation has specific compliance requirements, the LICENSE file in the repository root is the document to review.

Upgrade cost is where pgx asks for attention. Because version support tracks Go and PostgreSQL support windows, a major Go upgrade can force a pgx upgrade, and vice versa. The dependency set is small (pgpassfile, pgservicefile, puddle, and golang.org/x/sync and golang.org/x/text at the time of go.mod), so a version bump is unlikely to cascade, but the Go directive in go.mod and the README's stated minimums are the two lines to check before planning a bump. The CHANGELOG.md at the repository root is where release-to-release behaviour changes would be recorded.

Editorial conclusion

Adopt pgx when the application targets PostgreSQL only, no other library forces database/sql, and you want COPY, LISTEN/NOTIFY or binary type mapping without a second driver. Avoid it if you need one connection layer across several databases, since the stdlib adapter is the compatibility path and the README states the pgx interface is the faster one. Before committing, check your Go toolchain against the go.mod line 'go 1.25.0', confirm your server version is PostgreSQL 14 or higher, and read pkg.go.dev for pgxpool and stdlib to see which of the two you actually need.

Frequently asked questions

Official sources

1. jackc/pgx on GitHub
2. License: MIT
3. Project website
4. README
5. Releases