Running PostgreSQL Privately on a NAT VPS

Keep PostgreSQL private by default and expose only the application or a controlled administrative path. A shared public IPv4 address and unusual port number do not replace database authentication, network restrictions or backups.

Prefer local access

If the application runs in the same guest, a Unix socket or loopback listener is often enough. Inspect the effective listen_addresses, port and pg_hba.conf rules. Package locations and default authentication differ by distribution and version.

Do not broaden access to 0.0.0.0/0 merely to make a test pass. Select the required source network and authentication mechanism deliberately. If applications live on separate systems, design a protected network path and TLS as appropriate.

Use an SSH tunnel for administration

Forward a local client port to the database through your assigned NAT SSH endpoint, then connect the database client to your own loopback address. The database can remain unexposed publicly. Keep the local forward bound to loopback and retain normal database authentication.

Make consistent backups

For a simple logical backup by an authorized account, pg_dump -Fc DATABASE_NAME > backup.dump creates a custom-format export. Protect the output, check command success and test pg_restore into a separate test database. Roles, external files and other cluster-level state may require additional backup steps.

Tune memory conservatively on a small VPS. Connection count, work memory and background activity can add up beyond a simple database-size estimate. Do not copy high-memory server tuning into a 1 GiB guest.

See SSH database tunnels, backup recovery and memory checks.

Reference: PostgreSQL backup documentation.