Analytics

Operate ClickHouse

After creating the project, maintain secure access and verify operation with a real query. This page gathers practical checks and product limits. For a first table and aggregation, see Getting started; for DBeaver and clickhouse-client fields, see Connections.

Check status and access

Open your project in the Console and make sure it is ready before connecting. Under Connection, copy the host, database name, username, and both ports from the same project: Native TLS for native drivers, HTTPS/JDBC for DBeaver. Each project gets its own port numbers; another project's port is not a useful reference.

Connect with the right protocol and run an authenticated SELECT 1; then SELECT currentDatabase() checks your active database. If you have a test table, run a read query against it. A ready status, TLS handshake, or /ping does not validate password, privileges, or a SQL query. Do not include your password in support tickets, shell history, or screenshots to prove your test.

Store and rotate the password

The Console shows the usable password only during creation and after rotation. On subsequent reads, the connection URI is masked; the original password cannot be recovered from the card. If it is lost, use change/rotate password in the project edit view and store the new password in a secure manager before dismissing the confirmation.

After successful rotation, Zenifra updates and verifies the project's instances: the new password works over both Native TLS and HTTPS; the old password is rejected. Update applications, jobs, and clients that used the previous password. Test the new connection with SELECT 1 on the protocols you actually use, then remove the old credential from settings and shares. Avoid rotating during a critical operation without preparing your consumers for the change.

If rotation fails or is still in progress, do not assume which password is active: check project status and run an authenticated test before updating every consumer. Never send passwords to support; provide only the time, sanitized error message, and protocol/port used.

Topology and tables

Sandbox and Starter have one instance; Production and Enterprise have three replicas. In the app database, DDL is replicated and ReplicatedMergeTree is the default table engine for Zenifra's user. A table explicitly created with MergeTree does not gain data replication from the plan name. Check the engine in your DDL when porting schemas, and use Analytics plans to choose capacity and availability. An isolated SELECT 1 is not proof that a particular table is replicated.

Storage is persistent. The allowance varies by plan; provisioned logical capacity above it is billed separately using logical_gb. Check configured capacity and current charges in the Console. Used data, allocated capacity, and contractual limits are different measures; do not mistake a usage metric for a storage allowance.

Troubleshoot by symptom

  1. DBeaver rejects the URL: use jdbc:clickhouse:https://, your project's HTTPS/JDBC port, and explicit ssl=true. secure=true belongs to the native URI and does not replace the JDBC setting.
  2. TLS or certificate fails: check the Console hostname, protocol, and SSL settings; retain certificate validation. Do not switch to an IP or “accept invalid certificate”.
  3. HTTP 400 or unknown protocol: check for swapped ports — Native TLS does not speak HTTPS, and HTTPS/JDBC does not speak the native protocol.
  4. HTTP 401 or login fails: check the database, username, and password in the client; 401 without credentials does not prove an authenticated attempt will fail. If you lost the password, rotate it.
  5. Connected but no tables: run SELECT currentDatabase(), check that the expected database is active, then query a known table. A non-replicated engine can affect data visibility between instances.
  6. Project is not ready yet: wait for creation to finish in the Console before retrying queries; if it persists, report the project ID and sanitized error, never credentials.

Next steps

On this page