Question​

How can I use API to manage clusters on ClickHouse Cloud?

Answer​

We will use Terraform to configure our infra and ClickHouse Provider

Steps:

1). Create an API Key on Cloud. Follow the docs here - https://clickhouse.com/docs/cloud/manage/openapi

Save the creds locally.

2). Install Terraform using - https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli

You can use Homebrew package manager if you're on Mac.

3). Create a directory anywhere you like:

mkdir test
➜  test pwd
/Users/jaijhala/Desktop/terraform/test

4). Create 2 files: main.tf and secret.tfvars

Copy the following:

main.tf file would be:

terraform {
 required_providers {
   clickhouse = {
     source = "ClickHouse/clickhouse"
     version = "0.0.2"
   }
 }
}

variable "organization_id" {
  type = string
}

variable "token_key" {
  type = string
}

variable "token_secret" {
  type = string
}

provider clickhouse {
  environment 	= "production"
  organization_id = var.organization_id
  token_key   	= var.token_key
  token_secret	= var.token_secret
}


variable "service_password" {
  type = string
  sensitive   = true
}

resource "clickhouse_service" "service123" {
  name       	= "jai-terraform"
  cloud_provider = "aws"
  region     	= "us-east-2"
  tier       	= "development"
  idle_scaling   = true
  password  = var.service_password
  ip_access = [
	{
    	source  	= "0.0.0.0/0"
    	description = "Anywhere"
	}
  ]
}

output "CLICKHOUSE_HOST" {
  value = clickhouse_service.service123.endpoints.0.host
}

You can replace your own parameters like service name, region etc.. in the resources section above.

secret.tfvars is where you'll put all the API Key related info that you downloaded earlier. The idea behind this file is that all your secret credentials will be hidden from the main config file.

It would be something like (replace these parameters):

organization_id = "e957a5f7-4qe3-4b05-ad5a-d02b2dcd0593"
token_key = "QWhhkMeytqQruTeKg"
token_secret = "4b1dNmjWdLUno9lXxmKvSUcPP62jvn7irkuZPbY"
service_password = "password123!"

5). Run terraform init from this directory

Expected output:

Initializing the backend...

Initializing provider plugins...
- Finding clickhouse/clickhouse versions matching "0.0.2"...
- Installing clickhouse/clickhouse v0.0.2...
- Installed clickhouse/clickhouse v0.0.2 (self-signed, key ID D7089EE5C6A92ED1)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/cli/plugins/signing.html

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

6). Run terraform apply -var-file=secret.tfvars command.

Something like:

➜  test terraform apply -var-file=secret.tfvars

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
  + create

Terraform will perform the following actions:

  # clickhouse_service.service123 will be created
  + resource "clickhouse_service" "service123" {
      + cloud_provider = "aws"
      + endpoints      = (known after apply)
      + id             = (known after apply)
      + idle_scaling   = true
      + ip_access      = [
          + {
              + description = "Anywhere"
              + source      = "0.0.0.0/0"
            },
        ]
      + last_updated   = (known after apply)
      + name           = "jai-terraform"
      + password       = (sensitive value)
      + region         = "us-east-2"
      + tier           = "development"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + CLICKHOUSE_HOST = (known after apply)

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

Type yes and hit enter

Side note: Notice it says password = (sensitive value) above. This is because we set sensitive = true for the password in the main.tf file.

7). It will take a couple of mins to create the service but eventually it should come up like:

  Enter a value: yes

clickhouse_service.service123: Creating...
clickhouse_service.service123: Still creating... [10s elapsed]
clickhouse_service.service123: Still creating... [20s elapsed]
clickhouse_service.service123: Still creating... [30s elapsed]
clickhouse_service.service123: Still creating... [40s elapsed]
clickhouse_service.service123: Still creating... [50s elapsed]
clickhouse_service.service123: Still creating... [1m0s elapsed]
clickhouse_service.service123: Still creating... [1m10s elapsed]
clickhouse_service.service123: Still creating... [1m20s elapsed]
clickhouse_service.service123: Still creating... [1m30s elapsed]
clickhouse_service.service123: Still creating... [1m40s elapsed]
clickhouse_service.service123: Creation complete after 1m41s [id=aa8d8d63-1878-4600-8470-630715af38ed]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Outputs:

