NGINX Ingress Controller can be improved, and my team's concern would be database protocol-aware health checks for Transport Server since that is what NGINX is more focused on. Right now, even on Plus, a Transport Server health check is essentially a TCP connect or maybe a basic send-expect. For a database, that is a weak signal. The listener being up tells you almost nothing about whether Postgres is actually serving, whether a replica is lagging, or whether it is in recovery. I would love a way to define a health check that does something protocol-aware, even something as simple as you open a connection, run a SELECT one, which is the most popular test, and expect a row for Postgres or a PING for Redis. Without that, I am relying on the database's own infrastructure to pull bad replicas, and the ingress will happily continue routing to a replica that answers TCP but is serving stale reads. Better idle connection management for long-lived stream connections can also be improved. A pooled database connection sitting idle between transactions is healthy in my opinion, but the proxy's instinct is to reap idle connections. You can crank timeouts way up, but that is a blunt instrument. I would like to add that specifically for databases, the need for improvement becomes clearer. Every client connection through NGINX becomes a backend connection, one-to-one. A client connection through NGINX and a client connection through a connection pooler are sitting because they are going to get sent to the backend connection. It does not multiplex; it does not understand transaction boundaries. It cannot reuse a connection across clients. If you put it in front of Postgres without a real pooler behind it, you have just built a very efficient way to exhaust the max connection. The architecture is always client, ingress, connection pooler which is either pgBouncer or ProxySQL, then the actual engine which is Postgres or MySQL. Never let it be clients straight to the database. NGINX Ingress Controller's mode is one client connection to one backend connection with no multiplexing and no protocol awareness, which would be an issue for you.
