Administer a PostgreSQL connection

Bounded pilot, 24 September 2026. This route reads PostgreSQL well headers. It does not provide SQL curve support, arbitrary SQL execution or database writes. File, SQLite and OSDU setup retain their deployment-managed setup.

Before setup

Your deployment operator must approve the database host, port, database, schema, table and transport settings and configure a private encryption key. The gateway host needs network access to that target. Entering a private address in a browser would not make it reachable; this pilot supplies no private-network tunnel.

Ask for a PostgreSQL principal with SELECT access to the approved table and its username/password. Sign into Workspace as a project administrator.

Configure it yourself

1. Open Connections → Administration → Add PostgreSQL connection.
2. Select the approved target. Its database and schema/table are shown.
3. Enter a display name, database username and password. Save credentials.
4. Choose Test access. Success reports the number of rows, not scientific approval.
5. Open Connections → Data sources, expand the connection and select the table.
6. Map well ID, name, X/Y and any depth/operator fields. Declare known CRS, depth unit/type/reference and missing-value interpretation. Unknown context stays unknown; mapping does not convert coordinates or units. Preview, review and add the source.

Saving a connection alone adds no project data. Tables are bounded to 1,000 rows; use an operator-approved filtered view for a larger database. Source selections remain account-owned; this administration feature does not share an administrator’s SQL selection with every member. The retained LAS workflow is the separate qualified path for ordinary scientists.

Maintain access

• Replace credential: after the database password changes, enter the new username and password here, save, and test. This changes Ophiolite’s stored credential; it does not change the password inside PostgreSQL.
• Disable: blocks subsequent reads through Ophiolite. It does not invalidate the upstream password, stop an already authorized request or recall retained/downloaded data.
• Enable: test access again. Offline selections recover through source reconciliation; use Resume if a prior authentication failure left a selection access-denied.
• Unreachable or rejected: verify credentials and reachability from the gateway. Detailed upstream errors are withheld to keep private connection information out of logs/UI.
• Key unavailable: ask the deployment operator to restore the dedicated key or establish a replacement and re-enter credentials. Existing file connections can remain usable while managed credentials fail closed.

Passwords are encrypted at rest and never returned to ordinary users. Backups must contain both the journal and its dedicated connection key. Changing target host, database or table requires a new approved target/authority; password rotation does not. One registration per approved target is supported in this pilot. Test attempts are limited to ten per minute per administrator. No production availability guarantee is implied.