CLICKHOUSE_HOST = "h3ljlaqez6.us-east-2.aws.clickhouse.cloud"
➜  test

8). Check Cloud Console, you should be able to see the service created.

9). To clean up/destroy the service again, run terraform destroy -var-file=secret.tfvars

Something like:

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with
the following symbols:
  - destroy

Terraform will perform the following actions:

  # clickhouse_service.service123 will be destroyed
  - resource "clickhouse_service" "service123" {
      - cloud_provider = "aws" -> null
      - ............

Plan: 0 to add, 0 to change, 1 to destroy.

Changes to Outputs:
  - CLICKHOUSE_HOST = "h3ljlaqez6.us-east-2.aws.clickhouse.cloud" -> null

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value:

Type yes and hit enter

10).

clickhouse_service.service123: Destroying... [id=aa8d8d63-1878-4600-8470-630715af38ed]
clickhouse_service.service123: Still destroying... [id=aa8d8d63-1878-4600-8470-630715af38ed, 10s elapsed]
clickhouse_service.service123: Still destroying... [id=aa8d8d63-1878-4600-8470-630715af38ed, 20s elapsed]
clickhouse_service.service123: Destruction complete after 27s

Destroy complete! Resources: 1 destroyed.

And it should be gone from the Cloud Console.

More details about the Cloud API can be found here - https://clickhouse.com/docs/cloud/manage/api/api-overview

From Google Chrome​

1. Open Developer Tools by pressing F12 or Ctrl + Shift + I (Windows/Linux) / Cmd + Option + I (Mac).
2. Click the "Network" tab.
3. Reload the page and reproduce the issue.
4. From Developer Tools, click the download button.

From Mozilla Firefox​

1. Open Developer Tools by pressing F12 or Ctrl + Shift + E (Windows/Linux) / Cmd + Option + E (Mac).
2. Click the "Network" tab.
3. Reload the page and reproduce the issue.
4. From Developer Tools, right-click in the request list and select "Save All As HAR".

From Microsoft Edge​

1. Open Developer Tools by pressing F12 or Ctrl + Shift + I (Windows/Linux) / Cmd + Option + I (Mac).
2. Click the "Network" tab.
3. Reload the page and reproduce the issue.
4. From Developer Tools, right-click in the network list and choose "Save all as HAR with content".

From Safari​

1. Enable Developer Tools (if not already enabled):
   • Go to Safari > Settings > Advanced.
   • Check "Show Develop menu in menu bar" at the bottom.
2. Click Develop > Show Web Inspector.
3. Click the "Network" tab.
4. Reload the page and reproduce the issue.
5. From Developer Tools, click the "Export" button.

Sending the .HAR file​

1. Rename the file to something short and descriptive (e.g., login-issue.har).
2. Compress the file (optional but recommended).
3. Attach it to your support case or email it to your assigned support contact.

Memory limit exceeded for query​

As a new user, ClickHouse can often seem like magic - every query is super fast, even on the largest datasets and most ambitious queries. Invariably though, real-world usage tests even the limits of ClickHouse. Queries exceeding memory can be the result of a number of causes. Most commonly, we see large joins or aggregations on high cardinality fields. If performance is critical, and these queries are required, we often recommend users simply scale up - something ClickHouse Cloud does automatically and effortlessly to ensure your queries remain responsive. We appreciate, however, that in self-managed scenarios, this is sometimes not trivial, and maybe optimal performance is not even required. Users, in this case, have a few options.

Aggregations​

For memory-intensive aggregations or sorting scenarios, users can use the settings max_bytes_before_external_group_by and max_bytes_before_external_sort respectively. The former of which is discussed extensively here.

