Conectando o TablePlus ou o psql a um banco sem porta pública

Um banco gerenciado sem porta pública é o padrão correto e, ao mesmo tempo, imediatamente a primeira coisa que entra no caminho de quem quer de fato olhar os dados com uma ferramenta de verdade. TablePlus, psql, redis-cli, clickhouse-client — todos querem conectar a partir de um laptop, e um banco que é privado por design não tem uma porta pra isso pousar.

O que realmente acontece quando você libera um endereço

Trusted addresses, no card do banco ou do add-on, recebe um IP que você quer liberar. O que isso faz na prática: o Railyard abre um proxy TCP no servidor, restrito àquele único endereço — qualquer outra tentativa de conexão contra aquela porta continua bloqueada exatamente como antes, e a senha do banco ainda é exigida além da lista de IPs liberados, não no lugar dela. O card te entrega o comando de conexão pronto pra colar, em vez de te fazer montar uma connection string a partir de um host, uma porta e credenciais que você teria que ir buscar separadamente.

Isso funciona em toda a gama real de engines que o Railyard provisiona: Postgres, MySQL, ClickHouse, Redis, RabbitMQ — e funciona do mesmo jeito tanto se o banco vive no próprio servidor da aplicação quanto num servidor de banco de dados separado.

Por que isso é diferente de “simplesmente abrir a porta”

A solução ingênua pra “eu preciso conectar a partir do meu laptop” é abrir a porta do banco pra internet e confiar só na senha — o que transforma “esqueci de revogar um cliente antigo” e “senha quebrada por força bruta” no mesmo incidente, porque a única coisa entre a internet e o banco sempre foi aquela única senha. Restringir o proxy a um IP específico significa que uma senha vazada por si só não é suficiente — a conexão precisa vir de um endereço explicitamente liberado, que é o ponto real de uma defesa em profundidade em vez de um único checkpoint.

O que você ganha depois de de fato conectar

A aba Insights do console do banco vale conhecer antes de precisar dela sob pressão: taxas de acerto de cache e índice, conexões ativas contra max_connections, tamanho do banco, as queries mais lentas e mais frequentes puxadas do pg_stat_statements, queries de longa duração que você pode cancelar direto, e índices que na prática não estão sendo usados. Isso é a maior parte do checklist de diagnóstico inicial de um DBA, já rodando, em vez de algo pra montar separadamente quando uma query lenta de fato se torna um incidente.

Quando o banco nem é o Railyard que gerencia

A aba Resources de uma aplicação também pode provisionar um banco direto na sua própria conta DigitalOcean ou AWS — o Railyard cria, espera ele entrar no ar, e conecta como DATABASE_URL com sslmode=require, com todo o progresso visível em tempo real. Na AWS especificamente, se o servidor da aplicação estiver na mesma região, o banco fica dentro da sua VPC sem nenhuma exposição pública; caso contrário, fica alcançável pela internet, mas restrito ao IP daquele único servidor, o mesmo princípio de restrição do Trusted addresses aplicado no nível de rede em vez do nível do proxy.

Referência completa: Databases and backups.