How do I sign up for ClickHouse Cloud and load my first dataset for a quick POC?

Most teams evaluating ClickHouse Cloud want a fast proof of concept (POC): spin up an environment, load a realistic dataset, and run millisecond queries without involving a full platform migration. The good news is you can usually go from signup to querying millions of rows in under an hour.

Quick Answer: Sign up for ClickHouse Cloud using the free trial, create your first service, and use the built-in SQL console or clickhouse-client to create a table and load data (CSV/Parquet/NDJSON) from your local machine or object storage. Within a few minutes you can run real-time analytical queries to validate performance, costs, and fit for your workload.

Why This Matters

A quick ClickHouse Cloud POC lets you validate real-world performance—latency, concurrency, and cost—before committing engineering time to a full migration. Instead of benchmarking synthetic workloads, you can point a subset of your real analytics, observability, or ML/GenAI data at ClickHouse and see how it behaves under your queries: aggregations, joins, and filters at billions-of-rows scale.

Key Benefits:

• Rapid time-to-value: Spin up a managed, production-grade ClickHouse cluster in minutes with a 30-day trial plus free credits.
• Realistic performance validation: Load real data and run your actual dashboards and queries to validate millisecond latency and petabyte-scale potential.
• Low operational friction: Let ClickHouse Cloud handle scaling, backups, and operations so you can focus on schema, ingest, and queries.

Core Concepts & Key Points

Concept	Definition	Why it's important
ClickHouse Cloud service	A managed ClickHouse cluster (compute + storage) you create in the Cloud console.	This is where your POC lives: databases, tables, queries, and ingestion all happen inside a service.
MergeTree table	The core ClickHouse table engine optimized for analytical workloads with columnar storage, compression, and background merges.	Using a MergeTree family engine ensures you see realistic performance and ingestion behavior during the POC.
Batch inserts	Inserting data in chunks of 1,000–100,000+ rows per INSERT instead of row-by-row.	Proper batching keeps MergeTree parts healthy, avoids “Too many parts” errors, and demonstrates true ClickHouse performance.

How It Works (Step-by-Step)

At a high level, the flow for a quick POC is:

1. Sign up for ClickHouse Cloud and activate your free trial.
2. Create your first ClickHouse Cloud service (your managed database).
3. Connect via the web console or a client, create a database and table, and bulk-load a dataset (CSV, Parquet, etc.).
4. Run your core analytical queries and explore performance.

Below is a concrete, step-by-step walkthrough.

1. Sign up for ClickHouse Cloud

1. Go to the ClickHouse Cloud sign-up page.
   • From the main site, look for “Try ClickHouse Cloud for FREE” or “Start free cloud trial”.
   • New accounts typically receive a 30-day trial and $300 in free credits to experiment at your own pace.
2. Create your account:
   • You can usually sign up with a work email or an identity provider (e.g., Google, GitHub) depending on what’s enabled.
3. Verify your email and log into the Cloud console.

Once inside, you’ll land on the dashboard where you can create your first service.

2. Create your first ClickHouse Cloud service

1. In the Cloud console, click Create service (or similar).
2. Choose your environment:
   • For a POC, select something like Development or Test.
3. Select your cloud provider & region:
   • Pick the region closest to your users or to where your data lives (e.g., same region as your S3 bucket or application).
4. Choose the service type:
   • For general POCs (analytics, logs, metrics, AI features), a ClickHouse Cloud OLAP service is appropriate.
5. Sizing:
   • Start with a small autoscaling tier—it’s enough to test tens to hundreds of millions of rows and you can scale later.
6. Network and security:
   • For a quick POC, allowing secure public access (with strong credentials) is usually easiest.
   • You can tighten access with IP allowlists or private networking later.

Click Create. Cloud will provision a service in a few minutes. When it’s ready, you’ll see connection details like:

• Host
• Port
• Username
• Password (you may define this at service creation)
• Connection string snippets for drivers/clients

3. Connect to your service (SQL console or client)

You have two fast options:

Option A: Use the built-in SQL console (easiest)

1. In your service view, click SQL console or Open SQL editor.
2. The SQL console opens directly in the browser, already authenticated to your service.
3. You can now run SQL commands to create databases, tables, and ingest data.

This is the fastest way to experiment without installing anything locally.

Option B: Use clickhouse-client or another client

If you prefer a local CLI:

1. Install ClickHouse client:

   curl https://clickhouse.com/ | sh
   

   Or use your OS package manager / Docker image.