In summary, this ensures any aggregations can “spill” out to disk if a memory threshold is exceeded. This will invariably impact query performance but will help ensure queries do not OOM. The latter sorting setting helps address similar issues with memory-intensive sorts. This can be particularly important in distributed environments where a coordinating node receives sorted responses from child shards. In this case, the coordinating server can be asked to sort a dataset larger than its available memory. With max_bytes_before_external_sort, sorting can be allowed to spill over to disk. This setting is also helpful for cases where the user has an ORDER BY after a GROUP BY with a LIMIT, especially in cases where the query is distributed.

Joins​

For joins, users can select different JOIN algorithms, which can assist in lowering the required memory. By default, joins use the hash join, which offers the most completeness with respect to features and often the best performance. This algorithm loads the right-hand table of the JOIN into an in-memory hash table, against which the left-hand table is then evaluated. To minimize memory, users should thus place the smaller table on the right side. This approach still has limitations in memory-bound cases, however. In these cases, partial_merge join can be enabled via the join_algorithm setting. This derivative of the sort-merge algorithm, first sorts the right table into blocks and creates a min-max index for them. It then sorts parts of the left table by the join key and joins them over the right table. The min-max index is used to skip unneeded right table blocks. This is less memory-intensive at the expense of performance. Taking this concept further, the full_sorting_merge algorithm allows a JOIN to be performed when the right-hand side is very large and doesn't fit into memory and lookups are impossible, e.g. a complex subquery. In this case, both the right and left side are sorted on disk if they do not fit in memory, allowing large tables to be joined.

Since 20.3, ClickHouse has supported an auto value for the join_algorithm setting. This instructs ClickHouse to apply an adaptive join approach, where the hash-join algorithm is preferred until memory limits are violated, at which point the partial_merge algorithm is attempted. Finally, concerning joins, we encourage readers to be aware of the behavior of distributed joins and how to minimize their memory consumption. More information can be found here.

OPTIMIZE FINAL is a DDL command that physically and permanently reorganizes and optimizes data on disk. It physically merges data parts in MergeTree tables, performing data deduplication in the process by removing duplicate rows from storage.

FINAL is a query-time modifier that provides deduplicated results without changing the structure of the stored data. It works by performing merge logic at read-time. It is temporary, only affecting the current query result.

Users are often advised to avoid using OPTIMIZE FINAL, as it has a significant performance overhead, however they should not confuse the two. It is often necessary to use FINAL to get back results without duplicates, especially when using table engines like ReplacingMergeTree which may contain duplicate rows which have not been replaced during the eventual, background merge process.

The table below summarises the key differences:

When to use each​

Use OPTIMIZE FINAL when:

• You want to permanently improve query performance
• You can afford the one-time optimization cost
• You're doing periodic table maintenance
• You want to physically clean up duplicate data

Use FINAL when:

• You need deduplicated results immediately
• You can't wait for or don't want permanent optimization
• You only occasionally need deduplicated data
• You're working with frequently changing data

Both are valuable tools, but they serve different purposes in ClickHouse's deduplication strategy.

In this knowledgebase article, we will walk you through how you can set up a custom DNS alias for your ClickHouse Cloud instance through the use of a reverse proxy such as Nginx for ClickHouse native client.

Create a self-signed certificate​

Create a self-signed certificate with the domain name of your choice. In this example we will use a domain name xyz-customdomain.com and create a certificate called MyCertificate.crt. Refer to "Create SSL certificates" for further details.

Add the certificate to /etc/clickhouse-client/config.xml:

<clickhouse>
    <openSSL>
        <client>
            <loadDefaultCAFile>false</loadDefaultCAFile>
            # highlight-next-line
            <caConfig>/etc/ssl/certs/MyCertificate.crt</caConfig>
            <cacheSessions>true</cacheSessions>
            <disableProtocols>sslv2,sslv3</disableProtocols>
            <preferServerCiphers>true</preferServerCiphers>
            <invalidCertificateHandler>
                <name>RejectCertificateHandler</name>
            </invalidCertificateHandler>
        </client>
    </openSSL>
</clickhouse>

