Connecting TablePlus or psql to a database that has no public port
A managed database with no public port is the correct default and also, immediately, the first thing that gets in the way of actually looking at the data with a real tool. TablePlus, psql, redis-cli, clickhouse-client — all of them want to connect from a laptop, and a database that’s private by design doesn’t have a port for that to land on.
What actually happens when you allow an address
Trusted addresses, on the database or add-on card, takes an IP you want to allow. What that does mechanically: Railyard opens a TCP proxy on the server, scoped to that one address — every other connection attempt against that port stays blocked exactly as before, and the database password is still required on top of the IP allowlist, not instead of it. The card hands you the actual connection command to paste, rather than making you assemble a connection string from a host, port and credentials you have to go find separately.
This works across the real range of engines Railyard provisions: Postgres, MySQL, ClickHouse, Redis, RabbitMQ — and it works the same way whether the database lives on the app’s own server or on a separate database server.
Why this is a different shape than “just open the port”
The naive fix for “I need to connect from my laptop” is opening the database’s port to the internet and relying on the password alone — which turns “forgot to revoke an old client” and “password brute-forced” into the same incident, because the only thing standing between the internet and the database was ever the one password. Scoping the proxy to a specific IP means a leaked password alone isn’t enough — the connection has to originate from an address that was explicitly trusted, which is the actual point of defense in depth rather than a single checkpoint.
What you get once you’re actually connected
The database console’s Insights tab is worth knowing about before you need it under pressure: cache and index hit rates, live connections against max_connections, database size, the slowest and most frequent queries pulled from pg_stat_statements, long-running queries you can cancel directly, and indexes that aren’t actually being used. That’s most of a DBA’s first-pass diagnostic checklist, already running, rather than something to wire up separately when a slow query actually becomes an incident.
When the database isn’t Railyard’s to manage at all
An app’s Resources tab can also provision a database directly in your own DigitalOcean or AWS account instead — Railyard creates it, waits for it to come online, and attaches it as DATABASE_URL with sslmode=require, all progress visible live. On AWS specifically, if the app’s server is in the same region, the database stays inside your VPC with no public exposure at all; otherwise it’s reachable from the internet but locked to that one server’s IP, the same scoping principle as Trusted addresses applied at the network level instead of the proxy level.
Full reference: Databases and backups.