Clickhouse

​

Prerequisites

• If your ClickHouse security posture requires IP whitelisting, have our data syncing service’s static IP available during the following steps. It will be required in Step 1.

​

Step 1: Allow access

🚩 SSH Tunneling Not Supported SSH Tunneling is currently unsupported for Clickhouse destinations. Please ensure your Clickhouse destination is accessible over the public internet.

1. incoming connections to your host and port (usually 9440) from 35.192.85.117.
2. outgoing connections from ports 1024 to 65535 to 35.192.85.117.

​

Step 2: Create writer user

1. Open a connection to your ClickHouse database.
2. Create a user for the data transfer by executing the following SQL command.

CREATE USER <username>@'%' IDENTIFIED BY '<some-password>';

🔒 Password Rules Passwords may only include alphanumeric characters (A-Z, a-z, 0-9), dashes (-), and underscores (_).

3. Grant user required privileges on the database.

GRANT SELECT ON information_schema.columns TO <username>;
GRANT SELECT, CREATE, INSERT, DROP, ALTER, OPTIMIZE, SHOW, TRUNCATE ON <database>.* TO <username>@'%';
grant CREATE TEMPORARY TABLE, S3 on *.* to <username>@'%';

📘 Understanding the CREATE TEMPORARY TABLE, S3 permissions The CREATE TEMPORARY TABLE and S3 permissions are required to efficiently transfer data to ClickHouse. Under the hood, these permissions are used to stage data in object storage as compressed files, COPY INTO temporary tables, and finally merge into the target tables. By definition, the temporary table will not exist outside of the session. The S3 permission is required for both S3 and GCS staging buckets, because ClickHouse accesses GCS buckets through its S3 integration.

​

Step 3: Set up staging bucket

• S3 staging bucket. See Appendix A: S3 staging bucket.
• GCS staging bucket. See Appendix B: GCS staging bucket.

🧹 Optional: Add a short retention lifecycle policy You may configure a lifecycle rule on the bucket to automatically delete objects older than 2 days as the bucket is not used to persist data. Note that transfer logic automatically cleans up files after transfer completion, so this is an optional step.

​

Granting ClickHouse Cloud role-based access to S3

{
    "Version": "2012-10-17",
    "Statement": [
        {
            // Existing statements
        },
        {
            "Effect": "Allow",
            "Principal": {"AWS": "<CLICKHOUSE_IAM_ARN>"},
            "Action": "sts:AssumeRole"
        }
    ]
}

​

Step 4: Add your destination

🔌 Connection Protocol Use the ClickHouse TCP native protocol, not HTTPS. This is commonly exposed on port 9000.

📘 Understanding the database vs. schema fields (connection database vs. write database) Depending on the version of your integration, you may be asked for both a database and schema, or a connection database and write database.

• database (also referred to as connection_database): is the database used to establish the connection with ClickHouse.
• schema (also referred to as write_database): is the database/schema within which data will be written

These can be (and often are) the same values, but do not need to be.

​

Using the ClickHouse data

📘 Querying ClickHouse data without duplicates The resulting ClickHouse tables use the ReplacingMergeTree table engine in order to efficiently upsert changes. To properly query this data, the FINAL keyword must be used when selecting from these tables guarantee duplicates are removed. For example:

SELECT
  *
FROM
  schema.table FINAL
WHERE
  foo = bar
ORDER BY foo
LIMIT 10;

​

Permissions checklist

• User has SELECT on information_schema.columns.
• User has SELECT, CREATE, INSERT, DROP, ALTER, OPTIMIZE, SHOW, TRUNCATE on <database>.*.
• User has CREATE TEMPORARY TABLE, S3 on *.*.
• Staging bucket configured (S3 or GCS).
• Firewall or security group allows the service’s egress IP on the ClickHouse native protocol port (default: 9440 for TLS, 9000 for TCP).
• Password uses only alphanumeric characters, dashes (-), or underscores (_).

​

FAQ

​

Q: How is the ClickHouse connection secured?

​

Appendix A: S3 staging bucket

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRoleWithWebIdentity"
      ],
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Condition": {
        "StringEquals": {
          "accounts.google.com:oaud": "<some_organization_identifier>",
          "accounts.google.com:sub": "<some_service_account_identifier>"
        }
      }
    }
  ]
}

​

Create staging bucket

1. Navigate to the S3 service page.
2. Click Create bucket.
3. Enter a Bucket name and modify any of the default settings as desired. Note: Object Ownership can be set to “ACLs disabled” and Block Public Access settings for this bucket can be set to “Block all public access” as recommended by AWS. Make note of the Bucket name and AWS Region.
4. Click Create bucket.

​

Create policy

1. Navigate to the IAM service page, click on the Policies navigation tab, and click Create policy.
2. Click the JSON tab, and paste the following policy, being sure to replace BUCKET_NAME with the name of the bucket chosen above.
   1. Note: the first policy applies to BUCKET_NAME whereas the second policy applies only to the bucket’s contents (BUCKET_NAME/*), an important distinction.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::BUCKET_NAME"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::BUCKET_NAME/*"
        }
    ]
}

3. Click through to the Review step, choose a name for the policy, for example, transfer-service-policy (this will be referenced in the next step), add a description, and click Create policy.

​

Create role

1. Navigate to the IAM service page.
2. Navigate to the Roles navigation tab, and click Create role.
3. Select Custom trust policy and paste the provided trust policy to allow AssumeRole access to the new role. Click Next.
4. Add the permissions policy created above, and click Next.
5. Enter a Role name, for example, transfer-role, and click Create role.
6. Once successfully created, search for the created role in the Roles list, click the role name, and make a note of the ARN value.

​

Appendix B: GCS staging bucket

​

Create a service account

1. In the GCP console, navigate to the IAM & Admin menu.
2. Click into the Service Accounts tab.
3. Click Create service account at the top of the menu.
4. In the first step, name the service account that will be used to transfer data into Cloud Storage and click Create and Continue. You may continue through the following steps without assigning any roles, and in the final step, click Done.

​

Create staging bucket

1. Navigate to the Cloud Storage page.
2. Click Create.
3. Enter a bucket name, choose a region.
4. After choosing your preferences for the remaining steps, click Create. (If presented with a warning, you may enforce public access prevention)
5. On the Bucket details page for the bucket you created, select the Permissions tab, and click Grant access.
6. Grant access to the Service Account you created above, and assign the Role: Storage Object User. Click Save.

​

Generate HMAC key

1. Navigate to the Cloud Storage page.
2. Click into the Settings tab on the left side menu.
3. In the Interoperability tab, click the Create a key for a Service Account button.
4. Select the Service Account created above, and click Create key.

5. Make a note of the Access key and Secret.

📘 Depending on the connection method, you may need to refer to the following field name mappings:

• Bucket Access ID: your HMAC Access Key.
• Bucket Secret Key: your HMAC Secret.