Update Nginx configuration​

Add the following in your nginx.conf file:

proxy_ssl_name xyz.us-west-2.aws.clickhouse.cloud;
proxy_ssl_server_name on;

stream {
    upstream stream_backend {
         server xyz.us-west-2.aws.clickhouse.cloud:9440;
    }

    server {
        listen                9440 ssl;
        proxy_pass            stream_backend;

        ssl_certificate       /etc/ssl/certs/MyCertificate.crt;
        ssl_certificate_key   /etc/ssl/certs/MyKey.key;
        ssl_protocols         SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers           HIGH:!aNULL:!MD5;
        ssl_session_cache     shared:SSL:20m;
        ssl_session_timeout   4h;
        ssl_handshake_timeout 30s;
	proxy_ssl on;
	proxy_ssl_trusted_certificate /etc/ssl/certs/isrgrootx1.pem;
	proxy_ssl_session_reuse on;
        proxy_ssl_verify on;
    #highlight-next-line
	proxy_ssl_name xyz.us-west-2.aws.clickhouse.cloud;
    #highlight-next-line
	proxy_ssl_server_name on;
    }
}

Where isrgrootx1.pem is the root certificate for ClickHouse Cloud which you can download here.

Update hosts file​

Add the following to your /etc/hosts file on the Nginx server:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost6 localhost6.localdomain6
10.X.Y.Z  xyz-customdomain.com

Where 10.X.Y.Z is the IP address of your specific Nginx box.

Connect to Cloud using alias​

You are now ready to connect using your custom alias:

clickhouse-client --host xyz.customdomain.com --secure --password 'xxxxxxx'
ClickHouse client version 23.12.1.428 (official build).
Connecting to xyz.customdomain.com:9440 as user default.
Connected to ClickHouse server version 23.9.2.

clickhouse-cloud :)

Overview​

This guide will get you started with setting up a MSK multi-VPC to be used with ClickPipes reverse private endpoint.

Requirements​

Your MSK cluster VPC must be located in one of our ClickPipes regions. See ClickPipes regions for the list of supported regions.

Enabling multi-VPC connectivity​

1. Navigate to the MSK cluster.
   • Choose "Clusters" from the left navigation pane in the Amazon MSK console.
   • Select the specific MSK cluster you want to configure for multi-VPC connectivity.
2. Enable MSK multi-VPC connectivity
   • In the Connectivity tab, find the Multi-VPC connectivity section.
   • Click on Edit.
   • Enable the Turn-on MSK multi-VPC connectivity option.
   • Follow the instructions
3. Add ClickPipes account principal into a cluster’s policy
   • Navigate to the Configuration tab.
   • Click on Edit in the Cluster policy section.
   • Include arn:aws:iam::072088201116:root in the IAM policy. Example:

     {
         "Version": "2012-10-17",
         "Statement": [
             {
                 "Effect": "Allow",
                 "Principal": {
                     "AWS": [
                         "arn:aws:iam::072088201116:root"
                     ]
                 },
                 "Action": [
                     "kafka-cluster:Connect",
                     "kafka-cluster:DescribeCluster",
                     "kafka-cluster:ListClusters"
                 ]
             }
         ]
     }
     

Creating reverse private endpoint​

Follow reverse private endpoint creation steps in the ClickPipes documentation.

Removing the default user​

In this guide, we're going to learn how to remove the default user from ClickHouse Server.

