PostgreSQL

The connection uses a host, port, database name, username and password. The database owner prepares the account; a Persyst admin saves the connection and grants access to tables.

Prepare a reader accountCopy section link

Ask the PostgreSQL owner for a dedicated user without administrative or write permissions, restricted to the required tables or views. Prefer dedicated views when some columns or rows must remain outside the shared scope.

The database owner should adapt and run this example. reporting and weekly_sales refer to an existing schema and table or view; replace business_db and the password too.

CREATE ROLE persyst_reader LOGIN PASSWORD '<UNIQUE_PASSWORD>';
GRANT CONNECT ON DATABASE business_db TO persyst_reader;
GRANT USAGE ON SCHEMA reporting TO persyst_reader;
GRANT SELECT ON reporting.weekly_sales TO persyst_reader;

These statements apply to the named table or view. The PostgreSQL owner must authorize any additional resource separately.

Prepare network accessCopy section link

The host must be reachable from the Persyst server. A localhost address refers to that server, not your computer. Have your database owner validate network access and transport requirements before entering credentials.

Connect the database in PersystCopy section link

1. In Data sources → Add a source, choose PostgreSQL.
2. Name the connection and enter the host, provider-supplied port (5432 by default), database, username and password.
3. Test the connection, then create it to continue to table selection.
4. Select only the tables or views to make available, then save the selection.
5. In Access management, grant the tables and read tools to their intended recipients.

PostgreSQL permissions and Persyst selection work together. Selecting an entire table does not hide individual columns or rows.

Verify and maintain accessCopy section link

From an authorized member’s assistant, request the schema of a selected table, then a count on that table. Queries are restricted to reads and allowed tables.

To replace the password, use Edit credentials on the source page. When editing, leaving the password blank preserves the existing secret. After changing PostgreSQL permissions, refresh the table list and review grants.

Prompt to prepare read-only access

Copy this prompt to the assistant used by your database owner. It recovers the setup checklist: table classification, filtered views and a dedicated reader. Review its proposed SQL against your actual schema before running it. Keep credentials out of the conversation.

You are helping prepare a PostgreSQL database for Persyst.
Inspect schema metadata first; do not read production rows unnecessarily.

Goal: a dedicated SELECT-only account limited to useful approved data.
Classify every relevant table as safe, sensitive, or excluded.
Grant safe tables directly. For sensitive tables, expose explicit-column
views containing only approved columns and rows; never use SELECT *.
Do not grant the underlying sensitive tables to the reader.

Exclude credentials, password hashes, API keys, tokens, private keys,
OTP/MFA secrets and webhook secrets. Exclude personal data by default:
names, emails, phone numbers, addresses, national and financial identifiers,
IP/device identifiers, precise location and unredacted free text.
Opaque IDs may still be personal data; do not assume they are anonymous.
Do not join approved views back to excluded personal data.

Provide reviewed SQL to create a dedicated LOGIN role with no superuser,
role-creation, database-creation, write, ownership or privileged memberships.
Grant CONNECT on the required database, USAGE on the required schemas,
and SELECT only on approved tables/views. Review inherited/PUBLIC grants,
function execution and view security under this PostgreSQL version.
Do not grant access automatically to future tables.

Output: classification and exclusions; explicit-column view definitions;
role and minimal GRANT statements; verification queries as the reader;
and the non-secret host, port, database and username for the Persyst form.
Confirm allowed reads and rejection of writes without modifying real data.
Have the database owner validate network and transport compatibility.
Use password placeholders. Generate/store the real password locally and
enter it directly in Persyst; never print it or paste it into this chat.
Prepare the SQL for review before applying account or permission changes.

Reference: PostgreSQL permissions with GRANT.