// the find
jackc/pgx
PostgreSQL driver and toolkit for Go
pgx is the de facto PostgreSQL driver for Go — it talks the wire protocol directly, skips the database/sql overhead, and exposes Postgres-specific features that database/sql simply can't reach. If you're building a Go service that only talks to Postgres, this is what you use. The toolkit layer (pgconn, pgproto3, pgtype) is independently useful for building proxies, replication clients, or connection poolers.
1. Binary protocol support for custom types — encoding/decoding at the wire level is meaningfully faster than text-format round-trips, which matters at scale. 2. COPY protocol support is a first-class feature, not an afterthought — bulk loads that would take minutes with INSERT batches finish in seconds. 3. The pgxpool package handles connection lifecycle properly: after-connect hooks let you set session parameters once rather than on every query. 4. pgproto3 exposes the full wire protocol as a library, so you can build a Postgres-speaking proxy or MitM without reimplementing the framing yourself.
1. The v5 type mapping system is a significant API break from v4, and the migration is non-trivial — you'll touch every Scan call in your codebase and discover that pgtype.Text is not the same as string in ways that surprise you. 2. No built-in struct scanning — you need a third-party library (scany, pgx-go-kit, etc.) to map rows to structs, which is table stakes for most applications. 3. The pgxpool configuration is powerful but the zero-values are not safe defaults for production; MaxConns, MinConns, and health-check intervals all need explicit tuning, and the docs don't make the production-safe starting point obvious. 4. OAuth/OAUTHBEARER auth support landed recently and the test setup requires compiling a custom PostgreSQL C module — not a day-to-day concern, but the ops story for that auth path is rough.