ClickHouse
Prepare a ClickHouse Cloud reader user and select the tables to share.
This connector version uses ClickHouse Cloud’s HTTPS interface with a host, port, username and password. These are separate from your ClickHouse Cloud console login.
Prepare the ClickHouse user
The service owner creates a dedicated SQL user and grants read access only to the required tables. They should also configure a read-only profile and resource limits suited to the service.
Example for the service owner to adapt: analytics.weekly_sales must already exist. Replace the password with a unique value.
CREATE SETTINGS PROFILE persyst_readonly
SETTINGS readonly = 1, max_execution_time = 30, max_rows_to_read = 10000000;
CREATE USER persyst_reader
IDENTIFIED WITH sha256_password BY '<UNIQUE_PASSWORD>'
SETTINGS PROFILE persyst_readonly;
GRANT SELECT ON analytics.weekly_sales TO persyst_reader;
GRANT SELECT(role_name, user_name) ON system.role_grants TO persyst_reader;
GRANT SELECT(database, table, column_names, access_type, user_name, role_name)
ON system.grants TO persyst_reader;The numerical limits above are examples to adapt to your workload. The two system-table grants let Persyst discover which columns the user can read. They expose grant metadata; have the service owner approve that visibility. They do not grant reads on business data.
Configure quotas and execution limits in ClickHouse according to your workload. Grant each additional table explicitly to this user.
Find the service address
In the ClickHouse Cloud console, open Connect on the service and retrieve its HTTPS connection host. Persyst defaults to port 8443. Use the HTTPS port supplied by your service, not the native protocol port.
The service must accept network connections from Persyst. Have the ClickHouse owner confirm network rules.
Connect the service in Persyst
- In Data sources → Add a source, choose ClickHouse.
- Name the connection and enter the host, HTTPS port, SQL username and password.
- Test the connection and create the connector.
- Select the tables to make available, then save.
- In Access management, grant these tables and tools to the relevant teams or members.
This form has no database field: discovery can show tables from several databases accessible to the SQL user. Table selection and grants are still required.
Verify and maintain access
An authorized member can ask their assistant to describe a selected table, then calculate an aggregate on it. The connector exposes SQL reads on granted tables.
Use Edit credentials to change the username or password. When editing, leaving the password blank preserves the existing secret. Refresh tables after changing ClickHouse permissions.
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 ClickHouse Cloud service for Persyst.
Inspect schema metadata first; do not read production rows unnecessarily.
Persyst uses HTTPS/TLS with a host, HTTPS port (default 8443), SQL username
and password, not a Cloud console login, OAuth token or SDK/API key.
Classify every relevant table as safe, sensitive, or excluded.
Grant safe tables directly. For sensitive tables, create explicit-column
views of approved columns/rows and do not grant the base tables.
Check the view security model for this ClickHouse version so the reader
can use the view without gaining direct access to the sensitive source.
Never use SELECT * in an approved view.
Exclude secrets, credentials, hashes, tokens, keys and OTP/MFA data.
Exclude personal data by default: names, emails, phone/address details,
national/financial identifiers, IP/device identifiers, precise location
and unredacted free text. Opaque IDs are not automatically anonymous.
Create a dedicated user, never an admin/default user, and a SETTINGS
PROFILE with readonly = 1 plus workload-appropriate max_execution_time,
max_rows_to_read and other server-side resource limits.
Grant SELECT only on approved tables/views and the discovery metadata:
GRANT SELECT(role_name, user_name) ON system.role_grants TO <reader>;
GRANT SELECT(database, table, column_names, access_type, user_name, role_name)
ON system.grants TO <reader>;
Persyst reads these grants to discover permitted columns. They expose grant
metadata: review this visibility with the service owner. Do not grant
SELECT on all system tables or all business databases as a shortcut.
Output: classification and exclusions; explicit-column view SQL; settings
profile and dedicated user SQL; minimal grants; verification as the reader
(approved reads and write rejection without modifying real data); and
non-secret host, HTTPS port and username for the Persyst form.
Have the owner validate network access. Use password placeholders only.
Generate/store the password locally and enter it directly in Persyst;
never print it or paste it into this chat. Prepare SQL for review before
applying account or permission changes.References: creating a ClickHouse user, assistant permissions and limits.