TablePlus oder psql mit einer Datenbank ohne öffentlichen Port verbinden
Eine Managed-Datenbank ohne öffentlichen Port ist die richtige Standardeinstellung – und zugleich sofort das erste Hindernis, wenn du die Daten tatsächlich mit einem echten Tool ansehen willst. TablePlus, psql, redis-cli, clickhouse-client – sie alle wollen sich von einem Laptop aus verbinden, und eine Datenbank, die per Design privat ist, hat dafür keinen Port.
Was beim Erlauben einer Adresse technisch passiert
Trusted addresses, auf der Datenbank- oder Add-on-Karte, nimmt eine IP entgegen, die du erlauben willst. Was das mechanisch bewirkt: Railyard öffnet auf dem Server einen TCP-Proxy, der auf genau diese eine Adresse beschränkt ist – jeder andere Verbindungsversuch gegen diesen Port bleibt genau wie vorher blockiert, und das Datenbankpasswort wird weiterhin zusätzlich zur IP-Allowlist verlangt, nicht stattdessen. Die Karte liefert dir den fertigen Verbindungsbefehl zum Einfügen, statt dich einen Connection-String aus Host, Port und Zugangsdaten selbst zusammenbauen zu lassen.
Das funktioniert über die ganze Bandbreite der Engines, die Railyard bereitstellt: Postgres, MySQL, ClickHouse, Redis, RabbitMQ – und zwar gleich, ob die Datenbank auf dem Server der App selbst läuft oder auf einem separaten Datenbankserver.
Warum das anders ist als “einfach den Port öffnen”
Die naive Lösung für “ich muss mich von meinem Laptop aus verbinden” ist, den Datenbank-Port ins Internet zu öffnen und sich allein auf das Passwort zu verlassen – wodurch “vergessen, einen alten Client zu widerrufen” und “Passwort per Brute-Force geknackt” zum selben Vorfall werden, weil zwischen Internet und Datenbank immer nur dieses eine Passwort stand. Den Proxy auf eine bestimmte IP zu beschränken bedeutet, dass ein geleaktes Passwort allein nicht reicht – die Verbindung muss von einer Adresse ausgehen, die explizit vertraut wurde. Das ist der eigentliche Punkt von Defense in Depth statt eines einzigen Checkpoints.
Was du bekommst, sobald du tatsächlich verbunden bist
Der Insights-Tab der Datenbankkonsole ist es wert, bekannt zu sein, bevor du ihn unter Druck brauchst: Cache- und Index-Hit-Raten, aktive Verbindungen gegenüber max_connections, Datenbankgröße, die langsamsten und häufigsten Queries aus pg_stat_statements, lang laufende Queries, die du direkt abbrechen kannst, und Indizes, die tatsächlich nicht genutzt werden. Das ist der größte Teil der ersten diagnostischen Checkliste eines DBA – bereits laufend, statt etwas, das du separat einrichten musst, wenn eine langsame Query tatsächlich zum Vorfall wird.
Wenn die Datenbank gar nicht Railyards Aufgabe ist
Der Resources-Tab einer App kann auch eine Datenbank direkt in deinem eigenen DigitalOcean- oder AWS-Account bereitstellen – Railyard erstellt sie, wartet, bis sie online ist, und hängt sie als DATABASE_URL mit sslmode=require an, der ganze Fortschritt live sichtbar. Speziell bei AWS: Liegt der Server der App in derselben Region, bleibt die Datenbank vollständig innerhalb deiner VPC, ohne jede öffentliche Erreichbarkeit; andernfalls ist sie vom Internet aus erreichbar, aber auf die IP genau dieses einen Servers beschränkt – dasselbe Scoping-Prinzip wie bei Trusted addresses, nur auf Netzwerkebene statt auf Proxy-Ebene angewendet.
Vollständige Referenz: Datenbanken und Backups.