Analytics

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

ClientProtocolConsole valueTLS
DBeaver with ClickHouse driver and JDBC/HTTP clientsHTTPS/JDBCHTTPS/JDBC portSSL enabled
clickhouse-client and native driversNative TLSNative 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)

  1. Create a connection with Analytical → ClickHouse. Prefer the current ClickHouse driver rather than ClickHouse Legacy. If prompted to install a driver, confirm.
  2. 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.
  3. Under SSL, enable Use SSL and keep certificate validation enabled. Do not accept invalid certificates or replace the hostname with an IP address.
  4. If using Connect by → URL, supply the complete JDBC URL, not just https://. Replace the host and port with your project's values; use app only 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
  1. Do not omit ssl=true: include it explicitly, even with https:// and Use SSL enabled. In a real DBeaver-to-Zenifra flow, the connection failed without ssl=true and 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.
  2. Click Test Connection. After connecting, run SELECT 1 and SELECT 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, and ssl=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 receive 401; compare with an authenticated test.
  • Connected but tables are missing: run SELECT currentDatabase() and select the database shown in the Console. First-use examples use app.
  • 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.

Next steps

On this page