Conectar TablePlus o psql a una base de datos sin puerto público

Una base de datos administrada sin puerto público es el valor por defecto correcto y, al mismo tiempo, inmediatamente, lo primero que se te atraviesa cuando de verdad quieres mirar los datos con una herramienta real. TablePlus, psql, redis-cli, clickhouse-client — todos quieren conectarse desde una laptop, y una base de datos que es privada por diseño no tiene un puerto donde eso pueda aterrizar.

Qué pasa en realidad cuando permites una dirección

Trusted addresses, en la tarjeta de la base de datos o del complemento, recibe la IP que quieres permitir. Lo que eso hace mecánicamente: Railyard abre un proxy TCP en el servidor, limitado a esa única dirección — cualquier otro intento de conexión contra ese puerto sigue bloqueado exactamente como antes, y la contraseña de la base de datos sigue siendo necesaria además de la lista de IPs permitidas, no en su lugar. La tarjeta te da el comando de conexión real para pegar, en vez de hacerte armar un connection string a partir de un host, un puerto y credenciales que tendrías que ir a buscar por separado.

Esto funciona en toda la gama real de motores que Railyard aprovisiona: Postgres, MySQL, ClickHouse, Redis, RabbitMQ — y funciona igual sin importar si la base de datos vive en el propio servidor de la app o en un servidor de bases de datos aparte.

Por qué esto es distinto de simplemente “abrir el puerto”

La solución ingenua para “necesito conectarme desde mi laptop” es abrir el puerto de la base de datos a internet y confiar solo en la contraseña — lo cual convierte “olvidé revocar un cliente viejo” y “contraseña reventada por fuerza bruta” en el mismo incidente, porque lo único que estuvo entre internet y la base de datos siempre fue esa única contraseña. Limitar el proxy a una IP específica significa que una contraseña filtrada por sí sola no alcanza — la conexión tiene que originarse desde una dirección que fue permitida explícitamente, que es el verdadero sentido de la defensa en profundidad y no un único punto de control.

Qué obtienes una vez que de verdad estás conectado

La pestaña Insights de la consola de la base de datos vale la pena conocerla antes de necesitarla bajo presión: tasas de aciertos de caché e índices, conexiones en vivo contra max_connections, tamaño de la base de datos, las consultas más lentas y más frecuentes extraídas de pg_stat_statements, consultas de larga duración que puedes cancelar directamente, e índices que en realidad no se están usando. Eso es la mayor parte de la lista de diagnóstico de primera pasada de un DBA, ya corriendo, en vez de algo que armar por separado cuando una consulta lenta se convierte de verdad en un incidente.

Cuando la base de datos ni siquiera es de Railyard para administrar

La pestaña Resources de una app también puede aprovisionar una base de datos directamente en tu propia cuenta de DigitalOcean o AWS en su lugar — Railyard la crea, espera a que quede en línea, y la conecta como DATABASE_URL con sslmode=require, todo el progreso visible en vivo. En AWS específicamente, si el servidor de la app está en la misma región, la base de datos se queda dentro de tu VPC sin ninguna exposición pública; de lo contrario queda alcanzable desde internet pero restringida a la IP de ese único servidor, el mismo principio de limitación que Trusted addresses pero aplicado a nivel de red en vez de a nivel de proxy.

Referencia completa: Bases de datos y backups.