PostgreSQL Studio

Prerequisites and boundaries

• PostgreSQL must be installed and active on the server. If the engine card reports that PostgreSQL is unavailable, an administrator must complete the supported installation workflow first.
• Your Core Panel account must have access to the website and its database controls. Visibility depends on the assigned role and access package.
• Confirm the PostgreSQL major version and every extension required by the application before creating production data.
• PostgreSQL Studio is an administration aid; it does not replace application migrations, query review, capacity testing, or a recovery plan.

Create a PostgreSQL database

1. Open the website in Core Panel and select Databases .
2. Select the PostgreSQL engine view.
3. Select Add database .
4. Enter a database name, a new application username, and a unique password containing at least 12 characters.
5. Leave allowed remote IPv4 addresses empty unless the application must connect from another trusted host.
6. Select Create database and user , then confirm that the database appears as active.

Use the generated database, host, port, username, and password in the application's secret configuration. Do not commit a connection URL or password to source control.

Create and scope PostgreSQL users

The creation workflow provisions a dedicated managed user for the database. Use one identity per application or trust boundary rather than sharing a PostgreSQL administrative account. The managed user is intended for the selected database; do not give application code cluster-wide or superuser access.

• Copy connection details only into the approved deployment secret store.
• Use the database action to rotate credentials, then update the application and verify reconnection.
• Test one permitted operation and one operation that should be denied; a successful login alone does not prove least privilege.
• Advanced roles, memberships, ownership changes, schema grants, default privileges, row-level security, and service identities require deliberate PostgreSQL administration with native tools.

Open PostgreSQL Studio

1. Open the website's Databases tab and select PostgreSQL .
2. Find the active database and open its actions.
3. Select Open PostgreSQL Studio . Core Panel opens the authenticated workspace for that managed database.
4. Confirm the database identity shown in the workspace before inspecting or changing data. Close the Studio tab when the task is complete.

Do not share an authenticated Studio URL or leave the workspace open on an untrusted computer. Panel access controls and the database user's scope remain part of the security boundary.

Browse schemas, tables, and rows

1. Use the schema browser to choose an application schema. Do not assume every object is in public .
2. Select a table to inspect its supported structure and row view. Verify the schema and table name before taking an action.
3. Use filters and bounded result views when available instead of loading an entire large table.
4. Treat row changes as production data changes. Prefer application workflows or reviewed migrations for repeatable updates.

PostgreSQL Studio is suitable for supported routine inspection. Complex joins, execution plans, bulk changes, long-running queries, schema migrations, and scripted administration belong in reviewed native tooling.

Remote-access boundaries

Keep PostgreSQL private to the server or trusted network by default. Core Panel's allowed-remote-address field accepts exact IPv4 sources for a managed database. Add a source only when a real application or operator workflow requires it.

• Use a stable, known source address; do not open PostgreSQL to every internet address.
• Confirm the host firewall, PostgreSQL listener, authentication rules, and provider network controls enforce the intended boundary.
• Require encrypted connections when traffic crosses an untrusted network and validate the server certificate where the client supports it.
• Remove temporary source addresses immediately after the maintenance task and review authentication failures.
• Prefer a VPN, private network, or SSH tunnel over direct public database exposure when the architecture supports it.

A panel allow-list entry is not a substitute for an end-to-end network and PostgreSQL configuration review. Test the approved source and confirm an unapproved source is denied.

Back up and restore PostgreSQL

Create a manual logical export

1. Open the active PostgreSQL database actions and select the SQL export action.
2. Store the export in a protected location away from the source server and record the database, time, PostgreSQL version, and checksum.
3. Keep multiple recovery points according to the application's recovery point objective and retention policy.

Automate a custom-format archive

For scheduled logical backups, run reviewed native commands through a protected script and a Core Panel cron job. Use a dedicated backup identity or another approved authentication method; do not place the password in the command or shell history.

pg_dump --format=custom --no-owner --no-acl \
  --file=/protected/path/app_database.dump app_database
pg_restore --list /protected/path/app_database.dump > /dev/null
sha256sum /protected/path/app_database.dump

Restore and verify

1. Prepare an isolated PostgreSQL target with a compatible version, required extensions, sufficient disk capacity, and no production application traffic.
2. Verify the downloaded archive checksum and list the archive before restoring it.
3. Create an empty target database and restore with pg_restore for a custom archive or psql for a reviewed plain SQL export. Capture all output.
4. Validate schemas, roles, extensions, migrations, critical row-level invariants, representative reads and writes, and application startup.
5. Record the complete recovery time and compare the recovered data timestamp with the recovery point objective.

createdb app_database_restore_test
pg_restore --exit-on-error --no-owner --no-acl \
  --dbname=app_database_restore_test /protected/path/app_database.dump

A successful export is not a verified backup. Repeat an isolated application-level restore drill after major version changes, backup-tool changes, material database growth, and recovery-policy changes. Logical dumps may not meet a low RPO or short RTO; physical backups, WAL archiving, and point-in-time recovery require a separate native PostgreSQL design.

Tasks that require native PostgreSQL tools

Run native tools from a controlled operator environment with the least privilege required. Review commands, protect credentials, capture relevant output, and maintain a rollback or recovery plan before production changes.

Production verification checklist

• The application-supported PostgreSQL version and required extensions are recorded and tested.
• Each application uses a dedicated managed identity and cannot perform an intentionally forbidden action.
• Remote access is disabled or limited to exact approved sources and verified by a negative test.
• PostgreSQL Studio opens only for the intended database and operators understand its supported scope.
• Backups are automatic, monitored, protected off-server, retained across several recovery points, and covered by a successful isolated restore drill.
• Connection use, slow queries, locks, disk growth, errors, and backup freshness have owners and alert runbooks.
• Native-tool procedures exist for migrations, advanced privileges, extensions, tuning, and recovery work outside PostgreSQL Studio.