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 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.  

large_493369401-17fb9426-b9d9-4880-9af6-e252e2c5d498.jpg

medium_493369401-17fb9426-b9d9-4880-9af6-e252e2c5d498.jpg

small_493369401-17fb9426-b9d9-4880-9af6-e252e2c5d498.jpg

thumbnail_493369401-17fb9426-b9d9-4880-9af6-e252e2c5d498.jpg

493369401-17fb9426-b9d9-4880-9af6-e252e2c5d498.jpg

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

リアルタイム分析における新たなユーザーペルソナとしてのAIエージェント

large_Agent Facing Analytics Feb 2025.png

medium_Agent Facing Analytics Feb 2025.png

small_Agent Facing Analytics Feb 2025.png

thumbnail_Agent Facing Analytics Feb 2025.png

Agent Facing Analytics Feb 2025.png

エージェント向け分析

AI agents as an emerging user persona in real-time analytics

Agent-Facing Analytics

As 2024 comes to a close, explore the evolution of SQL-based observability and ClickHouse’s latest developments, including enhanced JSON support, OpenTelemetry integration, and powerful time series capabilities.

Ryadh Dahimene

Blog posts by Ryadh Dahimene

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

エージェント向け分析

Agent-Facing Analytics

The evolution of SQL-based observability