Connecter TablePlus ou psql à une base de données qui n'a aucun port public
Une base de données gérée sans port public est le bon réglage par défaut et aussi, immédiatement, la première chose qui empêche de vraiment regarder les données avec un vrai outil. TablePlus, psql, redis-cli, clickhouse-client — tous veulent se connecter depuis un ordinateur portable, et une base de données privée par conception n’a pas de port où ça puisse atterrir.
Ce qui se passe vraiment quand on autorise une adresse
Trusted addresses, sur la carte de la base de données ou de l’addon, prend une IP que vous voulez autoriser. Ce que ça fait mécaniquement : Railyard ouvre un proxy TCP sur le serveur, limité à cette seule adresse — toute autre tentative de connexion contre ce port reste bloquée exactement comme avant, et le mot de passe de la base de données est toujours exigé en plus de la liste blanche d’IP, pas à sa place. La carte vous donne directement la commande de connexion à coller, plutôt que de vous faire assembler une chaîne de connexion à partir d’un hôte, d’un port et d’identifiants à aller chercher séparément.
Ça fonctionne sur le vrai éventail de moteurs que Railyard provisionne : Postgres, MySQL, ClickHouse, Redis, RabbitMQ — et ça fonctionne de la même façon que la base de données vive sur le propre serveur de l’application ou sur un serveur de base de données séparé.
Pourquoi c’est une forme différente de « juste ouvrir le port »
La correction naïve pour « j’ai besoin de me connecter depuis mon ordinateur portable » est d’ouvrir le port de la base de données à internet et de compter uniquement sur le mot de passe — ce qui transforme « oublié de révoquer un vieux client » et « mot de passe forcé par force brute » en le même incident, parce que la seule chose qui se trouvait entre internet et la base de données a toujours été ce seul mot de passe. Limiter le proxy à une IP spécifique veut dire qu’un mot de passe qui a fuité seul ne suffit pas — la connexion doit provenir d’une adresse explicitement autorisée, ce qui est le vrai point d’une défense en profondeur plutôt qu’un seul point de contrôle.
Ce qu’on obtient une fois vraiment connecté
L’onglet Insights de la console de base de données mérite d’être connu avant d’en avoir besoin sous pression : taux de succès du cache et des index, connexions en direct contre max_connections, taille de la base de données, les requêtes les plus lentes et les plus fréquentes tirées de pg_stat_statements, les requêtes longues qu’on peut annuler directement, et les index qui ne sont en fait pas utilisés. C’est la plupart de la liste de diagnostic de premier passage d’un DBA, déjà en marche, plutôt que quelque chose à câbler séparément quand une requête lente devient vraiment un incident.
Quand la base de données n’est pas du tout à gérer par Railyard
L’onglet Resources d’une application peut aussi provisionner une base de données directement dans votre propre compte DigitalOcean ou AWS à la place — Railyard la crée, attend qu’elle soit en ligne, et l’attache comme DATABASE_URL avec sslmode=require, toute la progression visible en direct. Sur AWS spécifiquement, si le serveur de l’application est dans la même région, la base de données reste à l’intérieur de votre VPC sans aucune exposition publique; sinon elle est accessible depuis internet mais verrouillée à l’IP de ce seul serveur, le même principe de limitation que Trusted addresses mais appliqué au niveau réseau plutôt qu’au niveau du proxy.
Référence complète : Bases de données et sauvegardes.