Postgres Binary Protocol Proxying with Kubernetes Ingress

Pods were ready, traffic was flowing, but Postgres connections hit a wall. The problem wasn’t the database. It was the Kubernetes Ingress.

Most Kubernetes Ingress controllers focus on HTTP routing. They handle web traffic well, but anything outside HTTP—like the Postgres binary protocol—often fails or needs ugly workarounds. Postgres speaks its own protocol on TCP port 5432. HTTP-based ingress paths can’t understand it, can’t stream it efficiently, and sometimes can’t proxy it at all. If you want routing, TLS termination, or external access for Postgres inside Kubernetes, this is a hard constraint.

This is where native TCP load balancing in Kubernetes comes into play. Instead of forcing the Postgres binary protocol over HTTP, you use an ingress or a proxy that handles raw TCP directly. Some Ingress controllers support this with custom configuration. NGINX Ingress, for example, has a TCP services config map for mapping external ports to service ports. Traefik supports TCP routers alongside HTTP routers. HAProxy Ingress can do pure TCP proxying with SNI-based routing. All of these approaches bypass HTTP entirely.

For Postgres, this matters. TCP proxying preserves connection handling, streaming responses, and performance. It lets you connect from outside the cluster using standard Postgres clients, without rewriting application logic or tunneling. It also ensures that authentication, SSL, and other protocol-level features work as intended. When Kubernetes services are fronted by a TCP-capable ingress, Postgres just works—inside and outside the cluster.

The setup usually involves:

1. Creating a Kubernetes Service that targets your Postgres Deployment or StatefulSet.
2. Deploying an ingress or load balancer that supports TCP proxying.
3. Mapping an external port (like 5432) to your internal Postgres service.
4. Configuring firewall rules and security policies to control access.

One common pitfall is mixing HTTP and TCP ingress rules in the same listener. For Postgres binary protocol proxying, use a dedicated TCP listener. This avoids protocol confusion and keeps connection handling stable under load. Also watch timeouts—databases often need longer-lived connections than HTTP.

Using Kubernetes Ingress for Postgres binary protocol proxying is a clean solution when done with the right controller. It removes the need for complex bastion hosts or SSH tunnels, keeps your networking simpler, and integrates database access into your cluster’s existing ingress and load balancing patterns.

If you need to see Postgres binary protocol proxying over Kubernetes Ingress done right—without hacking YAML for days—check out hoop.dev. You can deploy it, connect, and watch it work live in minutes.