/clickhouse-best-practices
MUST USE when reviewing ClickHouse schemas, queries, or configurations. Contains 31 rules that MUST be checked before providing recommendations. Always read relevant rule files and cite specific rules in responses.
$ npx -y skills add clickhouse/agent-skills --skill clickhouse-best-practices --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/clickhouse-best-practices
Context preview
The summary Claude sees to decide when to auto-load this skill.
MUST USE when reviewing ClickHouse schemas, queries, or configurations. Contains 31 rules that MUST be checked before providing recommendations. Always read relevant rule files and cite specific rules in responses.
SKILL.md
clickhouse-best-practices.SKILL.mdname: clickhouse-best-practices
description: MUST USE when reviewing ClickHouse schemas, queries, or configurations. Contains 31 rules that MUST be checked before providing recommendations. Always read relevant rule files and cite specific rules in responses.
license: Apache-2.0
metadata:
author: ClickHouse Inc
version: "0.4.0"
ClickHouse Best Practices
Comprehensive guidance for ClickHouse covering schema design, query optimization, data ingestion, and AI agent connectivity. Contains 31 rules across 4 main categories (schema, query, insert, agent), prioritized by impact.
> **Official docs:** [ClickHouse Best Practices](https://clickhouse.com/docs/best-practices)
IMPORTANT: How to Apply This Skill
**Before answering ClickHouse questions, follow this priority order:**
1. **Check for applicable rules** in the `rules/` directory 2. **If rules exist:** Apply them and cite them in your response using "Per `rule-name`..." 3. **If no rule exists:** Use the LLM's ClickHouse knowledge or search documentation 4. **If uncertain:** Use web search for current best practices 5. **Always cite your source:** rule name, "general ClickHouse guidance", or URL
**Why rules take priority:** ClickHouse has specific behaviors (columnar storage, sparse indexes, merge tree mechanics) where general database intuition can be misleading. The rules encode validated, ClickHouse-specific guidance.
---
Agent Connectivity & Query Workflow
Before querying ClickHouse, agents must establish a connection and follow the discovery workflow:
1. `rules/agent-connect-mcp.md` - Connection setup (MCP + CLI), credential discovery, output format selection 2. `rules/agent-discovery-schema.md` - **CRITICAL**: 7-step schema discovery workflow 3. `rules/agent-query-safety.md` - **CRITICAL**: LIMIT, timeouts, progressive exploration
**Every agent session should follow this sequence:**
1. **Connect** — establish connection via MCP or CLI (see `agent-connect-mcp`) 2. **Discover** — databases → tables → columns + comments → sort keys → skip indexes → sample → EXPLAIN 3. **Plan** — use sort key and skip index knowledge to write efficient WHERE clauses 4. **Execute** — run queries with LIMIT and timeouts 5. **Recover** — on timeout/memory errors, narrow filters and retry (see `agent-query-safety`)
Subagent architecture notes
If your system dispatches ClickHouse tasks to specialized subagents:
- **Schema discovery + query execution**: any model — the steps are procedural
- **EXPLAIN analysis + query optimization**: benefits from mid-tier reasoning
- **Schema design review against all 28 rules**: benefits from mid-tier reasoning
---
Review Procedures
For Schema Reviews (CREATE TABLE, ALTER TABLE)
**Read these rule files in order:**
1. `rules/schema-pk-plan-before-creation.md` - ORDER BY is immutable 2. `rules/schema-pk-cardinality-order.md` - Column ordering in keys 3. `rules/schema-pk-prioritize-filters.md` - Filter column inclusion 4. `rules/schema-types-native-types.md` - Proper type selection 5. `rules/schema-types-minimize-bitwidth.md` - Numeric type sizing 6. `rules/schema-types-lowcardinality.md` - LowCardinality usage 7. `rules/schema-types-avoid-nullable.md` - Nullable vs DEFAULT 8. `rules/schema-partition-low-cardinality.md` - Partition count limits 9. `rules/schema-partition-lifecycle.md` - Partitioning purpose
**Check for:**
- [ ] PRIMARY KEY / ORDER BY column order (low-to-high cardinality)
- [ ] Data types match actual data ranges
- [ ] LowCardinality applied to appropriate string columns
- [ ] Partition key cardinality bounded (100-1,000 values)
- [ ] ReplacingMergeTree has version column if used
For Query Reviews (SELECT, JOIN, aggregations)
**Read these rule files:**
1. `rules/query-join-choose-algorithm.md` - Algorithm selection 2. `rules/query-join-filter-before.md` - Pre-join filtering 3. `rules/query-join-use-any.md` - ANY vs regular JOIN 4. `rules/query-index-skipping-indices.md` - Secondary index usage 5. `rules/schema-pk-filter-on-orderby.md` - Filter alignment with ORDER BY
**Check for:**
- [ ] Filters use ORDER BY prefix columns
- [ ] JOINs filter tables before joining (not after)
- [ ] Correct JOIN algorithm for table sizes
- [ ] Skipping indices for non-ORDER BY filter columns
For Insert Strategy Reviews (data ingestion, updates, deletes)
**Read these rule files:**
1. `rules/insert-batch-size.md` - Batch sizing requirements 2. `rules/insert-mutation-avoid-update.md` - UPDATE alternatives 3. `rules/insert-mutation-avoid-delete.md` - DELETE alternatives 4. `rules/insert-async-small-batches.md` - Async insert usage 5. `rules/insert-optimize-avoid-final.md` - OPTIMIZE TABLE risks
**Check for:**
- [ ] Batch size 10K-100K rows per INSERT
- [ ] No ALTER TABLE UPDATE for frequent changes
- [ ] ReplacingMergeTree or CollapsingMergeTree for update patterns
- [ ] Async inserts enabled for high-frequency small batches
---
Output Format
Structure your response as follows:
## Rules Checked
- `rule-name-1` - Compliant / Violation found
- `rule-name-2` - Compliant / Violation found
...
## Findings
### Violations
- **`rule-name`**: Description of the issue
- Current: [what the code does]
- Required: [what it should do]
- Fix: [specific correction]
### Compliant
- `rule-name`: Brief note on why it's correct
## Recommendations
[Prioritized list of changes, citing rules]
---
Rule Categories by Priority
| Priority | Category | Impact | Prefix | Rule Count | |----------|----------|--------|--------|------------| | 1 | Primary Key Selection | CRITICAL | `schema-pk-` | 4 | | 2 | Data Type Selection | CRITICAL | `schema-types-` | 5 | | 3 | JOIN Optimization | CRITICAL | `query-join-` | 5 | | 4 | Insert Batching | CRITICAL | `insert-batch-` | 1 | | 5 | Mutation Avoidance | CRITICAL | `insert-mutation-` | 2 | | 6 | Partitioning Strategy | HIGH | `schema-partition-` | 4 | | 7 | Skipping Indices | HIGH | `query-index-` | 1 | | 8 | Materialized Views
Read more
name: clickhouse-best-practices description: MUST USE when reviewing ClickHouse schemas, queries, or configurations. Contains 31 rules that MUST be checked before providing recommendations. Always read relevant rule files and cite specific rules in responses. license: Apache-2.0 metadata: author: ClickHouse Inc version: "0.4.0"
ClickHouse Best Practices
Comprehensive guidance for ClickHouse covering schema design, query optimization, data ingestion, and AI agent connectivity. Contains 31 rules across 4 main categories (schema, query, insert, agent), prioritized by impact.
> **Official docs:** [ClickHouse Best Practices](https://clickhouse.com/docs/best-practices)
IMPORTANT: How to Apply This Skill
**Before answering ClickHouse questions, follow this priority order:**
1. **Check for applicable rules** in the `rules/` directory 2. **If rules exist:** Apply them and cite them in your response using "Per `rule-name`..." 3. **If no rule exists:** Use the LLM's ClickHouse knowledge or search documentation 4. **If uncertain:** Use web search for current best practices 5. **Always cite your source:** rule name, "general ClickHouse guidance", or URL
**Why rules take priority:** ClickHouse has specific behaviors (columnar storage, sparse indexes, merge tree mechanics) where general database intuition can be misleading. The rules encode validated, ClickHouse-specific guidance.
---
Agent Connectivity & Query Workflow
Before querying ClickHouse, agents must establish a connection and follow the discovery workflow:
1. `rules/agent-connect-mcp.md` - Connection setup (MCP + CLI), credential discovery, output format selection 2. `rules/agent-discovery-schema.md` - **CRITICAL**: 7-step schema discovery workflow 3. `rules/agent-query-safety.md` - **CRITICAL**: LIMIT, timeouts, progressive exploration
**Every agent session should follow this sequence:**
1. **Connect** — establish connection via MCP or CLI (see `agent-connect-mcp`) 2. **Discover** — databases → tables → columns + comments → sort keys → skip indexes → sample → EXPLAIN 3. **Plan** — use sort key and skip index knowledge to write efficient WHERE clauses 4. **Execute** — run queries with LIMIT and timeouts 5. **Recover** — on timeout/memory errors, narrow filters and retry (see `agent-query-safety`)
Subagent architecture notes
If your system dispatches ClickHouse tasks to specialized subagents:
- **Schema discovery + query execution**: any model — the steps are procedural
- **EXPLAIN analysis + query optimization**: benefits from mid-tier reasoning
- **Schema design review against all 28 rules**: benefits from mid-tier reasoning
---
Review Procedures
For Schema Reviews (CREATE TABLE, ALTER TABLE)
**Read these rule files in order:**
1. `rules/schema-pk-plan-before-creation.md` - ORDER BY is immutable 2. `rules/schema-pk-cardinality-order.md` - Column ordering in keys 3. `rules/schema-pk-prioritize-filters.md` - Filter column inclusion 4. `rules/schema-types-native-types.md` - Proper type selection 5. `rules/schema-types-minimize-bitwidth.md` - Numeric type sizing 6. `rules/schema-types-lowcardinality.md` - LowCardinality usage 7. `rules/schema-types-avoid-nullable.md` - Nullable vs DEFAULT 8. `rules/schema-partition-low-cardinality.md` - Partition count limits 9. `rules/schema-partition-lifecycle.md` - Partitioning purpose
**Check for:**
- [ ] PRIMARY KEY / ORDER BY column order (low-to-high cardinality)
- [ ] Data types match actual data ranges
- [ ] LowCardinality applied to appropriate string columns
- [ ] Partition key cardinality bounded (100-1,000 values)
- [ ] ReplacingMergeTree has version column if used
For Query Reviews (SELECT, JOIN, aggregations)
**Read these rule files:**
1. `rules/query-join-choose-algorithm.md` - Algorithm selection 2. `rules/query-join-filter-before.md` - Pre-join filtering 3. `rules/query-join-use-any.md` - ANY vs regular JOIN 4. `rules/query-index-skipping-indices.md` - Secondary index usage 5. `rules/schema-pk-filter-on-orderby.md` - Filter alignment with ORDER BY
**Check for:**
- [ ] Filters use ORDER BY prefix columns
- [ ] JOINs filter tables before joining (not after)
- [ ] Correct JOIN algorithm for table sizes
- [ ] Skipping indices for non-ORDER BY filter columns
For Insert Strategy Reviews (data ingestion, updates, deletes)
**Read these rule files:**
1. `rules/insert-batch-size.md` - Batch sizing requirements 2. `rules/insert-mutation-avoid-update.md` - UPDATE alternatives 3. `rules/insert-mutation-avoid-delete.md` - DELETE alternatives 4. `rules/insert-async-small-batches.md` - Async insert usage 5. `rules/insert-optimize-avoid-final.md` - OPTIMIZE TABLE risks
**Check for:**
- [ ] Batch size 10K-100K rows per INSERT
- [ ] No ALTER TABLE UPDATE for frequent changes
- [ ] ReplacingMergeTree or CollapsingMergeTree for update patterns
- [ ] Async inserts enabled for high-frequency small batches
---
Output Format
Structure your response as follows:
## Rules Checked - `rule-name-1` - Compliant / Violation found - `rule-name-2` - Compliant / Violation found ... ## Findings ### Violations - **`rule-name`**: Description of the issue - Current: [what the code does] - Required: [what it should do] - Fix: [specific correction] ### Compliant - `rule-name`: Brief note on why it's correct ## Recommendations [Prioritized list of changes, citing rules]
---
Rule Categories by Priority
| Priority | Category | Impact | Prefix | Rule Count | |----------|----------|--------|--------|------------| | 1 | Primary Key Selection | CRITICAL | `schema-pk-` | 4 | | 2 | Data Type Selection | CRITICAL | `schema-types-` | 5 | | 3 | JOIN Optimization | CRITICAL | `query-join-` | 5 | | 4 | Insert Batching | CRITICAL | `insert-batch-` | 1 | | 5 | Mutation Avoidance | CRITICAL | `insert-mutation-` | 2 | | 6 | Partitioning Strategy | HIGH | `schema-partition-` | 4 | | 7 | Skipping Indices | HIGH | `query-index-` | 1 | | 8 | Materialized Views
The official Agent Skills for ClickHouse. These skills help LLMs and agents to adopt best practices when working with ClickHouse and chdb (in-process ClickHouse for Python). You can use these skills with open-source ClickHouse and managed ClickHouse Cloud.
Repo: clickhouse/agent-skills
Other skills on clickhouse-best-practices.
- /chdb-datastore
Use when the user has tabular data (pandas DataFrame, parquet, csv, Arrow, json) and wants to filter, group, aggregate, join, or speed up slow pandas. Provides chDB DataStore — same pandas API, ClickHouse engine underneath. Also handles reading from S3, MySQL, PostgreSQL,
Open skill - /chdb-sql
Use when the user wants to run SQL — especially analytical SQL — on local files (parquet/csv/json), URLs, S3 paths, or remote databases (Postgres, MySQL, MongoDB, ClickHouse Cloud, Iceberg, Delta Lake) without setting up a server. Provides chDB — embedded ClickHouse SQL in
Open skill - /clickhouse-architecture-advisor
MUST USE when designing ClickHouse architectures, selecting between ingestion or modeling patterns, or translating best practices into workload-specific system designs. Complements clickhouse-best-practices with decision frameworks and explicit provenance labels.
Open skill - /clickhouse-js-node-coding
Write idiomatic application code with the ClickHouse Node.js client (`@clickhouse/client`). Use this skill whenever a user is *building* against the Node.js client — configuring the client, pinging, inserting rows in JSON or raw formats, selecting and parsing results, binding
Open skill - /clickhouse-js-node-rowbinary
Generate TypeScript/JavaScript code that reads/decodes AND writes/encodes ClickHouse RowBinary streams for the ClickHouse HTTP server. Use this skill whenever a user wants to parse or produce `RowBinary`, `RowBinaryWithNames`, or `RowBinaryWithNamesAndTypes`. Node.js only,
Open skill - /clickhouse-js-node-troubleshooting
Troubleshoot and resolve common issues with the ClickHouse Node.js client (@clickhouse/client). Use this skill whenever a user reports errors, unexpected behavior, or configuration questions involving the Node.js client specifically — including socket hang-up errors, Keep-Alive
Open skill

