ClickHouse localは何行から報われるか：581件の手元データでsqlite3と実測比較した

「AI時代のデータベース、何が変わる？」というお題で、まず手元の実データを使って一番地味な検証から始めた。ClickHouseは数百万〜数億行のスキャン・集計で真価を発揮する列指向DBと言われるが、では何行からその差が出るのか。

手元にあったQiita記事のフロントマター581件というごく普通の規模のデータで、clickhouse localとPythonのsqlite3（標準ライブラリ）を同一クエリ・同一マシンで実測した。結論から言うと、この規模ではsqlite3の方が明確に速かった。

環境構築でいきなりつまずいた話

まずbrew install clickhouseを試したところ、インストール自体は成功したが、実行するとexit 137（SIGKILL）で即座に落ちた。

原因はmacOSのGatekeeperで、Homebrewのcask経由で配布されているClickHouseバイナリにquarantine属性が付いており、署名検証を通過できていない。Homebrew自身も次のように警告している。

原文: Warning: clickhouse has been deprecated because it does not pass the macOS Gatekeeper check! It will be disabled on 2026-09-01.
日本語訳: 警告：clickhouseはmacOSのGatekeeperチェックを通過しないため非推奨になりました。2026年9月1日に無効化されます。

xattr -d com.apple.quarantineでquarantine属性を外せば動くが、これはセキュリティ設定を緩める操作なので今回は見送り、代わりに署名済みのDocker公式イメージ（clickhouse/clickhouse-server:latest）上でclickhouse localを動かした。「AI時代でもDB選定の前に配布形態の壁がある」というのは、地味だが実務では効いてくる事実だと思う。

検証方法

• データ: ~/qiita-backup/public/*.md（このリポジトリ自身のQiita記事）581件のYAMLフロントマターを抽出し、id / title / updated_at / private / tags_count / tags / organization_url_name / char_countの列を持つTSV（582行、約142KB）に整形
• クエリ3種（ClickHouseとsqlite3で同一ロジックを実装、結果が完全一致することを確認済み）
  1. タグ別記事数トップ10（GROUP BY + COUNT + ORDER BY + LIMIT）
  2. updated_atの年月別投稿数トレンド（GROUP BY + COUNT）
  3. private別の件数・平均文字数（GROUP BY + COUNT + AVG）
• 計測方法: sqlite3はPythonプロセス内で5回実行しbest/avgを記録。ClickHouseはコンテナ常駐＋docker exec経由で5回実行し、さらに--timeオプションでプロセス起動を除いたクエリ内部実行時間も別途計測

結果（すべて実測値）

クエリ	sqlite3 (best, ms)	ClickHouse内部実行 (--time, ms)	ClickHouse プロセス起動込み (docker exec, ms)
タグ別トップ10	0.478	約2〜3	約90〜120
月別トレンド	0.063	約2	約90〜100
private別集計	0.044	約2	約90〜110

この規模（581行）では、sqlite3の方がClickHouse localより速い。 クエリの内部実行時間だけで比べてもsqlite3（0.04〜0.5ms）がClickHouse（2〜3ms）を上回り、プロセス起動コストまで含めるとClickHouseは1桁〜2桁遅い。

原因は明確で、clickhouse localはCLI呼び出しのたびにプロセスを起動しており、そのオーバーヘッドが90ms前後かかる。
これはClickHouseエンジン自体の遅さではなく、「毎回プロセスを立ち上げて1クエリ投げて終わる」という使い方そのものがClickHouseの得意な使われ方（サーバーとして常駐し、大量データへの継続的なクエリを捌く）と噛み合っていないだけだ。
sqlite3はすでに起動済みのPythonインタプリタの中で完結するため、この種の「軽い・単発の」ワークロードでは有利になる。

なお今回の計測はHomebrewのネイティブ実行ではなくDocker経由（Gatekeeperのquarantineブロックのため）なので、Dockerのレイヤーが多少オーバーヘッドを上乗せしている可能性はある。
ただしネイティブで測ってもプロセス起動コストがゼロになるわけではなく、「数百行規模でsqlite3に負ける」という構図自体は変わらないと考えている。

使い分けの結論

特性	向いている道具
数百〜数千行、CLIで単発集計、Pythonスクリプトの一部として使う	sqlite3
数百万〜数億行、サーバーとして常駐させ継続的にクエリを捌く	ClickHouse（server起動、CLI呼び出しではない）
ベクトル検索と構造化データの集計を同一エンジンで両方やりたい	ClickHouse（後述）

「ClickHouseは速い」という言説はデータ規模と使い方（常駐サーバー vs 単発CLI）を伴わないと成立しない、というのが今回の実測から得た結論だ。

AI時代のDBに求められるもの：単一エンジンへの統合

今回のベンチマークとは別に、ClickHouse公式が公開しているHackerNews検索デモ（HackBot）の構成が興味深かったので触れておく。
Hacker Newsのコメント2,800万件をベクトルストア化して意味検索する一方、Stack Overflowの構造化データへの集計クエリやメタデータでのフィルタリングも同じClickHouseエンジンで処理している。
つまり「ベクトル検索専用DB」と「分析用DB」を分けず、1つの列指向エンジンに統合している。

LLM/RAGが日常的なワークロードになるほど、埋め込み・ログ・イベントデータの「量」は増え続ける。
今回のベンチマークで見た「ClickHouseはプロセス起動コストが支配的な小規模データでは分が悪い」という結果は、裏を返せば「データが本当に大きくなったとき、専用ベクトルDBと分析DBを分けずに済ませられるか」という問いにつながる。
AI時代のデータベース選定は、単発クエリの速さよりも、増え続けるデータ種別をいくつのエンジンで支えるか、という設計の問題に近づいている。

再現手順

# 1. フロントマターの抽出（PyYAML使用）
python3 scripts/extract_frontmatter.py

# 2. sqlite3ベンチマーク
python3 scripts/bench_sqlite.py

# 3. ClickHouse local（Docker経由、Gatekeeperのquarantineブロック回避）
docker pull clickhouse/clickhouse-server:latest
docker run -d --name ch-bench -v "$(pwd)/data:/data" -v "$(pwd)/queries:/queries" \
  clickhouse/clickhouse-server:latest tail -f /dev/null
docker exec ch-bench clickhouse local --queries-file /queries/q1_tag_top10.sql --time
docker stop ch-bench && docker rm ch-bench

参考リンク

• Homebrew clickhouse caskの非推奨警告（brew install clickhouse実行時にターミナルへ表示される文言。2026-07-05実行時に確認、固定URLの一次情報は未特定）
• ClickHouse公式 Docker Hub
• ClickHouse公式ブログ「HackBot」構築記事（Hacker News + Stack Overflowの検索デモ）

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。