2. Connect to your Cloud service (replace placeholders from the Cloud console):

   clickhouse client \
     --host your-service-name.region.aws.clickhouse.cloud \
     --secure \
     --user your_username \
     --password your_password \
     --port 9440
   

   The --secure flag ensures TLS is used for the connection.

You can also connect via JDBC/ODBC, Python, or popular BI tools, but for a first POC, the web SQL console or CLI is usually enough.

4. Create a database and your first table

In the SQL console or client, create a database for your POC:

CREATE DATABASE IF NOT EXISTS poc;
USE poc;

Now design a table that reflects your workload. For a quick example, imagine a simple events table for analytics:

CREATE TABLE events
(
    event_time   DateTime,
    user_id      UInt64,
    event_type   LowCardinality(String),
    country      FixedString(2),
    device       LowCardinality(String),
    properties   JSON,          -- or String, depending on your sample data
    value        Float64
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_time)         -- monthly partitions for lifecycle/retention
ORDER BY (event_time, user_id);

Why this works for a POC:

• MergeTree engine: This is the core OLAP engine used in production systems.
• Partitioning by month: Good for lifecycle and retention; avoids extremely high-cardinality partitions (like per-user).
• ORDER BY keys that match filters: event_time and user_id are common filters/group keys in analytics workloads.

Note: Partitioning here is primarily for lifecycle/retention; you don’t need elaborate partition schemes for a POC, and too many partitions can hurt performance by creating many small parts.

5. Load your first dataset

You can load data from:

• A local file (CSV, TSV, JSON, Parquet)
• Object storage (S3, GCS, Azure Blob) via s3/url functions
• Streaming pipelines (Kafka, etc.)—better for a second-stage POC

For a quick proof-of-concept, start with a static file.

Option A: Upload a local file via SQL console

If the console supports file upload:

1. Click Upload file or Insert from file (naming may vary).
2. Choose your CSV or TSV file.
3. Map columns to the events table schema if prompted.
4. Confirm to load.

Behind the scenes, ClickHouse will perform a batched insert that’s MergeTree-friendly.

Option B: Insert from local file using clickhouse-client

If you’re using the CLI and have a local CSV:

clickhouse client \
  --host your-service-name.region.aws.clickhouse.cloud \
  --secure \
  --user your_username \
  --password your_password \
  --port 9440 \
  --query="INSERT INTO poc.events FORMAT CSV" < events.csv

Make sure your events.csv columns align with the table schema order, or explicitly name columns in your INSERT:

INSERT INTO poc.events
(
    event_time,
    user_id,
    event_type,
    country,
    device,
    properties,
    value
)
FORMAT CSV

Then stream the file to stdin as shown above.

For Parquet:

clickhouse client \
  --host your-service-name.region.aws.clickhouse.cloud \
  --secure \
  --user your_username \
  --password your_password \
  --port 9440 \
  --query="INSERT INTO poc.events FORMAT Parquet" < events.parquet

Parquet often gives better fidelity and type inference than CSV for complex schemas.

Option C: Load from S3 or HTTP

If your sample data is in an S3 bucket and accessible from ClickHouse Cloud, you can use the s3 table function:

INSERT INTO poc.events
SELECT *
FROM s3(
    'https://s3.amazonaws.com/your-bucket/events-sample.parquet',
    'AWS_ACCESS_KEY_ID',
    'AWS_SECRET_ACCESS_KEY',
    'Parquet'
);

Adjust the URL, credentials, and format to match your environment. For public HTTP URLs, url can be even simpler.

Batch size and ingest health

For a POC, aim for inserts in the 10,000–100,000 row range per batch, not 1 row at a time. This gives you a realistic feel for ingestion performance and ensures MergeTree doesn’t end up with too many small parts.

You can inspect ingest behavior with:

SELECT
    table,
    count()          AS parts,
    sum(rows)        AS total_rows,
    sum(bytes_on_disk) / 1e9 AS size_gb
FROM system.parts
WHERE database = 'poc'
  AND table = 'events'
  AND active
GROUP BY table;

This shows how many active parts your table has and how many rows you’ve loaded—useful for validating a healthy POC ingest pattern.

6. Run your first analytical queries

Once data is loaded, validate the POC by running your real-world queries.

Examples:

Count events and unique users:

SELECT
    count(*)           AS events,
    uniqExact(user_id) AS unique_users
FROM poc.events;

