ClickHouseでは1年以上にわたって本番環境でエージェント型分析を運用してきましたが、サンフランシスコで開催された [Open House 2026](https://clickhouse.com/blog/open-house-2026-day-1) において、Claudeを搭載したClickHouse Cloudのフルマネージド型エージェント分析サービスである [ClickHouse Agents](https://clickhouse.com/docs/cloud/features/ai-ml/agents) のパブリックベータを発表しました。

ClickHouse Agentsは、ClickHouse Cloudに統合されたネイティブなAI体験です。ClickHouse Agentsを使えば、コード不要で簡単にエージェントを構築でき、SQLやセットアップなしで、ライブなClickHouseデータに基づいたエージェントをユーザーが展開できます。これらのエージェントは、Cloudコンソール内のフルマネージド型チャット体験を通じて活用でき、セットアップも別のホスティング環境も不要です。

## ClickHouse Agentsとは {#what-clickhouse-agents-is}

ClickHouse Agentsは、実績のあるオープンソースAIプラットフォームである [LibreChat](https://github.com/danny-avila/LibreChat) 上に構築されており、ClickHouse Cloud内でフルマネージドとして動作します。その中核にあるのは、ノーコードのエージェントビルダーで、アナリスト、PM、データエンジニア、エグゼクティブを問わず、誰もがClickHouseデータに基づいたエージェントを定義、設定、展開できます。ClickHouse Agentsには、すぐに使えるチャットインターフェース、サンドボックス化されたコードインタープリター、共有可能なアーティファクト、スキル、メモリ、マルチエージェントワークフローも備わっています。エージェントはClickHouseおよびあらゆるMCP互換システムにネイティブに接続し、すでに存在する場所からコンテキストを取り込みます。

Ryadh Keynote Web.mp4

含まれるもの:

* **ノーコードエージェントビルダー**: カスタム指示、スキル、コンテキストファイル、MCPツールアクセスを備えたエージェントを定義可能。Cloud RBACによって管理されます。
* **チャットインターフェース**: フルマネージドのマルチテナント対応チャット体験。自然言語で質問し、SQLや可視化を生成し、アーティファクトを構築し、データに対してマルチターン会話を実行できます。
* **サンドボックス化されたコードインタープリター**: 任意の会話の中で、Bash、Python、JavaScriptを安全に[実行](https://clickhouse.com/docs/cloud/features/ai-ml/agents/builder/code-interpreter)。チャットを離れることなく、ライブのクエリ結果に対して実行されます。
* **事前設定されたClaude**: すべてのCloudユーザーに対し、Claudeモデル(SonnetおよびHaiku)がデフォルトモデルとして組み込まれています。
* **スキル、メモリ、アーティファクト**: 反復可能なワークフローやコンテキストをスキルとしてパッケージ化し、メモリでコンテキストを永続化し、チャートやダッシュボードをアーティファクトとして共有可能。
* **マルチエージェントワークフロー**: エンドツーエンドの分析タスクをまたいでサブエージェントをオーケストレーション。
* **エンタープライズセキュリティ**: SSO、暗号化されたメッセージストレージ、ガバナンスの効いたデータアクセスを、マネージドランタイムに組み込み済み。

## AI向けClickHouseプラットフォーム {#the-clickhouse-platform-for-ai}

ClickHouse Agentsは、私たちが「AI向けClickHouseプラットフォーム(ClickHouse Platform for AI)」と呼ぶものの一部です。

主要なクラウドデータプラットフォームはこぞってAIをネイティブ機能に組み込もうとしていますが、その多くは同じやり方を取っています。すなわち、データとAIをバンドルし、プロプライエタリで高価、データ構造、モデル、エージェント、ツールが単一のエコシステムにロックインされた「壁に囲まれた庭(ウォールドガーデン)」型です。この領域の進化の速さを考えると、これは間違った方向であり、オープン性と相互運用性こそが鍵だと私たちは考えています。ClickHouse Platform for AIはオープンスタックで、データ層から積み上げ、アプリ、エージェント、ユーザー、APIに提供されます:

* **データ層**: オープンソースのカラムナエンジンであるClickHouse。[Shopify](https://clickhouse.com/videos/shopify-open-source-network-monitoring)、[Uber](https://www.uber.com/us/en/blog/logging/)、[Ramp](https://clickhouse.com/videos/ramp)、[Anthropic](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era)、[Tesla](https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse)、[Deutsche Bank](https://clickhouse.com/videos/big-sensitive-data-warehouse-deutsche-bank-clickhouse)のような企業がすでに大規模なリアルタイム分析に使用しており、トランザクションデータ用のマネージドPostgresも併設します。マネージドな取り込みにより、オープンテーブルフォーマット、データレイク、その他のソースからデータを取り込み、コンテキスト管理層(スキル)がエージェントを自社の定義に基づいて接地させます。
* **接続層**: マネージドのClickHouse MCPサーバー、加えてクライアント、CLI、プラグイン。お客様は接続したい任意のMCP互換アプリやエージェントに対する柔軟性と完全な制御を維持できます。すでにお客様はClaude Code、Cursor、Amazon Bedrockエージェント、独自のカスタムエージェントを接続しています。
* **エージェント層**: SQLコンソール内で簡単な質問に答えるClickHouse Assistantと、サンドボックス化されたコードインタープリターを備えたフルエージェント型ワークフロー用のClickHouse Agents。
* **エンドツーエンドの可観測性と評価**: ClickHouseには、可観測性のためのClickStackと、LLM可観測性および評価のためのLangfuseも含まれます。これによりエージェントが何をしているかを可視化し、本番環境で信頼性高く運用できます。


![](/uploads/clickhouse_agents_jun2026_image3_8315470075.png)

目標は、ポータブルで拡張可能、ロックインのない最高のリアルタイム分析プラットフォームによってAIの力を享受していただくことです。お客様は、マネージドエージェントをそのまま利用したり、ノーコードビルダーで独自に構築したり、ご自身のフレームワークを持ち込んでClickHouseをその下のオープンデータ層として活用したりと、柔軟に選択できます。

このアプローチで何が違うかというと、ClickHouseはお客様にファーストパーティかサードパーティかの二者択一を迫らないことです。ご自身のエージェント、モデル、ツールをClickHouseに持ち込み、私たちの接続層上で実行することも、ClickHouse Agentsのようなファーストパーティ機能を利用することも可能です。どちらの道も同じオープンなデータ基盤の上に成り立っており、片方を選ばせるのではなく、お客様のいる場所に寄り添います。

![](/uploads/clickhouse_agents_jun2026_image4_33e7a643e2.png)

*ClickHouse CloudにおけるMCP採用状況(上記グラフは、リモートMCP機能を利用しているユニークなサービス数の時系列推移を示しています)*

これを示すため、私たちはAmazon Web Servicesと緊密に連携し、ClickHouse Agentsに対するAgentCore Registryとのネイティブ統合を出荷しました。これによりユーザーは、AgentCoreで管理されているエージェント、ツール、スキルをMCP経由で持ち込み、ClickHouse Agentsで利用できます。

![](/uploads/clickhouse_agents_jun2026_image5_9d4230b8e1.png)

私たちはClickHouseをAIのためのオープンなデータプラットフォームとして構築しています。ClickHouse Agents、LibreChat、MCP、そしてAWS Agent Registryのようなシステムとの取り組みはすべて、同じ信念を反映しています。すなわち、オープン性、コンポーザビリティ、相互運用性こそが、AIが求めるスピードで企業を動かす力になるという信念です。単一ベンダーが完全なAIスタックを十分に速く、十分に完全に統合することはできず、それを試みる者はユーザーをウォールドガーデンに閉じ込めることになります。ClickHouseのオープンでコミュニティ主導のDNAこそが、すべてのお客様にとってエージェント時代の基盤となる理由です。

## ここに至るまで: 自社経験のプロダクト化 {#how-we-got-here}

2025年3月、私たちは自社のデータウェアハウスをAIファーストにし、その上に社内分析エージェントを構築しました。そのすべてを[社内データウェアハウスをAIファーストにした方法](https://clickhouse.com/blog/ai-first-data-warehouse)に記録しました。要約すれば、急速に普及したということです。現在、ClickHouseの従業員の約80%が日常的にLibreChatを利用し、当社のプラットフォームだけで社内データウェアハウスクエリの約70%を処理し、1日あたり4,500万トークン以上を処理しています。圧倒的に、最も使われている社内ツールです。

チャット層の選定は、本格的な「自作 vs 購入」の判断でした。要件は妥協できないものでした。任意のLLMプロバイダーに対応すること、堅実なMCPサポート、SSOや監査ログなどのエンタープライズ機能の搭載、アーティファクトのレンダリング、そして単一ベンダーへのロックインがないこと。[LibreChat](https://github.com/danny-avila/LibreChat)はすべての項目を満たしていました。ご存じない方のために説明すると、LibreChatは主要なオープンソースAIチャットプラットフォームで、ほぼすべてのLLMプロバイダーの前段に立てるセルフホスト可能な単一UIを提供し、エンタープライズSSO、RBAC、MCPサポート、エージェント、アーティファクト、サンドボックス化されたコードインタープリターを内蔵しています。

LibreChatが正しいプラットフォームだと確信させたのは、すでに本番運用している企業のリストでもありました。Shopify CEOのTobi Lütke氏は[率直にこう述べています](https://x.com/tobi/status/1932846291794510241):

「Shopifyは社内のlibrechatフォークを運用しており、ほぼすべての変更を本家にマージし戻している。社内LLMシステムを検討している企業には、このプロジェクトを強くお勧めしたい。我々にとっては非常にうまく機能している。」

[Daimler Truck](https://www.daimlertruck.com/en/newsroom/stories/daimler-truck-makes-artificial-intelligence-accessible-to-all-employees-worldwide-with-librechat)は、何千人もの従業員と3,000を超える本番エージェントを擁する全社AIプラットフォームをLibreChat上で運用しています。ヘルスケア分野では、cBioPortalがClickHouse、MCP、LibreChatスタック上で[cBioAgent](https://chat.cbioportal.org/)を出荷し、がん研究者が自然言語でゲノミクスデータセットを照会できるようにしました。同団体でバイオインフォマティクスのソフトウェアエンジニアリングを率いるIno de Bruijn氏は、これは「がん研究者の指先に発見をもたらす」と述べています。2025年11月、[私たちはLibreChatを買収し](https://clickhouse.com/blog/clickhouse-acquires-librechat)、Danny Avila氏とそのチームをClickHouseに迎えました。ClickHouse AgentsはLibreChatの本番品質をそのまま受け継いでいます。

社内ユースケースを運用することで、エージェント分析の実ワークロードの大きなコーパスも得られました。実際のスキーマに対する実際の質問、対応するSQLおよびツール利用のトレースです。これにより、汎用ベンチマークではなく実タスクそのものに対して、利用可能な事実上すべてのモデルを評価できました。Claudeファミリーは、SQL生成、スキーマ推論、ツール利用にわたって一貫してトップでした。コードのリーディングモデルであり、SQLとスキーマの作業はその強みの自然な延長です。これがClaudeをClickHouse Agentsのデフォルトに組み込んだ理由です。

![](/uploads/clickhouse_agents_jun2026_image6_0be9866d16.png)

## エージェント向けリアルタイムOLAP {#real-time-olap-for-agents}

1年以上前、私たちは[エージェント向け分析(agent-facing analytics)](https://clickhouse.com/blog/agent-facing-analytics)について書きました。AIエージェントはリアルタイムデータベースにとって新しいユーザーペルソナである、というアイデアです。眠らず、休まず、SQLを際限なく生成するユーザーです。私たちの主張は、リアルタイム分析データベースこそがこうしたエージェントにとって自然なコンテキストプロバイダーである、というものでした。なぜなら、新鮮なデータに対して高速で並行的かつ探索的なクエリを提供できるからで、これはまさにエージェントが依存するアクセスパターンです。1年間本番運用し、アーリーアダプターと緊密に連携した結果、この仮説は裏付けられました。

![](/uploads/clickhouse_agents_jun2026_image7_e65251f928.png)

エージェントは人間のアナリストの10〜100倍のクエリ量をバースト的に発火させ、リトライやタイムアウトはトークンを消費し負荷を増やします。数十億行に対するサブ秒レイテンシ、ペタバイト規模のストレージ、数千の並行クエリ、そしてエージェントトラフィックが拡大しても手頃なコスト効率、これらはClickHouseのようなプラットフォームの重要な特性です。最近のエンジン改善によりさらに良くなっており、過去1年で[最大6倍高速になったJoin](https://clickhouse.com/blog/join-me-if-you-can-clickhouse-vs-databricks-snowflake-join-performance)、[多段階の分散クエリ実行](https://clickhouse.com/blog/multi-stage-distributed-query-execution-clickhouse-cloud)、[全文検索のGA](https://clickhouse.com/blog/full-text-search-ga-release)などが含まれます。

これによりインサイトまでの時間が短縮されます。従来のパスはハンドオフを伴います。データエンジニアがクエリを書き、アナリストがダッシュボードを作り、ビジネスユーザーが結果を解釈する、各ステップが時間や日単位で測られます。ClickHouse Agentsを使えば、PMが「先週の解約急増の要因は?」と質問すれば、答え、その背後のクエリ、チャート、そして次に探求すべき質問が数秒で得られます。

## 次にやること {#whats-next}

エキサイティングな新発表に加え、私たちは以下に向けてお客様と協力しています:

* より深いCloud統合。チャット内のより豊富な可視化と、SQLコンソールとのより緊密な結合。
* Agent API。ClickHouse Agentsで構築したエージェントへのプログラム的アクセス。
* 信頼性のフィードバックループ。[2026年1月にClickHouseに加わった](https://clickhouse.com/blog/clickhouse-acquires-langfuse-open-source-llm-observability)Langfuseとのネイティブ統合を活用し、ユーザーが評価を実行しコンテキストに影響を与えられるようにする。

## 今すぐ始める {#get-started-today}

ClickHouse Agentsは、すべてのClickHouse Cloudユーザーにパブリックベータとして提供されています。ClickHouseアカウントをお持ちであれば、SQLコンソール経由でClickHouse Agentsにアクセスするか、単に[https://ai.clickhouse.cloud/](https://ai.clickhouse.cloud/)を利用開始できます。ベータ版ですので、皆様のフィードバックだけが改善の道です。フォームや[コミュニティSlack](https://clickhouse.com/slack)からお寄せください。

ClickHouse上でエージェント分析を構築していてデザインパートナーになりたい方は、[ご連絡ください](https://clickhouse.com/company/contact)。

*AI/MLチーム、Danny Avila氏とLibreChatコミュニティ、基調講演ステージで一緒に登壇してくれたAnthropicとAWSの仲間たち、そしてエージェント分析で共に取り組んでくださっているすべてのお客様に大きな感謝を。私たちはまだ始まったばかりです。*

large_clickhouse_agents_jun2026_image7.png

medium_clickhouse_agents_jun2026_image7.png

small_clickhouse_agents_jun2026_image7.png

thumbnail_clickhouse_agents_jun2026_image7.png

clickhouse_agents_jun2026_image7.png

ClickHouseエージェント: Claudeを活用したエージェント型アナリティクスがパブリックベータで登場

After running agentic analytics in production for more than a year at ClickHouse, at [Open House 2026](https://clickhouse.com/blog/open-house-2026-day-1) in San Francisco, we announced the public beta of [ClickHouse Agents](https://clickhouse.com/docs/cloud/features/ai-ml/agents), a fully managed agentic analytics service in ClickHouse Cloud, powered by Claude.

ClickHouse Agents is a native AI experience inside ClickHouse Cloud. With ClickHouse Agents, you can build agents easily with no code required where users can ship agents grounded in their live ClickHouse data, with no SQL or setup required. You put those agents to work through a fully managed chat experience right in the Cloud console, with no setup and no separate environment to host.

## What ClickHouse Agents is {#what-clickhouse-agents-is}

ClickHouse Agents is built on [LibreChat](https://github.com/danny-avila/LibreChat), the battle-tested open-source AI platform, and runs fully managed inside ClickHouse Cloud. At its core is the no-code agent builder, which lets anyone, whether analyst, PM, data engineer, or executive, define, configure, and ship agents grounded in their ClickHouse data. ClickHouse Agents also comes with an out-of-box  chat interface, a sandboxed code interpreter, shareable artifacts, skills, memories, and multi-agent workflows. Agents connect natively to ClickHouse and to any MCP-compatible system, pulling context from wherever it already lives.

What's included:

* **No-code Agent Builder**: define agents with custom instructions, skills, context files, and MCP tool access, governed by your Cloud RBAC.  
* **Chat interface**: a fully managed, multi-tenant chat experience. Ask in natural language, generate SQL and visualizations, build artifacts, and run multi-turn conversations against your data.  
* **Sandboxed code interpreter**: secure Bash, Python and JavaScript [execution](https://clickhouse.com/docs/cloud/features/ai-ml/agents/builder/code-interpreter) inside any conversation, running against live query results without leaving the chat.  
* **Claude, pre-configured**: every Cloud customer gets Claude models (Sonnet and Haiku) wired in as the default model.  
* **Skills, memories, and artifacts**: package repeatable workflows and context as skills, persist context with memories, and share charts and dashboards as artifacts.  
* **Multi-agent workflows**: orchestrate subagents across end-to-end analytical tasks.  
* **Enterprise security**: SSO, encrypted message storage, and governed data access, built into the managed runtime.

## The ClickHouse Platform for AI {#the-clickhouse-platform-for-ai}

ClickHouse Agents is a piece of what we coined "the ClickHouse Platform for AI".

As every major cloud data platform is racing to make AI a native capability, most are doing it the same way: a walled garden where data and AI come bundled, proprietary, expensive, and locked to a single ecosystem of data constructs, models, agents, and tools. Given how fast this space is moving, we think that is the wrong direction and that openness and interoperability is key. The ClickHouse Platform for AI is an open stack, layered from the data up and served to apps, agents, users, and an API:

* **The data layer**: ClickHouse, the open-source columnar engine that companies like [Shopify](https://clickhouse.com/videos/shopify-open-source-network-monitoring), [Uber](https://www.uber.com/us/en/blog/logging/), [Ramp](https://clickhouse.com/videos/ramp), [Anthropic](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era), [Tesla](https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse), and [Deutsche Bank](https://clickhouse.com/videos/big-sensitive-data-warehouse-deutsche-bank-clickhouse) already run for real-time analytics at scale, alongside managed Postgres for transactional data. Managed ingestion brings data in from open table formats, data lakes, and other sources, and a context management layer (aka. skills) grounds agents in your own definitions.  
* **The connectivity layer**: the managed ClickHouse MCP server, plus clients, CLIs, and plugins.  Our customers keep the flexibility and full control over any MCP-compatible app or agent they want to connect. We are seeing customers already plugging in Claude Code, Cursor, Amazon Bedrock agents, and their own custom agents.  
* **The agentic layer**: the ClickHouse Assistant for quick questions in the SQL Console, and ClickHouse Agents for full agentic workflows with a sandboxed code interpreter.   
* **Observability and evals, end to end**: ClickHouse also includes ClickStack for observability and Langfuse for LLM observability and evaluations, so you can see what your agents are doing and keep them reliable in production.


![](/uploads/clickhouse_agents_jun2026_image3_8315470075.png)

The goal is to allow our customers to benefit from the power of AI with the best real-time analytics platform that is portable, extensible, and free of lock-in. Customers have the flexibility to use our managed agents out of the box, build your own with the no-code builder, or bring your own framework and let ClickHouse be the open data layer underneath. 

What's different with this approach is that ClickHouse does not force customers to choose between first-party or  third-party AI as an either-or scenario. Bring your own agents, models, and tools to ClickHouse and run them over our connectivity layer, or reach for our first-party capabilities like ClickHouse Agents. Both paths sit on the same open data foundation, and meet our customers  where you are  instead of making you pick a side.

![](/uploads/clickhouse_agents_jun2026_image4_33e7a643e2.png)

*MCP Adoption in ClickHouse Cloud (The graph above shows the number of unique services using our remote MCP feature over time)*

To illustrate this, we worked closely with Amazon Web Services to ship a native integration with the AgentCore Registry in ClickHouse Agents. This allows users to use MCP in order to bring their agents, tools and skills managed in AgentCore, and use them in ClickHouse agents.

![](/uploads/clickhouse_agents_jun2026_image5_9d4230b8e1.png)

We build ClickHouse as an open data platform for AI. ClickHouse Agents, LibreChat, MCP, and our work with systems like AWS Agent Registry all reflect the same belief: openness, composability, and interoperability are what enable enterprises move at the speed AI demands. No single vendor is going to integrate a complete AI stack fast enough and complete enough, and the ones that try will lock users into a walled garden. ClickHouse's open and community driven DNA is what makes it the substrate of the agentic era for all our customers.  

## How we got here: Productizing our own experience {#how-we-got-here}

In March 2025 we made our own data warehouse AI-first and built our internal analytics agent, on top of it. We documented the whole thing in [how we made our internal data warehouse AI-first](https://clickhouse.com/blog/ai-first-data-warehouse), and the short version is that it took off fast. Today around 80% of ClickHouse employees use LibreChat daily, and our platform alone handles roughly 70% of our internal data warehouse queries, processing more than 45 million tokens a day. By some distance, it is the most-used internal tool we run.

Picking the chat layer was a real build-versus-buy decision, and our requirements were non-negotiable: work with any LLM provider, solid MCP support, ship enterprise features like SSO and audit logging, render artifacts, and never lock us into a single vendor. [LibreChat](https://github.com/danny-avila/LibreChat) checked every box. For anyone who has not met it, LibreChat is a leading open-source AI chat platform: one self-hostable UI in front of virtually every LLM provider, with enterprise SSO, RBAC, MCP support, agents, artifacts, and a sandboxed code interpreter built in. 

What convinced us LibreChat was the right platform was also the list of companies already running it in production. Shopify CEO Tobi Lütke [put it plainly](https://x.com/tobi/status/1932846291794510241):

"Shopify runs an internal fork of librechat, and we merge most everything back. I highly recommend other companies give this project a look for their internal LLM system. It works very well for us."

[Daimler Truck](https://www.daimlertruck.com/en/newsroom/stories/daimler-truck-makes-artificial-intelligence-accessible-to-all-employees-worldwide-with-librechat) runs a company-wide AI platform on LibreChat with thousands of employees and over 3,000 agents in production. In healthcare, cBioPortal shipped [cBioAgent](https://chat.cbioportal.org/) on the ClickHouse, MCP, and LibreChat stack, letting cancer researchers query genomics datasets in plain language. As Ino de Bruijn, who manages bioinformatics software engineering there, put it, it "puts discovery at cancer researchers' fingertips." In November 2025 [we acquired LibreChat](https://clickhouse.com/blog/clickhouse-acquires-librechat) and welcomed Danny Avila and the team into ClickHouse. ClickHouse Agents inherits LibreChat's production readiness. 

Running our internal use-case also produced a large body of real agentic-analytics workloads, actual questions against actual schemas, with the SQL and tool-use traces to match. That lets us evaluate virtually every available model on the task itself rather than on generic benchmarks. The Claude family came out on top consistently, across SQL generation, schema reasoning, and tool use. It is the leading model for code, and SQL and schema work are a natural extension of that strength, which is why Claude is wired in as the default in ClickHouse Agents.

![](/uploads/clickhouse_agents_jun2026_image6_0be9866d16.png)

## Real-time OLAP for agents {#real-time-olap-for-agents}

Over a year ago, we wrote about [agent-facing analytics](https://clickhouse.com/blog/agent-facing-analytics): the idea that AI agents are a new user persona for real-time databases. The ones that never sleep, never take breaks, and generate SQL like there is no tomorrow. The argument was that a real-time analytics database is the natural context provider for these agents, because it can serve fast, concurrent, exploratory queries over fresh data, exactly the access pattern agents lean on. A year of running them in production and working closely with early adopters confirmed our hypothesis.

![](/uploads/clickhouse_agents_jun2026_image7_e65251f928.png)

Agents fire 10 to 100x the volume of queries a human analyst would, in bursts, and every retry and timeout burns tokens and adds load. Sub-second latency on billions of rows, petabyte-scale storage, thousands of concurrent queries, and the cost efficiency to keep agent traffic affordable as it grows as key characteristics of a platform like ClickHouse. Recent engine work makes this even better, including [joins up to 6x faster](https://clickhouse.com/blog/join-me-if-you-can-clickhouse-vs-databricks-snowflake-join-performance) over the past year, [multi-stage distributed query execution](https://clickhouse.com/blog/multi-stage-distributed-query-execution-clickhouse-cloud), and [full-text search GA](https://clickhouse.com/blog/full-text-search-ga-release).

It unlocks time to insight. The traditional path runs through handoffs: data engineers write queries, analysts build dashboards, business users interpret the results, each step measured in hours or days. With ClickHouse Agents, a PM can ask "what's driving the churn spike last week?" and get the answer, the query behind it, a chart, and the next questions to explore, in seconds.

## What's next {#whats-next}

Besides all the exciting new announcements, we are working with our customers for 

* Deeper Cloud integration, with richer in-chat visualizations and tighter coupling to the SQL Console.  
* An Agent API for programmatic access to the agents built in ClickHouse Agents  
* Trust feedback loop: allowing users to run evals and influence context by leveraging our native integration with Langfuse, which [joined ClickHouse in January 2026](https://clickhouse.com/blog/clickhouse-acquires-langfuse-open-source-llm-observability) 

## Get started today {#get-started-today}

ClickHouse Agents is available to all ClickHouse Cloud customers in public beta. If you have a ClickHouse account, you can now access ClickHouse Agents through the SQL console, or simply start using [https://ai.clickhouse.cloud/](https://ai.clickhouse.cloud/). As with any beta, your feedback is the only way this gets better. Find us via the form, our [community Slack](https://clickhouse.com/slack).

If you are building agentic analytics on ClickHouse and want to be a design partner, [reach out](https://clickhouse.com/company/contact). 

*Huge thanks to the AI/ML team, to Danny Avila and the LibreChat community, to our friends at Anthropic and AWS who joined us on the keynote stage, and to every customer working with us on agentic analytics. We are just getting started.*


ClickHouse Agents: Claude-powered agentic analytics, now in public beta


<blockquote>
<p style="font-style: normal;">
Today, we're launching chDB 4 together with Hex, where it is available along with the new Pandas-like DataStore API as a native integration. If you work in Hex notebooks, you can start using chDB 4 immediately — no local installation, no infrastructure to manage. Write Pandas, run ClickHouse, ship from Hex.
</p>
</blockquote>

Data practitioners have long been split into two camps: those who think in SQL and those who think in function chains. SQL has decades of compiler-level optimizations — vectorized SIMD execution, JIT compilation, logical and physical plan optimization — all battle-tested in engines like ClickHouse. Pandas, on the other hand, has become the lingua franca of data science, deeply embedded in notebook environments like Hex and Jupyter Notebook ecosystem and the muscle memory of millions of data scientists.

**What if you didn't have to choose?**

chDB is an in-process OLAP SQL engine powered by ClickHouse. With chDB, you can embed a powerful SQL engine in your app without installing a server.

**chDB 4 introduces Data Store** — a new component that lets you write familiar Pandas code while executing it on the ClickHouse engine. No new API to learn. No SQL translation by hand. Just the Pandas code you (and your LLM) already know how to write, running on one of the fastest analytical engines in the world.

## The problem with eager execution {#the-problem-with-eager-execution}

Consider a typical Pandas workflow:

<pre><code type='click-ui' language='python'>
import pandas as pd

df = pd.read_parquet("users.parquet")
df = df[df["age"] > 30]
df = df.sort_values("salary", ascending=False)
df = df.head(100)
</code></pre>

Simple enough. But here's what actually happens under the hood:

1. **The entire Parquet file is loaded into memory** — depending on data types and compression, the in-memory representation can be significantly larger than the compressed on-disk size. For highly compressed string-heavy data, this inflation can reach 4x or more; for dense numeric columns, it may be closer to 1.5–2x.
2. A full-table filter is applied, producing a second copy.
3. A full sort is performed.
4. Finally, only 100 rows are kept.

Pandas executes each step eagerly and independently, with no global view of the pipeline. While `pd.read_parquet()` does support a `filters` parameter for row-group-level predicate pushdown (via PyArrow) and a `columns` parameter for column pruning, these optimizations require the user to explicitly specify them at read time — they aren't inferred from downstream operations. A chained pipeline like the one above won't benefit from them automatically. Every intermediate step materializes a new DataFrame in memory.

![](/uploads/chdb4_mar2026_image4_8ad20b9096.png)

This is fine for small datasets on a laptop. It breaks down fast in production feature engineering pipelines, where data scientists prototype on small samples and then hand off to engineers who must rewrite everything to handle full-scale data — often introducing subtle inconsistencies between research and production.

## How Data Store works {#how-data-store-works}

Data Store is built on a four-layer architecture that transforms Pandas-style code into optimized ClickHouse execution:

![](/uploads/chdb4_mar2026_image2_c28abbd8af.png)

At the top, **Layer 1** provides the familiar Pandas API — `ds['col'] > 25`, `ds.filter(...)`, `ds.groupby('cat').sum()`. Every call returns a lazy object instead of executing immediately.

**Layer 2** records these operations as a chain of `LazyOp` objects — filter, select, assign, apply, and more — without touching any data.

**Layer 3** waits for a natural trigger like `print()`, `len()`, or `.columns`, then hands the operation chain to the `QueryPlanner`, which also determines how to split the pipeline into segments and route each to the appropriate engine.

Finally, **Layer 4** executes the plan, with each segment running on either the chDB (ClickHouse) engine or the Pandas engine, and cached DataFrames flowing between them via Python's `memoryview` to minimize data copying.

Let's see this in action.

### Lazy execution {#lazy-execution}

Instead of running each operation immediately, Data Store records your Pandas-style operations as a lazy pipeline and only executes when you actually need results:

<pre><code type='click-ui' language='python'>
from chdb import DataStore

ds = DataStore.from_file("users.parquet")
ds = ds[ds["age"] > 30]
ds = ds.sort_values("salary", ascending=False)
ds = ds.head(100)

# Nothing has executed yet.
# Execution happens here — compiled to optimized SQL, run on ClickHouse:
print(ds)
</code></pre>

At execution time, the full pipeline is compiled into ClickHouse SQL with optimizations like **filter pushdown**, **column pruning**, and **limit propagation**. The ClickHouse engine then processes the query using its vectorized, multi-threaded execution pipeline — the same engine that powers analytical workloads at massive scale.

Want to see what will happen before it runs? Use `explain()`:

<pre><code type='click-ui' language='python'>
print(ds.explain())
</code></pre>

```shell
================================================================================
Execution Plan
================================================================================

 [1] 📊 File: users.parquet

Operations:
────────────────────────────────────────
 [2] 🚀 [chDB] WHERE: age > 30
 [3] 🚀 [chDB] ORDER BY: salary DESC
 [4] 🚀 [chDB] LIMIT: 100
```

Every operation is routed to the ClickHouse engine. No data was copied into Pandas at all until the final result.

## Low-overhead DataFrame exchange {#low-overhead-dataframe-exchange}

![](/uploads/chdb4_mar2026_image5_e9306bbcbb.png)

One of the key engineering achievements in chDB 4 is **low-overhead data exchange** between ClickHouse and Pandas. chDB directly reads and writes Pandas DataFrame structures without serialization or deserialization overhead. By bypassing the traditional serialize-deserialize cycle, chDB exposes ClickHouse's internal memory buffers directly to Pandas, avoiding full data copies for numeric and fixed-width columns. For variable-length data such as strings, some conversion overhead is unavoidable due to differences in internal representation between ClickHouse and Pandas.

For the common case of numeric-heavy analytical workloads, this means the cost of crossing the boundary between ClickHouse and Pandas is effectively constant, regardless of data size. This matters not just for final results, but is critical for the segment execution model described next.

### Segment execution: seamless Pandas fallback {#segment-execution-seamless-pandas-fallback}

ClickHouse supports over 300 built-in functions, but Pandas has its own vast ecosystem of operations — custom accessors, string methods, and user-defined transformations. What happens when you use a Pandas function that has no ClickHouse equivalent?

This is where **Layer 4** from the architecture diagram comes in. The query planner analyzes your pipeline and splits it into segments at boundaries where ClickHouse can't handle an operation — automatically routing each segment to the right engine:

<pre><code type='click-ui' language='python'>
ds = DataStore.from_file("data.parquet")
ds = ds[ds["age"] > 25]                    # → chDB segment
ds["name_upper"] = ds["name"].str.title()   # → Pandas segment (str.title)
ds = ds.sort_values("age")                  # → chDB segment

print(ds.explain())
</code></pre>

```shell
Segment 1 [chDB] (from source): WHERE age > 25
Segment 2 [Pandas]: Assign name_upper = name.str.title()
Segment 3 [chDB] (via Python() table function): ORDER BY age
```

The pipeline is automatically split into three segments:

1. **chDB** reads the Parquet file and applies the filter.
2. The result is passed (via `memoryview`) to **Pandas** for the `.str.title()` operation.
3. The result is passed back to **chDB** for sorting via ClickHouse's `Python()` table function.

Each transition between engines has minimal overhead thanks to the buffer protocol. You get ClickHouse performance where possible and Pandas compatibility everywhere else — without writing a single line of glue code.

**A note on optimization boundaries:** When a Pandas segment sits in the middle of a pipeline, the ClickHouse query optimizer cannot see through it. This means that segments after a Pandas operation (like Segment 3 above) operate on an in-memory intermediate result rather than the original data source, and cannot benefit from source-level optimizations like Parquet row-group skipping. For best performance, try to keep Pandas-only operations toward the end of your pipeline where possible.

## Unified data sources {#unified-data-sources}

Because Data Store sits on top of the ClickHouse engine, it inherits ClickHouse's broad data source support. You can process data from local files, object storage, or remote databases — all through the same Pandas-style API:

<pre><code type='click-ui' language='python'>
# Local Parquet
ds = DataStore.from_file("events.parquet")

# Remote S3
ds = DataStore.uri("s3://bucket/path/to/data.parquet")

# Query a PostgreSQL table
ds = DataStore.from_sql("SELECT * FROM users", engine="postgresql://...")

# Even mix sources in SQL
ds = DataStore.from_sql("""
    SELECT u.name, e.event_type, e.timestamp
    FROM file('users.parquet') u
    JOIN postgresql('host:5432', 'db', 'events', 'user', 'pass') e
    ON u.id = e.user_id
""")
</code></pre>

This is particularly powerful for **feature engineering** in machine learning. Instead of writing ETL scripts to combine data from multiple systems into a single DataFrame, you can define the pipeline declaratively and let ClickHouse optimize the execution — much like a materialized view, but with Pandas ergonomics.

## Smart caching for interactive workflows {#smart-caching-for-interactive-workflows}

In notebook environments like Hex, data scientists often sprinkle `print()` statements throughout their code to inspect intermediate results. In a lazy execution engine, each `print()` triggers execution. Without caching, code like this would execute the upstream pipeline twice:

<pre><code type='click-ui' language='python'>
ds = DataStore.from_file("data.parquet")
ds = ds[ds["value"] > 100]

print(ds)  # Triggers execution

ds = ds.sort_values("value")
print(ds)  # Would re-execute the filter without caching
</code></pre>

Data Store includes an **automatic caching mechanism** that transparently stores intermediate results. After the first `print()`, the filtered result is cached. When you continue building on the same pipeline, the cache is reused. It is automatically invalidated when the pipeline changes or the data source is modified — no manual `cache()` calls required.

## chDB 4 on Hex {#chdb-4-on-hex}

[Hex](https://hex.tech/) is an AI analytics platform that unifies deep analysis, conversation self-serve and ad hoc exploration in a single experience – enhanced by agents. Confidently take agents into production by leveraging the [Context Studio](https://hex.tech/product/context-studio/) to observe agents and compound context to make them better over time.

Hex agents and the ClickHouse engine are already a natural pairing, and we are excited to [deepen the partnership](https://hex.tech/blog/announcing-clickhouse-partnership/) by strengthening a core workflow. Hex users already use Pandas for data exploration and transformation, with chDB 4 their existing code gets faster without changing how they write it. It comes pre-installed in Hex, with a seamless one-click option to securely connect to your ClickHouse instance.

CHDB Loop No Zoom.mp4


### What this looks like in practice {#what-this-looks-like-in-practice}

In a Hex notebook, the workflow is identical to the examples above. Create a new Python cell, and write standard Pandas code against Data Store:

![](/uploads/chdb4_mar2026_image3_38735548be.png)

The result renders in Hex's interactive table view, and from there you can pipe it into Hex's built-in charting, feed it into a Hex App for stakeholders, or continue transforming it in the next cell.

The interactive, cell-by-cell workflow in Hex maps directly to Data Store's lazy execution model: each cell builds the pipeline, and execution is deferred until you access the results. The lazy execution and smart caching mean that re-running cells or iterating on your analysis doesn't re-scan the source data unnecessarily.

### Why Hex + chDB {#why-hex-chdb}

For data teams already using Hex, chDB 4 solves a common friction point: Pandas is great for expressiveness but struggles with scale. Until now, the options were to rewrite in SQL, move to Spark, or accept slow cell execution on large datasets. chDB 4 eliminates that tradeoff. You write Pythonic function chaining logics, and the ClickHouse engine handles the heavy lifting.

For teams evaluating Hex, chDB 4 adds another reason to adopt it: a notebook environment where Pandas code runs at analytical database speed, with no ops overhead.

## Pandas compatibility: getting the details right {#pandas-compatibility-getting-the-details-right}

Making a ClickHouse-backed engine behave like Pandas is harder than it sounds. One particularly interesting challenge is **row ordering**.

ClickHouse is a massively parallel engine. When you read a file, multiple threads process different chunks simultaneously. Without an explicit `ORDER BY`, the result order is non-deterministic — whichever thread finishes first contributes its rows first. This is expected behavior for a database, but Pandas users expect `df.head(10)` to always return the *first* 10 rows from the source.

Data Store preserves source ordering by default using internal row-ID tracking, ensuring that Pandas-style operations produce identical results regardless of ClickHouse's parallel execution. For users who prioritize throughput over ordering guarantees, a **Performance mode** is available:

<pre><code type='click-ui' language='python'>
from chdb.datastore import config

config.set_execution_mode("performance")  # Skip order preservation for speed
</code></pre>

This lets you trade strict Pandas compatibility for higher parallelism — useful in production pipelines where you control the ordering explicitly.

### Behavioral compatibility and known differences {#behavioral-compatibility-and-known-differences}

Data Store aims for high behavioral compatibility with Pandas. Every Data Store operation is mirrored against an equivalent Pandas operation and the results are compared — column names, data values, data types, and row ordering. That said, some edge-case differences between ClickHouse and Pandas semantics are worth noting:

* **NaN vs NULL**: Pandas uses `NaN` for missing floating-point values, while ClickHouse distinguishes between `NaN` and `NULL`. Data Store normalizes these where possible, but subtle differences may appear in operations that distinguish between the two.
* **String sorting**: ClickHouse sorts strings in byte order (effectively UTF-8), which may differ from Pandas' default locale-sensitive sorting in certain edge cases.
* **Integer overflow**: ClickHouse silently wraps on integer overflow, while Pandas (with NumPy backend) also wraps but may behave differently with nullable integer types.

For the vast majority of data science workflows, these differences are invisible. For a complete list of known differences and workarounds, see the [Pandas Differences Guide](https://clickhouse.com/docs/chdb/guides/pandas-differences). If you encounter an unlisted edge case, please file an issue — we actively work to close any remaining gaps.

## Built for AI-assisted development {#built-for-ai-assisted-development}

An often underestimated advantage of Pandas compatibility is its seamless integration with modern LLMs. Because Pandas has been a staple of data science for over a decade, models like Claude are expert-level Pandas programmers. They can generate complex data pipelines in idiomatic Pandas with high reliability.

With Data Store, all of that generated code runs on ClickHouse automatically. Your AI coding assistant doesn't need to learn a new API — it writes the Pandas code it already knows, and chDB handles the optimization. In Hex, where AI-assisted code generation is built into the notebook experience, this creates a particularly powerful loop: ask the AI to build a pipeline, and it runs at ClickHouse speed with zero manual optimization.

## Looking ahead: Python free-threading and native UDFs {#looking-ahead-python-free-threading-and-native-udfs}

The segment execution model works well today, but crossing the engine boundary — even with minimal overhead — still means the ClickHouse query optimizer can't see through Pandas operations. We're watching the development of Python's free-threaded mode (no-GIL) with great interest. Python 3.14 officially supports the free-threaded build (via PEP 779), which removes the Global Interpreter Lock and enables true multi-threaded Python execution.

This opens up new possibilities: in the future, we could explore registering Python functions as ClickHouse UDFs that execute within the vectorized pipeline without the GIL forcing single-threaded serialization. Achieving this will require significant integration work beyond just removing the GIL — including safe FFI boundaries, memory management coordination, and thread-safe Python object access — but the no-GIL foundation is a critical prerequisite that is now in place.

The long-term vision is to keep the entire pipeline in ClickHouse's execution engine, even when using Python-defined transformations — combining the expressiveness of Python with the full power of ClickHouse's parallel execution.

## Get started {#get-started}

<pre><code type='click-ui' language='bash'>
pip install --upgrade chdb>=4.0.0
</code></pre>

<pre><code type='click-ui' language='python'>
import chdb.datastore as pd

df = pd.DataFrame({"name": ["Alice", "Bob", "Charlie"], "age": [25, 30, 35]})
result = df[df["age"] > 25].sort_values("name")

print(result)
</code></pre>

If you already have Pandas code, the migration is a single import change — swap `import pandas as pd` for `import chdb.datastore as pd`, and your existing pipeline runs on ClickHouse.

You can get started on Hex using [this tutorial](https://app.hex.tech/partnerships/app/chDB-Tutorial-032XsQ4qoKtlXxcw49joav/latest) and benefit from an extended trial using the link below: [https://app.hex.tech/signup/clickhouse-30](https://app.hex.tech/signup/clickhouse-30)

---

*chDB is an in-process SQL OLAP engine powered by ClickHouse. It runs directly in your Python process with no server, no network overhead, and no setup — just `import chdb`.*


Interested in seeing how ClickHouse works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.

Get started today

Today, we're launching chDB 4 together with HexEX, where it is available along with the new Pandas-like DataStore API as a native integration

large_chdb4_mar2026_image1.png

medium_chdb4_mar2026_image1.png

small_chdb4_mar2026_image1.png

thumbnail_chdb4_mar2026_image1.png

chdb4_mar2026_image1.png

Announcing chDB 4: write Pandas, run ClickHouse, now on Hex

We are thrilled to announce that ClickHouse has acquired <a href="https://github.com/langfuse/langfuse" target="_blank">Langfuse</a>, the leading open-source platform for LLM observability, evaluations, and prompt management. We couldn't be more excited to welcome Marc Klingen, Max Deichmann, Clemens Rawert, and the entire Langfuse team and community into the ClickHouse family.

By combining Langfuse's developer-first approach to AI quality monitoring with ClickHouse's blazing-fast core analytical capabilities, we offer a comprehensive, open-source stack for building, monitoring, and optimizing AI applications at scale.

## The rise of AI-native applications
LLMs are no longer an emerging technology and have seen widespread adoption, powering features and capabilities in almost every modern software. For instance, a majority of new SaaS applications ship with AI-powered features at the center of their workflows: conversational interfaces, agent-enhanced workflows, and automation. Developers have become both consumers of AI (through coding agents and co-pilots) and the primary builders of AI-powered experiences.

At ClickHouse, we've seen this shift firsthand through our work on the <a href="https://clickhouse.com/ai" target="_blank">Agentic Data Stack</a>. Complex AI workflows need to be grounded in real data and insights: that's where the synergy between LLMs and powerful analytical databases becomes essential.

But there's still a critical “trust” gap: how do you know if your AI application is actually working as intended?

## AI quality monitoring

LLM-powered applications are non-deterministic black boxes. The same prompt can produce different responses, making debugging and quality assurance fundamentally different from traditional software.

Operating without proper visibility is what some practitioners call "vibe-checking": essentially placing a bet on output quality without any way to measure it. For consumer applications, this might mean a bad user experience. For enterprise applications dealing with financial decisions, legal or compliance matters, or customer-facing interactions, the stakes are much higher.

The challenge compounds with complexity. Modern AI applications can involve multi-step agentic workflows, enrichment pipelines, tool calls, nested reasoning chains, and multi-agent coordination. When something goes wrong, finding the cause and a remediation becomes nearly impossible without proper tooling.

Traditional observability tools can tell you if your service is up, fast, and error-free. But it reveals nothing about whether your model's outputs are correct, helpful, safe, or aligned with user intent. An LLM can be perfectly healthy from a systems perspective while consistently producing low-quality answers.

This is why we believe "AI quality monitoring" is the right framing—it focuses directly on the outcome that matters: how well is your AI actually performing for users?

As always at ClickHouse, we evaluate the solutions on our internal systems first. We've been using Langfuse internally to monitor <a href="/blog/ai-first-data-warehouse" target="_blank">DWAINE</a>, our internal data warehouse AI agent. Having proper observability into our LLM interactions has been invaluable for understanding where our agents succeed and where they need improvement.

![langfuse-screenshot-2.png](https://cms.clickhouse-dev.com:1337/uploads/langfuse_screenshot_2_ae975a0ccc.png)

The ability to trace individual interactions, score them for quality metrics like hallucination detection, and analyze trends over time has fundamentally changed how we think about AI quality in production.

![langfuse-screenshot.png](https://cms.clickhouse-dev.com:1337/uploads/langfuse_screenshot_a76076e363.png)

## Why Langfuse?
When we evaluated the AI observability landscape, a few things became immediately clear.

**The market is fragmented, but Langfuse is pulling ahead.** While there are dozens of players in this space, ranging from pure-play startups to MLOps vendors extending into LLM monitoring to traditional observability platforms adding AI features, Langfuse has emerged as a leader in open-source, developer-first LLM observability with:
- 20k+ GitHub stars
- 23.1M+ SDK installs per month
- 6M+ Docker pulls
- Trusted by 19 of the Fortune 50 and 63 of the Fortune 500
- <a href="https://langfuse.com/enterprise" target="_blank">Enterprise</a> users like Intuit, Twilio, 7-Eleven, Merck, and numerous others

Check out the <a href="https://langfuse.com/wrapped" target="_blank">Langfuse Wrapped 2025</a> for a great retrospective of last year's growth.

**Langfuse is already built on ClickHouse.** Langfuse's architecture <a href="https://langfuse.com/blog/2024-12-langfuse-v3-infrastructure-evolution" target="_blank">runs entirely on ClickHouse</a>, both in the cloud offering and for self-hosted deployments. The scale and performance requirements of LLM observability demand a database <a href="https://www.youtube.com/watch?v=NXYQ5odATrM" target="_blank">that can handle</a> high-volume writes and fast analytical queries. This existing alignment means tighter integration and better performance for everyone.

**Shared Open-source DNA.** We believe that being good stewards of open-source means not just maintaining code, but actively investing in and growing the communities that depend on it. Langfuse has built exactly the kind of vibrant developer community we love to support—one where contributors actively shape the product and enterprise adoption follows organic grassroots momentum, embracing open standards like OpenTelemetry. This is the same playbook that made ClickHouse what it is today, and we're excited to bring that same energy to the Langfuse community.

**The product is comprehensive.** Langfuse is a  <a href="https://langfuse.com/enterprise" target="_blank">complete platform</a> covering AI observability, prompt management, evaluations, and experimentation. The data models and SDK layers are thoughtfully designed for the unique challenges of LLM applications.

![observability-image.png](https://cms.clickhouse-dev.com:1337/uploads/observability_image_b64e9276e3.png)

>"Generative AI will only earn enterprise trust when we can see what's happening under the hood. Langfuse enables us to track every prompt, response, cost, and latency in real time, turning black-box models into auditable, optimizable assets."  \
> \
> *Walid Mehanna, Chief Data & AI Officer at Merck* (<a href="https://langfuse.com/customers/merckgroup" target="_blank">source</a>)

## The synergy

This acquisition follows the same playbook we've used successfully with <a href="/blog/clickhouse-welcomes-peerdb-adding-the-fastest-postgres-cdc-to-the-fastest-olap-database" target="_blank">PeerDB</a> (for Postgres CDC) and <a href="/blog/clickhouse-acquires-hyperdx-the-future-of-open-source-observability" target="_blank">HyperDX</a> (for infrastructure observability). We join forces with category-leading open-source projects that are already built on ClickHouse and share our commitment to developer experience and community-first development.

With Langfuse, we're doing the same for AI observability:
- **Langfuse remains 100% open-source** under its existing MIT license for core features which allows for self-hosting at production scale (on top of ClickHouse)
- **Langfuse Cloud continues operating** as a standalone service
- **Community-first development** continues with the same transparency and openness

The tighter integration between Langfuse and ClickHouse means we can optimize the entire stack together—from data collection through to analysis and action. This creates a feedback loop that benefits both Langfuse users (through better performance) and ClickHouse users (through insights that help us optimize for AI workloads).

>"Langfuse has really enabled our developers to get extremely fast feedback. When building and deploying features, we can quickly watch how those experiences are going. Langfuse is fundamental to how our developers understand their AI implementations." \
> \
> *Walt Wells, Staff Software Engineer at Khan Academy (<a target="_blank" href="https://langfuse.com/customers/khan-academy">source</a>)*

## What this means for the Agentic Data Stack
The <a href="/ai" target="_blank">Agentic Data Stack</a> (our vision for AI-powered applications built on ClickHouse and LibreChat) now gains a critical new capability: the ability to monitor, evaluate, and continuously improve the AI components themselves.

For data analysts and administrators using LibreChat to query their data warehouses, Langfuse provides visibility into how well the agents are performing. For developers building custom agentic workflows with our APIs and MCP servers, Langfuse offers the debugging and optimization tools they need to ship with confidence.

The three main personas of agentic analytics—data professionals operating databases, developers building AI features, and business users consuming insights—all benefit from knowing that their AI interactions are monitored, evaluated, and improving over time.

## What's next?
**For existing Langfuse deployments:** Nothing changes. Langfuse continues to work exactly as it does today, and we are committed to continuing to invest in the platform and community.

**For Langfuse Cloud customers:** The service continues operating with the same SLAs and support. The Langfuse team is focused on expanding the roadmap, not disrupting what's working.

**For ClickHouse users:** Over the coming months, we'll be releasing deeper integrations that make LLM observability a native part of the agentic data stack experience. Expect seamless connections between your AI workloads and the tools to understand them.

**For everyone:** Join the communities on <a href="/slack" target="_blank">Slack</a> to stay connected as we build the future of AI observability together.

## Get started
**For Langfuse users:** Continue using Langfuse as you always have. Check out the excellent <a href="https://langfuse.com/docs" target="_blank">documentation</a> if you're new, or explore the latest features if you're already on board.

**For ClickHouse users:** If you're building AI-powered applications, <a  target="_blank" href="https://langfuse.com">try Langfuse</a> to add observability to your LLM interactions. The integration with ClickHouse as a backend store is already seamless.

**For everyone else:** The AI quality monitoring space is only going to become more important as AI becomes more central to how software works. Now is the time to get serious about understanding your AI systems.

As always, the ClickHouse team would be honored to partner with you on your AI journey. Whether you're using Langfuse today or are just starting to think about LLM observability, please <a href="/company/contact" target="_blank">contact us</a>.


We are thrilled to announce that ClickHouse has acquired Langfuse, the leading open-source platform for LLM observability, evaluations, and prompt management.

large_ClickHouse-Langfuse.png

medium_ClickHouse-Langfuse.png

small_ClickHouse-Langfuse.png

thumbnail_ClickHouse-Langfuse.png

ClickHouse-Langfuse.png

ClickHouse welcomes Langfuse: The future of open-source LLM observability

[clickhouse.build](https://github.com/ClickHouse/clickhouse.build) is an open source, agentic CLI that accelerates the adoption of ClickHouse within your existing Postgres-backed TypeScript application. The goal is not to replace Postgres, but to seamlessly combine it with ClickHouse for analytical workloads, using the strengths of each database together, within the same application. 

It uses a multi-agent workflow that:

* Scans your Postgres-backed codebase to identify analytical queries (whether SQL in-line or ORM-based)  
* Determines which tables are required to support those analytical queries and creates a plan.  
* Helps to automatically sync the relevant tables to ClickHouse Cloud using ClickPipes API.  
* Rewrites the relevant portions of the code so that it uses ClickHouse for analytics and Postgres for transactions, while keeping the application backwards-compatible by introducing a feature flag.

clickhouse.build is intended as an accelerator, and can help you to have a working proof of concept (PoC) in under an hour. You can use the PoC to evaluate how your application performs with a combined Postgres+ClickHouse backend.

Already evaluating Postgres + ClickHouse? [Skip to how it works](#how-clickhousebuild-works), or read on to understand why these two  databases are so good together.

![chbuild.png](/uploads/chbuild_8f68f3f55e.png)

Try clickhouse.build today with a free trial of ClickHouse Cloud. Get a working PoC in under an hour.

Try clickhouse.build today

Work on clickhouse.build was initiated in partnership with the AWS Prototyping and Cloud Engineering ([PACE](https://www.linkedin.com/groups/12710205/)) team and uses Amazon Bedrock and the [Strands Agents SDK](https://github.com/strands-agents/sdk-python). We would like to thank our partners for this collaboration.

## Postgres + ClickHouse: the default data stack

Postgres & ClickHouse have seen huge community adoption; they are the most popular open source databases in their respective categories, each with flourishing ecosystems around them. That adoption has seen [the two become an unbeatable duo](https://about.gitlab.com/blog/two-sizes-fit-most-postgresql-and-clickhouse/), with [agentic AI only accelerating the trend](https://clickhouse.com/blog/langchain-why-we-choose-clickhouse-to-power-langchain).

### Adding ClickHouse to a Postgres application

ClickHouse doesn’t replace Postgres, instead, the two work in tandem to handle workloads that are best suited to them; transactional workloads go to Postgres, and analytical workloads go to ClickHouse. 

Many application backends are sending all queries to Postgres, whether it's a `SELECT *` of a single row by ID, or performing a `SUM() … GROUP BY` over 100,00 rows. The former is where Postgres shines, while the latter can be 100-1000x faster in ClickHouse.

![chb_pgonly_diag.jpg](/uploads/chb_pgonly_diag_8a9fd8e7ea.jpg)

With Postgres + ClickHouse, your application backend can send queries to the right database for the job. You avoid needing to oversize Postgres or fight with replication, and improve the user-facing performance and experience. Prototyping the new architecture can take a few weeks, particularly if it's your first time with ClickHouse, while you identify the right queries to migrate, setup data synchronization, and update backend integration. Building this prototype is where clickhouse.build can help.

![chb_pg_and_ch_diag.jpg](/uploads/chb_pg_and_ch_diag_b7774d3bf6.jpg)

## How clickhouse.build works

The clickhouse.build CLI uses multiple, task-specific agents to migrate Postgres-backed TypeScript apps to a Postgres+ClickHouse architecture. These agents can be used independently, or called via an all-in-one workflow. A Quality Assurance (QA) sub-agent checks every proposed code change, which has been augmented with high-quality reference examples.

There are 3 primary agents:

### Scanner

The scanner agent scans your TypeScript code base and looks for Postgres queries. It currently works whether you use a direct Postgres driver with queries in code, or using the query builders of Prisma and Drizzle ORMs.

When it finds queries, it will inspect them to determine whether the query is better suited for Postgres or ClickHouse: single-row lookups and insert/update/delete operations are typically best fit for Postgres, while COUNTs, SUMs and GROUP BYs are more optimal in ClickHouse. The scanner agent produces a structured output report with the identified queries that should be migrated to ClickHouse.

scanner_agent_edited.mp4

*A demo of the scanner agent, called on its own outside of the all-in-one workflow*

### Data migrator

The data migrator agent assists in syncing the necessary Postgres tables to ClickHouse. Based on the queries identified by the scanner agent, it determines which tables ClickHouse needs to serve the queries. It then generates the relevant ClickPipes API payloads to configure the [ClickPipes Postgres CDC connector](https://clickhouse.com/docs/integrations/clickpipes/postgres). This connector keeps ClickHouse in sync with Postgres, first backfilling all historical data, and then maintaining a continuous, real-time flow of changes from Postgres to ClickHouse.



data_agent_edited.mp4

*A demo of the data migrator agent, called on its own outside of the all-in-one workflow*

### Code migrator

The code migrator agent handles the job of updating queries and code. It can adjust SQL syntax to be correct for ClickHouse (queries between Postgres and ClickHouse are often compatible without change, but not always, especially if ORM query builders are used), and update TypeScript code to call ClickHouse via the [official ClickHouse JS client](https://clickhouse.com/docs/integrations/javascript). This agent will pause the migrations after each significant step, requesting input for the human to accept or reject the changes proposed. It’s also possible to accept all changes in one command.

Rather than remove your existing, working Postgres queries, the code migrator uses a backwards compatible indirection pattern. The queries for each database are moved to separate utility files, and a feature flag lets you pick which backend to use at run time. This means you can easily toggle between the two modes to compare performance and correctness while you evaluate your resulting application.

#### QA agent

The QA agent is a sub-agent of the code migrator, which validates any changes made. The code migrator will suggest what it wants to do, and then ask the QA agent if the change is appropriate. The QA agent scans the change and runs checks and validations comparing patterns against patterns from a series of reference code bases that already use Postgres+ClickHouse successfully.

code_agent_edited.mp4

*A demo of the code migrator agent, called on its own outside of the all-in-one workflow*

### All-in-one workflow

While each agent can be used on its own, the CLI has an all-in-one workflow that invokes each agent in the correct order (scanner -> data migrator -> code migrator). This is generally the recommended way to use the CLI for your PoC, but we won’t hold it against you if you want to call the agents yourself.

## Using clickhouse.build

You can get the CLI from the [clickhouse.build GitHub repo](https://github.com/ClickHouse/clickhouse.build). The README contains detailed instructions on setting up and configuring the CLI.

With the CLI configured, **we recommend creating a new branch in your application repository to work in**. You can then run the all-in-one migration workflow:

```py
uv run main.py migrate /path/to/your/repo --replication-mode cdc
```

This will walk through all agents in order: scanner -> data migrator -> code migrator. **The agents are not fully autonomous** by default. The CLI will prompt you to review and accept/deny changes as you go, though you can choose to “accept all” if you wish.

The scanner agent will go through your code, discover your Postgres queries, and output a structured JSON file of the queries, a description, and their file location. The data migrator agent will read this scan file and extract the names of tables that need to be replicated into ClickHouse. With the `--replication-mode cdc` option set, the **data migrator agent will produce the `curl` commands needed to configure ClickPipes Postgres CDC** via the [ClickHouse Cloud API](https://clickhouse.com/docs/cloud/manage/api/api-overview).

Currently, **the ClickPipes configuration commands require some manual input**. Along with the command, the output contains some environment variables you’ll need to complete some details about your ClickHouse Cloud account and Postgres instance. With these details completed, you’ll need to run the `curl` commands yourself.

clickpipes_edited.mp4

*A demo of running the ClickPipes configuration commands and validating the running ClickPipes service in ClickHouse Cloud*

The code migrator agent is the final piece of the workflow. It begins by loading the scan file and installing the [clickhouse.js driver](https://clickhouse.com/docs/integrations/javascript) using your project’s package manager. After loading some reference examples of Postgres+ClickHouse implementations in its context, the agent begins analysing your code base to build a plan of what to change. 

The agent aims to implement the ‘strategy pattern’, where the specific backend implementation is abstracted. This pattern means you can toggle between using the original Postgres backend or the new ClickHouse+Postgres backend with a simple feature flag. A file for each of Postgres and ClickHouse is created under `lib/strategies` which contains the logic for serving your queries via each of the respective databases. The agent will attempt to find the correct way to integrate this into your project, which means the next step can vary a bit. A common pattern is to create a database configuration at `lib/db.ts` which implements the logic to toggle between these strategies, and then update your existing routes to use the backend as configured in `db.ts`.

With each step, you’ll be asked to review the changes (unless you have chosen to accept all), and the QA sub-agent will automatically review changes for baseline quality against the reference examples.

The workflow will wrap up by ensuring your project builds, producing a summary of the changes it made, and instructions on how to use the feature flag to toggle between strategies. You can now evaluate the impact of using ClickHouse in your application.

### Evaluating the result

You can run your application as normal, and it should continue to use your existing Postgres implementation by default. To use the new ClickHouse implementation, **add the new feature flag to your environment variables: `USE_CLICKHOUSE=true`**. You can flip this flag to `false` to switch back.

evaluate_poc_edited.mp4

*A demo of an application being switched between Postgres and ClickHouse backends, showing a 3x gain in performance.*

We recommend testing the normal flows of your application, having new rows inserted into Postgres to test replication, and comparing the performance of features with and without the ClickHouse feature flag enabled. 

In many cases, the difference is immediately obvious; you should see that stats, charts, and tables that display analytics load several times faster without perceptible latency. Though it can be more fun to put some logging in and see the real numbers!

The change in performance you’ll see can be variable, but generally, the larger your data, the bigger the performance gain.

## The clickhouse.build design principles

clickhouse.build is a highly opinionated implementation. Its design is informed by lessons we have learned building agents for [data warehousing](https://clickhouse.com/blog/ai-first-data-warehouse), [for SREs](https://www.youtube.com/watch?v=og8ieNxixp4), and [agentic analytics](https://clickhouse.com/blog/agent-facing-analytics).

We believe that the best agentic flows **keep the human in the loop**, not only keeping you informed, but also involved in the actions that are taken. **Backwards compatibility** ensures we can validate correctness and assess the real impact of changes.

Agentic workflows are new, our understanding is still evolving, and we should approach changes to production with caution, but **agents are an obvious accelerator in development and proof of concepts**.

Agents can be tuned for different tasks by supplying specific context and instructions, which means **we can have one agent optimised to make changes, and another optimised to validate those changes**. We’ve seen that this can be effective in reducing errors, but it isn’t always perfect - that’s why we keep the human around, too.

**Evaluations might just be the highest impact and under-explored area** that we see in agentic workflows today. Getting to an 80% level of quality can be achieved relatively easily, but going beyond this barrier takes significant effort. We think this is where evaluations become critical, allowing us to constantly review, assess, and improve. But they can also be hard to do, and easy to forget. To mitigate this, we aim to bake evaluations into the workflow itself, adopting new techniques and tooling as the space develops.

**Open-source is the way forward.** There’s no secret sauce behind clickhouse.build. While most companies are building proprietary agents that are served from some black-box API, we decided to build an open, client-side application that’s free to use and free to adapt. Want a new LLM API? To support a new database? [We’d love for you to contribute!](https://github.com/ClickHouse/clickhouse.build)

## What’s next?

[Accelerating Postgres with ClickHouse](https://clickhouse.com/resources/engineering/managed-postgres-for-ai-and-real-time-apps) is just the beginning for clickhouse.build. We started with Postgres because this combination has become the default data stack for high-performance applications. But other transactional databases, like MySQL or MongoDB, benefit just as much and are a natural next step.

Similarly, we expect to expand support beyond TypeScript apps, with likely next candidates being Python, Go, Rust, or Ruby.

We also see this model benefiting not just application builders, but data and analytics engineers as well, where ClickHouse can reduce the cost and accelerate the workloads of cloud data warehouses.

clickhouse.build is open source and open for contributions. Feedback, suggestions, and comments are welcome; we’d love to see you in our [Community Slack](https://clickhouse.com/slack).

clickhouse.build is an open source, agentic CLI that accelerates the adoption of ClickHouse within your existing Postgres-backed TypeScript application.

large_clickhousebuildbanner.jpg

medium_clickhousebuildbanner.jpg

small_clickhousebuildbanner.jpg

thumbnail_clickhousebuildbanner.jpg

clickhousebuildbanner.jpg

clickhouse.build: An agentic CLI to accelerate Postgres apps with ClickHouse

We've been talking about[ agent-facing analytics](https://clickhouse.com/blog/agent-facing-analytics) for a while now. The idea is that AI agents would become primary consumers of analytics databases, running queries at machine speed and generating insights semi-autonomously. Well, today we're making that future more accessible by announcing the public beta release of two flagship features: the ClickHouse Ask AI agent and the remote MCP server for ClickHouse Cloud.

## The “Ask AI” agent in ClickHouse Cloud
The “Ask AI” agent is a turn-key experience that allows users to trigger complex analysis tasks on top of the data hosted in their ClickHouse Cloud service. Instead of writing SQL or navigating dashboards, users can describe what they are looking for in natural language. The assistant responds with generated queries, visualizations, or summaries, and can incorporate context like active tabs, saved queries, schema details, and dashboards to improve accuracy. It’s designed to work as an embedded assistant, helping users move quickly from questions to insights, and from prompts to working dashboards or APIs.

![ask_ai.gif](https://cms.clickhouse-dev.com:1337/uploads/ask_ai_d57107b308.gif)

The experience also embeds a "Docs AI" sub-agent that can be used to ask specific questions about the ClickHouse documentation straight from the console. Instead of searching through hundreds of pages, users can ask direct questions like "How do I configure materialized views?" or "What's the difference between ReplacingMergeTree and AggregatingMergeTree?" and receive precise answers with relevant code examples and links to source documentation. 


![image 2 unnamed.png](https://cms.clickhouse-dev.com:1337/uploads/image_2_unnamed_c7b0c3ac51.png)


## Remote MCP Server Integration
Not all users interact with ClickHouse through the Cloud console, however. For example, many developers work directly from their preferred code editors, CLI agents, or connect to the database via custom setups, while others rely on general-purpose AI assistants such as Anthropic Claude for most of their explorations. These users, and the agentic workloads acting on their behalf, need a way to securely access and query ClickHouse Cloud without complex setups or custom infrastructure.

![image 3.png](https://cms.clickhouse-dev.com:1337/uploads/image_3_936c8d05a0.png)



:::global-blog-cta:::




The new remote MCP server capability in ClickHouse Cloud addresses this by exposing a standard interface that external agents can use to retrieve analytical context. MCP, or [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro), is a standard for structured data access by AI applications powered by LLMs. With this integration, external agents can list databases and tables, inspect schemas, and run scoped, read-only SELECT queries. Authentication is handled via OAuth, and the server is fully managed on ClickHouse Cloud, so no setup or maintenance is required.

This makes it easier for agentic tools to plug into ClickHouse and retrieve the data they need, whether for analysis, summarization, code generation, or exploration.

![mcp_cursor.gif](https://cms.clickhouse-dev.com:1337/uploads/mcp_cursor_125691e256.gif)

Note that we also provide a “traditional” MCP Server for ClickHouse, which can be used in self-managed setups and installed via PyPI. At the time of writing, it has been downloaded more [than 220k times](https://clickpy.clickhouse.com/dashboard/mcp-clickhouse).

[https://github.com/ClickHouse/mcp-clickhouse](https://github.com/ClickHouse/mcp-clickhouse)


## Reducing Time to Insight
Features like Ask AI and a remote MCP server directly influence the velocity at which insights can be extracted from data. Traditional analytics workflows often involve multiple handoffs between data engineers writing queries, analysts building dashboards, and business users interpreting results. Each step introduces latency measured in hours or days.  \
 \
With these agentic capabilities, that timeline collapses to seconds or minutes. A product manager can ask "What's driving the spike in churn last week?" and immediately receive not just the answer, but the underlying query, a visualization, and potential next questions to explore. 

This is closely aligned with our own experience at Clickhouse. Six months ago, we introduced Dwaine (Data Warehouse AI Natural Expert): an internal agent that enables our team to query business data through natural language. Since then, questions like "What's our current revenue?", "How is this customer using our product?", "What issues are customers experiencing?" or "What's our website traffic and conversion rate?" are getting instant answers. Dwaine has transformed how our internal teams access insights, eliminating the bottleneck of SQL queries and data requests. The adoption quickly followed, for instance, ClickHouse internal users generated more than 15 million LLM tokens in a single day on Dwaine, roughly 1 month after its rollout. 


![image 5 .png](https://cms.clickhouse-dev.com:1337/uploads/image_5_9cbcd1cc6f.png)


*The first 3 months of DWAINE - Token Counts per Day*


If you want to experience what it looks like, we recommend visiting [llm.clickhouse.com](http://llm.clickhouse.com), our public demonstration agent code-named [AgentHouse](https://clickhouse.com/blog/agenthouse-demo-clickhouse-llm-mcp), which exposes publicly available datasets via an agentic interface.

Finally, while grounding responses in real-time data helps, AI agents are not immune to hallucinations: situations where the model generates incorrect information with high confidence. Our own experience running internal agents within ClickHouse taught us that the best remediation comes from providing the LLMs with the maximum and most accurate context possible. This can be achieved by commenting the tables using the SQL [COMMENT](https://clickhouse.com/docs/sql-reference/statements/alter/column#comment-column) syntax for example, or by providing more context in-line, in the chat, or part of the system prompt of an LLM session.


## Conclusion
The beta release of Ask AI and remote MCP server represents a step toward our vision of the agentic analytics experience. By making ClickHouse natively accessible to both interactive users through natural language and third-party agents through MCP, we're aiming at reducing the friction that has traditionally separated questions from answers. You can read more about these features in our documentation: [Ask AI](https://clickhouse.com/docs/use-cases/AI_ML/AIChat), [Remote MCP server](https://clickhouse.com/docs/use-cases/AI/MCP/remote_mcp). \
 \
As always, when we release Beta features, we’d love to receive your feedback and remarks, as it’s the only way to improve! You can contact us using this [form](https://clickhouse.com/company/contact) or via our [community Slack](https://clickhouse.com/slack).


Announcing Ask AI beta and remote MCP server, powering faster agentic analytics in ClickHouse Cloud.  

Ryadh Dahimene

Blog posts by Ryadh Dahimene

ClickHouseエージェント: Claudeを活用したエージェント型アナリティクスがパブリックベータで登場

ClickHouse Agents: Claude-powered agentic analytics, now in public beta

Announcing chDB 4: write Pandas, run ClickHouse, now on Hex

ClickHouse welcomes Langfuse: The future of open-source LLM observability

clickhouse.build: An agentic CLI to accelerate Postgres apps with ClickHouse

One step closer to Agentic Analytics: Ask AI agent & Remote MCP server beta launch