Connect to ClickHouse
Start under Console → ClickHouse project → Connection. Copy the host, username, database, and ports of your own project; these port numbers vary between projects. If you lost the password shown during creation, read Passwords and operations before trying to connect.
Choose a port for your client
| Client | Protocol | Console value | TLS |
|---|---|---|---|
| DBeaver with ClickHouse driver and JDBC/HTTP clients | HTTPS/JDBC | HTTPS/JDBC port | SSL enabled |
clickhouse-client and native drivers | Native TLS | Native TLS port; clickhouse://…?secure=true URI | --secure |
The ports are different and not interchangeable. A clickhouse:// URI speaks the native protocol: do not paste it in a JDBC URL field or replace its port with the HTTPS one. If the Console does not show the HTTPS/JDBC port, do not calculate or guess it from the other port.
DBeaver step by step (HTTPS/JDBC)
- Create a connection with Analytical → ClickHouse. Prefer the current ClickHouse driver rather than ClickHouse Legacy. If prompted to install a driver, confirm.
- On Main, enter Host, Port (the HTTPS/JDBC port), Database, Username, and Password from the Console. For new connections, the database is usually
app; check your own project's value. - Under SSL, enable Use SSL and keep certificate validation enabled. Do not accept invalid certificates or replace the hostname with an IP address.
- If using Connect by → URL, supply the complete JDBC URL, not just
https://. Replace the host and port with your project's values; useapponly when that is the database shown in the Console. Enter the username and password in their dedicated fields, not the URL:
jdbc:clickhouse:https://HOST_FROM_CONSOLE:HTTPS_JDBC_PORT/app?ssl=true- Do not omit
ssl=true: include it explicitly, even withhttps://and Use SSL enabled. In a real DBeaver-to-Zenifra flow, the connection failed withoutssl=trueand worked with it. The general JDBC reference describes it as optional when HTTPS is selected; that general rule does not replace the DBeaver configuration validated in this case. - Click Test Connection. After connecting, run
SELECT 1andSELECT currentDatabase()to verify authentication and the active database.
The jdbc:clickhouse: prefix is required in the JDBC URL field: https://… alone triggers Invalid JDBC URL. secure=true belongs to the Native TLS clickhouse://…?secure=true URI; it does not replace ssl=true in the JDBC example. A screenshot of one URL error only shows that attempt and does not explain every failed connection. DBeaver UI can differ by version; see the official DBeaver instructions as well.
clickhouse-client step by step (Native TLS)
Use the Console's Native TLS port, not its HTTPS/JDBC port. Keep your password off the command line so the client prompts you without storing it in shell history:
clickhouse-client --host HOST_FROM_CONSOLE --port NATIVE_TLS_PORT --secure \
--user USERNAME_FROM_CONSOLE --database DATABASE_FROM_CONSOLE --query 'SELECT 1'Enter the password at the prompt. --secure enables TLS for the native client; it is not a JDBC property. The official client reference explains connection options. Do not pass a password value through shared shell commands. Do not disable certificate validation to work around hostname or TLS errors.
If the connection fails
- Invalid JDBC URL: check the
jdbc:clickhouse:https://prefix, the HTTPS/JDBC port, andssl=true. - SSL or certificate error: check that SSL is enabled, the hostname comes from the Console, and the CA is trusted; do not accept an invalid certificate as a workaround.
- Protocol error or HTTP
400: make sure you did not send HTTPS to Native TLS or a native protocol to HTTPS. - HTTP
401/ authentication failure: check username and password in your client fields. An unauthenticated request can receive401; compare with an authenticated test. - Connected but tables are missing: run
SELECT currentDatabase()and select the database shown in the Console. First-use examples useapp. - Masked password: the Console cannot retrieve a password after creation. See rotation and troubleshooting.
A successful /ping or an open port only proves endpoint reachability, not SQL authorization. Verify with SELECT 1 using your real client and credentials.