We can do this by creating a YAML file (let's call it remove_default_user.yaml) that has the following content

users:
  default:
    "@remove": remove

The location of this file depends on how we have ClickHouse installed.

Running the executable directly​

If we're running the ClickHouse directly (clickhouse server), we need to put the file under the config.d directory.

When we run ClickHouse Server:

clickhouse server

We'll see the following line in the logs:

{} <Debug> ConfigProcessor: Merging configuration file 'config.d/remove_default_user.yaml'.

And we'll be unable to connect using clickhouse client:

ClickHouse client version 24.11.1.2557 (official build).
Connecting to localhost:9000 as user default.
Password for user (default):
Connecting to localhost:9000 as user default.
Code: 516. DB::Exception: Received from localhost:9000. DB::Exception: default: Authentication failed: password is incorrect, or there is no user with such name.

Docker or installed​

If we're running ClickHouse via Docker or have it installed on our machine, we need to put the file under the /etc/clickhouse-server/users.d directory instead.

So if we're running with Docker, we can mount the config.d directory that we created earlier to /etc/clickhouse-server/users.d:

docker run \
  -v ./config.d:/etc/clickhouse-server/users.d \
  -p 8123:8123 -p9000:9000 \
  clickhouse/clickhouse-server:24.12

Merging configuration file '/etc/clickhouse-server/config.d/docker_related_config.xml'.
Logging trace to /var/log/clickhouse-server/clickhouse-server.log
Logging errors to /var/log/clickhouse-server/clickhouse-server.err.log

We can then search the server logs to check that it gets picked up:

docker ps --format "table {{.ID}}\t{{.Image}}\t{{.Names}}\t{{.Command}}"

CONTAINER ID   IMAGE                                NAMES               COMMAND
383e8ed89431   clickhouse/clickhouse-server:24.12   trusting_rosalind   "/entrypoint.sh"

docker exec -it trusting_rosalind grep "users\.d" /var/log/clickhouse-server/clickhouse-server.log

We should see the following line:

{} <Debug> ConfigProcessor: Merging configuration file '/etc/clickhouse-server/users.d/remove_default_user.yaml'.

Verbose Logging​

One thing that often confuses new users is that ClickHouse generates a lot of logging output, even under light load.

This is because the default logging level, due to historical reasons, is trace (instead of warning that would be the default in other databases).

The ClickHouse developers argue that trace provides a lot of insight in case something goes wrong.

On the other hand, large volumes of logging mean that the system table system.text_log fills up quickly and needs to be merged in the background.

If the database runs stably, users may re-configure the log level, which we explain how to do below.

Change the log level​

The different log levels available are documented here

You'll need to edit the ClickHouse server configuration file (/etc/clickhouse-server/config.xml) to modify the log level.

The default value is trace but you can change it to the desired level. See the comment below:

<clickhouse>
    <logger>
        <!-- Possible levels [1]:

          - none (turns off logging)
          - fatal
          - critical
          - error
          - warning
          - notice
          - information
          - debug
          - trace
          - test (not for production usage)

            [1]: https://github.com/pocoproject/poco/blob/poco-1.9.4-release/Foundation/include/Poco/Logger.h#L105-L114
        -->
        <level>trace</level>
... Rest of the configuration file
</clickhouse>

Adding a Column to a Table​

We'll be using clickhouse-local:

clickhouse -m --output_format_pretty_row_numbers=

Let's imagine we have the following table:

CREATE TABLE events (
    date Date DEFAULT today(), 
    name String
) 
ENGINE = MergeTree
ORDER BY date;

Let's add one record:

INSERT INTO events (name) VALUES ('Alexey');

And now query the events table:

SELECT *
FROM events;

┌───────date─┬─name───┐
│ 2024-12-18 │ Alexey │
└────────────┴────────┘

Adding a new column​

Now let's say we're going to add a new column called favoriteNumber, which will be a Float64. We can do this using the ALTER TABLE...ADD COLUMN clause:

ALTER TABLE events 
ADD COLUMN favoriteNumber Float64 DEFAULT 7;

If we query the events table, we'll see the following output:

┌───────date─┬─name───┬─favoriteNumber─┐
│ 2024-12-18 │ Alexey │              7 │
└────────────┴────────┴────────────────┘

The Alexey row defaults to 7 since that column didn't exist when we added that row. Next, let's add another column:

INSERT INTO events (name) VALUES ('Tyler');

If we query the events table, we'll see the following output:

┏━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃       date ┃ name   ┃ favoriteNumber ┃
┡━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━┩
│ 2024-12-18 │ Tyler  │              7 │
├────────────┼────────┼────────────────┤
│ 2024-12-18 │ Alexey │              7 │
└────────────┴────────┴────────────────┘

Modifying a column's default value​

If we modify the favoriteNumber column to have a different type using the ALTER TABLE...MODIFY COLUMN clause, things get interesting:

ALTER TABLE events 
MODIFY COLUMN favoriteNumber Float64 DEFAULT 99;

If we query events again, we'll see this output:

┏━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃       date ┃ name   ┃ favoriteNumber ┃
┡━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━┩
│ 2024-12-18 │ Tyler  │              7 │
├────────────┼────────┼────────────────┤
│ 2024-12-18 │ Alexey │             99 │
└────────────┴────────┴────────────────┘

Tyler keeps a value of 7, which was the default when that row was created. Alexey picks up the new default of 99 because the favoriteNumber column didn't exist when that row was created.

If we want the Alexey row to use the current default right away, we need to call OPTIMIZE TABLE to force current defaults to be written to disk:

OPTIMIZE TABLE events;

Once we've done that, let's say we change the default value again:

ALTER TABLE events 
MODIFY COLUMN favoriteNumber Float64 DEFAULT 21;

And then insert another row:

INSERT INTO events (name) VALUES ('Tanya');

Finally, let's query events one more time:

┏━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃       date ┃ name   ┃ favoriteNumber ┃
┡━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━━┩
│ 2024-12-18 │ Alexey │             99 │
├────────────┼────────┼────────────────┤
│ 2024-12-18 │ Tyler  │              7 │
├────────────┼────────┼────────────────┤
│ 2024-12-18 │ Tanya  │             21 │
└────────────┴────────┴────────────────┘

Tanya picks up the new default of 21, but Alexey has the old default of 99.

Controlling column position in table​

When we add a new column, by default it will be added at the end of the table. But, we can use the FIRST and AFTER clauses to control where a column is positioned.

For example, if we wanted to add a column called favoriteColor after the name column, we could do this:

ALTER TABLE events
ADD COLUMN favoriteColor String DEFAULT 'Yellow' AFTER name;

Let's query events:

┏━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃       date ┃ name   ┃ favoriteColor ┃ favoriteNumber ┃
┡━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━┩
│ 2024-12-18 │ Alexey │ Yellow        │             99 │
├────────────┼────────┼───────────────┼────────────────┤
│ 2024-12-18 │ Tyler  │ Yellow        │              7 │
├────────────┼────────┼───────────────┼────────────────┤
│ 2024-12-18 │ Tanya  │ Yellow        │             21 │
└────────────┴────────┴───────────────┴────────────────┘

And if we wanted to add a column favoriteDatabase and have that be first in the list, we could do this:

ALTER TABLE events
ADD COLUMN favoriteDatabase String DEFAULT 'ClickHouse' FIRST;

┏━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━┳━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━┓
┃ favoriteDatabase ┃       date ┃ name   ┃ favoriteColor ┃ favoriteNumber ┃
┡━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━╇━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━┩
│ ClickHouse       │ 2024-12-18 │ Tanya  │ Yellow        │             21 │
├──────────────────┼────────────┼────────┼───────────────┼────────────────┤
│ ClickHouse       │ 2024-12-18 │ Alexey │ Yellow        │             99 │
├──────────────────┼────────────┼────────┼───────────────┼────────────────┤
│ ClickHouse       │ 2024-12-18 │ Tyler  │ Yellow        │              7 │
└──────────────────┴────────────┴────────┴───────────────┴────────────────┘

And let's have a look at the table definition:

SHOW CREATE TABLE events
FORMAT LineAsString

CREATE TABLE default.`clickhouse-local-ab404c86-56cc-495b-ad1d-fb343cac3bc0events`
(
    `favoriteDatabase` String DEFAULT 'ClickHouse',
    `date` Date DEFAULT today(),
    `name` String,
    `favoriteColor` String DEFAULT 'Yellow',
    `favoriteNumber` Float64 DEFAULT 21
)
ENGINE = MergeTree
ORDER BY date