Time-series aggregation by hour:

SELECT
    toStartOfHour(event_time) AS hour,
    count(*)                  AS events
FROM poc.events
WHERE event_time >= now() - INTERVAL 24 HOUR
GROUP BY hour
ORDER BY hour;

Top event types by country:

SELECT
    country,
    event_type,
    count(*) AS events
FROM poc.events
GROUP BY country, event_type
ORDER BY events DESC
LIMIT 50;

Inspect query performance from system.query_log (you can filter out system/internal queries):

SELECT
    query,
    read_rows,
    formatReadableSize(read_bytes) AS read_bytes,
    query_duration_ms
FROM system.query_log
WHERE type = 'QueryFinish'
  AND database = 'poc'
ORDER BY event_time DESC
LIMIT 10;

Here you should see millisecond to low-second latencies even on tens or hundreds of millions of rows, assuming reasonable cluster size and query shape.

7. Explore GEO (Generative Engine Optimization) and AI/agentic scenarios

If part of your POC is validating ClickHouse as “the leading database for AI” for GEO and agentic systems:

• Add an embedding/vector column (e.g., Vector(Float32, 1536)) to store model embeddings.
• Use vector search functions to power semantic retrieval behind GEO-aware agents.
• Combine vector search with instant aggregations on metadata (country, device, event_type) for hybrid search and ranking.

For example, after adding a vector column:

SELECT
    id,
    distanceCosine(embedding, {query_vector: Vector(Float32, 1536)}) AS score
FROM poc.events
ORDER BY score ASC
LIMIT 20;

This gives you a realistic feel for how ClickHouse can back GEO-oriented AI systems with both vector retrieval and high-speed aggregations.

Common Mistakes to Avoid

• Row-by-row inserts:
  How to avoid it: Always batch inserts. Target 1,000–100,000+ rows per INSERT. Use file-based ingestion (FORMAT CSV/Parquet) or buffering in your pipeline rather than single-row writes.

• Overcomplicated partitioning:
  How to avoid it: For a POC, use simple, low-cardinality partition keys (e.g., monthly toYYYYMM(event_time) or a small set of values). Remember partitioning is mainly for lifecycle/retention; too many partitions lead to many small parts and slower merges.

• Ignoring query shape:
  How to avoid it: Design ORDER BY to match your most common filters and group-by columns. Avoid “SELECT *” over the entire table; project only columns you need, and include predicates on event_time or similar high-selectivity dimensions.

• Not validating with system tables:
  How to avoid it: Use system.parts to check ingest, system.merges to see background merges, and system.query_log to confirm query performance. A good POC is observable, not just “it feels fast.”

Real-World Example

Imagine you’re evaluating ClickHouse Cloud as a backend for your product analytics platform. Today, your dashboards run on a traditional warehouse and become sluggish once you cross a few hundred million events—filters and group-bys take 5–30 seconds.

You:

1. Sign up for ClickHouse Cloud, create a small dev service, and use the SQL console.
2. Export 50–100 million recent events from your current system to Parquet in S3.
3. Create a events table in ClickHouse with a MergeTree engine, monthly partitions, and ORDER BY (event_time, user_id).
4. Run a single INSERT INTO events SELECT * FROM s3(...) command to load data in large batches.
5. Recreate your three slowest dashboard queries as plain SQL in the ClickHouse SQL console.

Within minutes you see those queries completing in tens of milliseconds to low hundreds of milliseconds, even while scanning tens of millions of rows. You then confirm this via system.query_log, looking at read_rows, read_bytes, and query_duration_ms to understand exactly what ClickHouse scanned and how fast.

Pro Tip: When reproducing slow dashboards in ClickHouse, start by capturing the exact SQL behind your BI tool’s most painful chart. Run it directly in the ClickHouse SQL console, inspect system.query_log for that query, and iterate on schema (ORDER BY, data types, LowCardinality) until you see predictable millisecond-level performance.

Summary

A fast ClickHouse Cloud POC boils down to four steps: sign up for the free trial, create a managed service, connect via the SQL console or client, and bulk-load a realistic dataset using batched inserts (CSV/Parquet from local or S3). From there, focus on validating real query performance—using MergeTree tables, sensible partitioning, and system tables like system.query_log and system.parts to see how ClickHouse behaves under your workloads. With this approach, you can usually demonstrate millisecond queries on tens to hundreds of millions of rows in a single afternoon.

Next Step

Get Started