Postgres client libraries
The Language Bindings section of awesome-postgres — every entry, across seventeen languages, as catalogued on 2026-08-20, at the catalog's word (T3).
| Language | Catalogued bindings |
|---|---|
| C / .NET | Npgsql |
| Clojure | clj-postgresql |
| Common Lisp | Postmodern |
| Elixir | postgrex |
| Go | pq, pgx, go-pg |
| Haskell | postgresql-simple |
| Java | PostgreSQL JDBC Driver, Vert.x PostgreSQL Client |
| Lua | luapgsql |
| Node | node-postgres, pg-promise, pogi, slonik, postgres |
| Perl | DBD-Pg |
| PHP | Pomm, pecl/pq |
| Python | psycopg2, asyncpg, pg8000 |
| R | RPostgres, RPostgreSQL |
| Ruby | pg |
| Rust | rust-postgres, pgx, wtx |
| TypeScript | zapatos |
| Zig | pg.zig, qail-zig |
Why this list is in a database wiki at all
Because of the wire protocol. Thirty-odd independent implementations across seventeen languages exist because Postgres's client protocol is a stable, documented, versioned public interface — the same property that lets pgbouncer sit in the middle pretending to be a server, lets vitess' VTGate do the same for MySQL, and lets ferretdb impersonate MongoDB. A protocol boundary is what makes a database extensible from outside without being forked, and this section is the population-level evidence for it, exactly as the Extensions section is for the in-process seam.
The one operational fact worth carrying
Several of these drivers use prepared statements by default, and pgbouncer's transaction
pooling breaks PREPARE/DEALLOCATE. That interaction is why so many of these libraries carry a
"if you use PgBouncer, set this flag" note in their documentation, and it is a client-library
consequence of a server design decision (process-per-connection) three layers up.
Nothing in the catalog connects those dots.
Not verified here: which of these are maintained. Several are decade-old bindings for languages with a newer canonical driver, and the catalog says nothing about it.
Related
postgresql · pgbouncer · ferretdb · vitess · awesome-postgres · operational-databases