Silverflow uses ClickHouse Cloud to power near-real-time analytics on global payment events, supporting dashboards, alerting, and operational decision-making. By streaming events directly into ClickHouse, insights that once took 20 minutes to appear in Grafana now arrive in 65 seconds—a 95% reduction in end-to-end latency. ClickHouse’s dynamic JSON ingestion and ClickPipes replaced dozens of ETL pipelines, reducing engineering costs while keeping analytics SQL-based. 

Summary

[Silverflow](https://www.silverflow.com/) was founded with a clear ambition: replace legacy card-processing infrastructure with a cloud-native platform that lets customers connect directly to card networks through a single, unified API. Since its launch in 2019, that promise has carried the company far beyond its Amsterdam roots. Today, Silverflow operates across Europe, the U.S., and Asia-Pacific, with offices in London and New York and a growing roster of global customers.

But that kind of growth also brings challenges, with every new region, feature, and customer adding volume, variety, and urgency to the stream of events flowing through the platform. “Rapid growth means that data volume and complexity increase quite a lot,” says Roberta Gismondi, a software engineer at Silverflow. “And for us at this stage, it’s crucial to be able to gather the insights we need to optimize and to scale from this data.”

Roberta joined us at our [Open House 2025 roadshow in Amsterdam](https://clickhouse.com/openhouse/amsterdam), where she shared how Silverflow rebuilt its data platform on [ClickHouse Cloud](https://clickhouse.com/cloud), unlocking faster analytics, reducing engineering overhead, and turning payments data into something teams can rely on for real-time dashboards, alerting, and day-to-day decisions.

## The old system’s bottlenecks

As Silverflow grew and expanded into new regions, it also broadened its product offerings, shipping new features quickly. “That means we have a lot of systems, a lot of components, a lot of event types that are emitted by our feature teams,” Roberta says. “And that’s without counting system events.”

For a time, Silverflow’s original data architecture did what it needed to do. Events were published to a central bus, archived, and processed through scheduled ETL jobs. From there, data landed in an S3-backed data lake and could be queried using Athena, with dashboards built in Grafana and other BI tools.

“This served us well,” Roberta says. “But as we scaled, we encountered a few bottlenecks, mostly around latency and the engineering cost to maintain all of this.”

Data freshness was a major problem—or rather, the lack of it. Some of Silverflow’s most important operational data took up to 20 minutes to become available for querying. Once it was, interactive queries took several seconds just to start, and 10 to 20 seconds to complete. “When the data is supposed to inform time-sensitive decisions—things like anomaly detection, monitoring, alerting—this is clearly less than ideal,” Roberta says.

At the same time, the cost of maintaining the system kept rising. “Our ETL pipelines were cumbersome, required a lot of maintenance, and in turn, that became quite expensive for our engineers,” Roberta explains. Each event type and version required its own ingestion logic, and those pipelines had to be updated constantly as the platform evolved. As Silverflow’s six feature teams moved quickly and events changed just as fast, pressure on the data engineering team grew. “It was just very hard for us to keep up with all of that,” she says.

## A new approach to events

In early 2025, several members of the Silverflow team, including data engineer David Forbes (who Roberta calls “the main mind behind our data platform”), attended the Data Innovation Summit in Stockholm. They returned to Amsterdam with pages of notes and one idea circled at the top: *ClickHouse’s new approach to JSON.*

“We’re very conservative with headings at Silverflow,” Roberta jokes. “So I was definitely intrigued.”

Within months, the team had stood up its first ClickHouse cluster. Rather than re-architecting everything at once, they started by integrating [ClickHouse Cloud](https://clickhouse.com/cloud) directly into their existing event architecture. Events published by feature teams continued to flow through Kinesis, but instead of being fanned out into dozens of pipelines, they streamed straight into ClickHouse using [ClickPipes](https://clickhouse.com/cloud/clickpipes), the database’s native ingestion service.

All events now land in a single, dynamically typed table. From there, the team maintains a small number of [materialized views](https://clickhouse.com/docs/materialized-views) to accelerate the most important queries and aggregations. Dashboards still live in Grafana, but the data powering them, and how quickly it arrives, has fundamentally changed.

## Breaking the latency barrier

ClickHouse immediately addressed Silverflow’s latency bottleneck. As a [columnar database](https://clickhouse.com/resources/engineering/what-is-columnar-database) designed for analytical workloads, it reads only the data needed for each query. “It turns out being column-oriented comes in pretty handy when querying things,” Roberta says. “Our events are very big, so being able to strip that down and reduce I/O improves performance quite a lot. This is crucial for analytical workloads.”

The ingestion path saw a major boost, too. Streaming events directly from Kinesis into ClickHouse eliminated multiple buffering and transformation steps. “That meant events were faster to query, but also that they were there to be queried much faster,” Roberta says. Insights that once took 20 minutes to appear in Grafana now arrive in just over a minute end to end—a roughly 95% reduction in data freshness latency.

That shift unlocked new use cases almost overnight. Real-time dashboards became a reality, alerting is timely rather than retrospective, and product and account teams can rely on data to reflect what’s happening *now*, not what happened half an hour ago. “This made a lot of non-engineers very happy,” Roberta says, “to be able to gather all those insights so easily.”

## Fewer pipelines, less friction

The second win was just as important, even if it was less visible on a dashboard.

Thanks to [ClickHouse’s ability to work directly with semi-structured JSON](https://clickhouse.com/docs/integrations/data-formats/json/overview), Silverflow collapsed its entire ingestion layer into a much simpler model. Now, instead of maintaining one pipeline per event type and version, everything flows into a single table. Materialized views handle optimization, rather than bespoke ETL code.

“That pretty much replaced our whole ingestion pipeline,” Roberta says. For the data team, that means fewer moving parts to maintain and far less coordination overhead with feature teams. For analysts and engineers across the company, it means they can continue using familiar SQL-based tools without learning a new stack.

ClickHouse became, in Roberta’s words, a “drop-in replacement” for much of the existing query layer, only faster, simpler, and easier to operate. The result is a dramatic reduction in infrastructure complexity and a major shift in how teams interact with data.

## Looking ahead with ClickHouse

Silverflow’s move to ClickHouse is still unfolding. In the near term, the team plans to migrate more workloads onto the new platform and make historical event data easier for non-technical users to explore. Over time, they expect to fully decommission their legacy ETL pipelines and standardize on ClickHouse as the foundation of their analytics stack.

There are also strategic considerations on the horizon. Data residency requirements in the U.S. have the team thinking about [regional deployments](https://clickhouse.com/docs/cloud/reference/supported-regions) and [cross-cluster queries](https://clickhouse.com/docs/engines/table-engines/special/distributed), capabilities that fit naturally into ClickHouse’s architecture.

For Roberta, the journey so far is less about a single technology choice than about removing friction and reclaiming momentum. “This has been a good outcome for the experiment,” she says. “And we want to experiment more.”

At a company built to move fast, the ability to see what’s happening clearly and quickly has become a competitive advantage in its own right. With ClickHouse Cloud, Silverflow has turned its growing stream of payment events into something closer to real-time understanding, and established a strong foundation for whatever comes next.


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

Looking to scale your team’s data operations? 

“With ClickHouse, events are faster to query, and they’re also available to be queried much faster, which has enabled us to do more real-time dashboarding and faster alerting.”  Roberta Gismondi, Software Engineer

large_Silverflow User Story Issue 1226.png

medium_Silverflow User Story Issue 1226.png

small_Silverflow User Story Issue 1226.png

thumbnail_Silverflow User Story Issue 1226.png

Silverflow User Story Issue 1226.png

How Silverflow simplified its data platform and cut end-to-end latency by 95% with ClickHouse Cloud

When [Langfuse](https://langfuse.com/) first shared its [journey from Postgres to ClickHouse](https://clickhouse.com/blog/langfuse-and-clickhouse-a-new-data-stack-for-modern-llm-applications) in March 2025, the challenge was clear. Their open-source LLM engineering platform had outgrown a simple, developer-friendly architecture, and the team needed a new data foundation to keep pace with rapidly scaling usage. ClickHouse became that foundation, allowing Langfuse to ingest and analyze orders of magnitude more data without sacrificing performance or flexibility.

By October, at our [Open House roadshow in Amsterdam](https://clickhouse.com/openhouse/amsterdam), the focus had naturally shifted. [ClickHouse Cloud](https://clickhouse.com/cloud) was running in production, and the questions were no longer about database choice. They were about how the shape of LLM applications themselves is changing, and what starts to break when systems that once handled millions of records are suddenly dealing with billions every month. As teams move from relatively simple RAG workflows to complex, agentic systems, observability must evolve along with them. The bottlenecks that matter most are no longer the obvious ones.

What followed was a field report from the frontier, tracing how Langfuse’s data model, ingestion patterns, and even SDK design have had to adapt as LLM applications continue to mature. As Langfuse co-founder and CTO Max Deichmann puts it, “What we’re building is observability for engineering teams working on the most complex and advanced agentic systems.”

## When LLMs got complicated

In the earliest days of production-grade LLM applications, the architecture was relatively straightforward. A user query went into a retrieval system, a handful of documents came back, and those documents were passed to a model to generate a response. These RAG workflows were simple enough to reason about, and simple enough to observe.

But that simplicity didn’t last long. “People realized this is not enough,” Max says. If you want better answers, more reliability, or richer behavior, the system has to do more.

As teams pushed for higher-quality outputs, they moved beyond single-shot prompts toward agentic systems that plan, iterate, and interact with external tools. Now, an agent might call a search API, query a database, invoke an internal service, reassess its plan, and repeat the process several times before producing an answer.

Once applications cross that line, observability becomes a different story. Engineers are no longer simply asking whether a request succeeded. They want to know whether the agent took the right tool call, passed the right parameters, or planned the right next step. And because, as Max puts it, “LLMs don’t have predictable outcomes,” the same input can lead to different execution paths.

Langfuse is built around that reality. “Tracing is at our core,” Max says. The platform started with familiar trace trees, but expanded into graph views that show how an agent moves through its turns and tool calls over time, along with specialized rendering for [large prompts](https://langfuse.com/docs/prompt-management/overview), completions, and business-level metadata.

From there, Langfuse moved beyond individual traces to analytics. Teams want to understand how latency, cost, and quality evolve across thousands or even millions of runs. They want to compare versions of an agent, test changes against production data, and see how behavior shifts over time. That’s why Langfuse added tools like datasets, which let users treat real traces as integration tests and [evaluate different agent versions](https://langfuse.com/docs/evaluation/overview) side by side.

Over the last two years, the product has grown into a full data platform that’s open by design, with [public APIs](https://langfuse.com/docs/api-and-data-platform/features/public-api) and export paths, supporting a growing ecosystem of teams building increasingly complex LLM systems. And all of that activity flows through one place: the database.

## From Postgres to ClickHouse

Langfuse’s previous architecture was intentionally simple: JavaScript and Python SDKs fed events into a single container backed by Postgres. Self-hosting was easy, and the team could move fast without much operational overhead. Even so, it was clear they would outgrow the setup someday. “We always knew this would happen,” Max says.

By June 2024, ingestion volumes had “skyrocketed,” along with IOPS costs. The team was running the largest available instance, and it still wasn’t enough. Analytical queries timed out. The ingestion API got so slow that users complained their SDKs couldn’t send data reliably. As a single-node database, Postgres was also an uptime risk. “We realized we needed to change Postgres,” he says, “or at least move the tracing data somewhere else.”

The team wrote a list of requirements: [columnar storage](https://clickhouse.com/docs/faq/general/columnar-database) for analytical queries, very high-volume [insert throughput](https://clickhouse.com/docs/best-practices/selecting-an-insert-strategy), [multiple write and read nodes](https://clickhouse.com/docs/academic_overview), and [SQL](https://clickhouse.com/docs/sql-reference) so users could slice and dice their data at low latency. Because Langfuse is open-source and widely self-hosted, the database also had to be deployable anywhere under an OSS license. ClickHouse checked all those boxes. 

They built a new pipeline with [SDKs](https://langfuse.com/docs/observability/sdk/overview) and an [OTel endpoint](https://langfuse.com/integrations/native/opentelemetry) feeding events into Redis queues and S3, async workers processing those events, and ClickHouse at the center as the analytical engine. “It worked surprisingly well at very high traffic,” Max says.

![Langfuse Issue 1225.jpg](/uploads/Langfuse_Issue_1225_f20eeb99d8.jpg)

Langfuse’s ingestion pipeline, moving SDK events through queues and storage into ClickHouse.

The turning point came quietly. “One Saturday afternoon, I decided to flip the switch and start reading data from ClickHouse,” Max recalls. The impact was immediate. “It was like minutes on Postgres, and then once I flipped it, latencies dropped right away.” The team wrote an extensive [blog post](https://langfuse.com/blog/2024-12-langfuse-v3-infrastructure-evolution) on that architecture transition.

Over the following year, the system continued to scale as adoption grew. Charts that once showed massive ingestion spikes now barely register. “What was big then is very small now,” Max says. “ClickHouse has served us really, really well.”

With the database no longer holding them back, new questions emerged: “What are our next steps?” Max asks. “Where are the bottlenecks we see today?”

## Lessons learned at scale

As Max shared at Open House, running Langfuse on ClickHouse surfaced a new class of problems that had less to do with raw throughput, and more to do with how data models and access patterns interact with real-world usage.

One early lesson was that performance doesn’t stop at the database boundary. The team learned the importance of passing [primary keys](https://clickhouse.com/docs/best-practices/choosing-a-primary-key), especially timestamps, through frontend state, ensuring that every query hitting ClickHouse is as selective as possible. Small choices in how queries are shaped often matter just as much as how fast the database itself can run.

Another lesson was skepticism. Rather than assuming a single data model would work for everyone, Langfuse now spins up alternative models in separate ClickHouse services and tests them side by side using real production data. With users free to ingest almost anything, cardinality and distribution vary widely. “Test in production,” Max advises. “What works for one user doesn’t work for another one.”

They’ve also learned the value of isolating workloads. “[Compute-compute separation](https://clickhouse.com/blog/introducing-warehouses-compute-compute-separation-in-clickhouse-cloud) is really helpful for us,” Max says. “If one ClickHouse cluster is under fire, the other one is still chill and can serve the UI for our users.” That separation makes performance more predictable and helps protect interactive queries from ingestion spikes.

The hardest lessons, though, came from mutability and joins. Langfuse’s original design allowed SDKs to emit multiple events per span: one capturing the model and input immediately, another arriving later with outputs and cost. That behavior matched how users expect LLM systems to work—calls can take time, and teams want visibility as soon as something happens—but it pushed Langfuse toward mutable tables and frequent deduplication.

[ReplacingMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replacingmergetree) can be a “great” solution for this, Max says, but it comes with tradeoffs. “If you want to have very accurate data, you need to deduplicate whenever you read the data.” At the same time, frequent joins across massive trace and span tables added pressure of their own, pushing query complexity and latency higher as usage grew.

All this led Max to step back and ask: “Why do we even have mutable data? Why do we update? Because in traditional observability systems, people don’t update.” Those questions marked a turning point that would reshape how Langfuse models agent behavior and observability at scale.

## One immutable path forward

For Langfuse, the answer lies in how user expectations have changed. While partial updates once mattered, “now people care more about the overall performance of agents rather than single calls,” Max says. That shift makes a new model possible.

Today, Langfuse is moving toward a wide, immutable observations table (called the “Events” table) that collapses trace- and span-level data into one structure. Metadata like user and session IDs are propagated directly into that table, making it much easier to query without joins.

Staying true to Max’s earlier advice, the team didn’t treat this as a theoretical improvement. “We tested this new table in production,” he says. Compared to the old approach, the new model delivered around three times less memory usage and up to 20 times faster queries.

The question now, Max says, is, “How do we get there?” Thousands of deployments still rely on older SDKs that emit multiple events per span. Langfuse can’t force everyone to upgrade. Instead, the team is running background jobs to backfill legacy data into the new schema, while newer SDKs write directly to the immutable table.

It’s an incremental transition, but a deliberate one. “This will help our users get very low latencies across the UI and also our APIs,” Max says.

A year ago, ClickHouse helped Langfuse escape the limits of a single-node database. What followed is more subtle: removing hidden taxes in the data model, aligning ingestion with how users actually reason about agents, and continuously reshaping the system as LLM applications evolve.

As Max made clear in Amsterdam, scaling is less a destination than a moving target. With ClickHouse Cloud, Langfuse has the data foundation to keep adapting as that target moves.


## Langfuse joins ClickHouse

In the time since this story was drafted, [we announced that ClickHouse has acquired Langfuse](https://clickhouse.com/blog/clickhouse-acquires-langfuse-open-source-llm-observability), deepening the integration between Langfuse's LLM observability platform and ClickHouse's analytical capabilities.

The story of scaling observability for agentic systems continues - now under one roof.

Looking to scale your team’s data operations?

“We’re building observability for engineering teams working on the most complex and advanced agentic systems. ClickHouse has served us really, really well.”  Max Deichmann, Co-Founder and CTO

large_Langfuse Issue 1225.png

medium_Langfuse Issue 1225.png

small_Langfuse Issue 1225.png

thumbnail_Langfuse Issue 1225.png

Langfuse Issue 1225.png

How Langfuse is scaling LLM observability for the agentic era with ClickHouse Cloud

### AI時代に不可欠なデータ分析マネジメント領域において、大量かつ高速なデータ分析基盤で高度な意思決定を可能にし、日本企業のイノベーション創出と競争力強化を実現

リアルタイム分析データ基盤のリーディングカンパニーであるClickHouse Inc.（CEO: Aaron Katz）の日本法人、ClickHouse株式会社（クリックハウス、本社：東京都港区）は、金古 毅 （かねこ たけし）が、2026年2月1日付でClickHouse株式会社の代表取締役社長に就任したことをお知らせします。

金古毅は、日本マイクロソフト、レッドハットなどグローバル企業でのエンタープライズビシネス事業のリーダーとして20年以上の経験を持ちます。直近では、ニュータニックス・ジャパン合同会社でコーポレートバイスプレジデント 兼 代表執行役員社長として組織を牽引してきました。

![Takeshi Kaneko_blog announcement.png](https://cms.clickhouse-dev.com:1337/uploads/Takeshi_Kaneko_blog_announcement_79d2faf942.png)

昨年11月にJapan Cloudと提携し日本法人を設立したClickHouseは、大規模なリアルタイムデータ処理と分析のために設計された高速な列指向データベースを基盤とするデータ分析プラットフォームです。AIエージェントがソフトウェアに組み込まれ、より頻繁かつ複雑なクエリが生成される中、ClickHouseは高スループット・低レイテンシ（低遅延）を特長とし、こうした要求に応える性能を提供します。

ClickHouseは、AI時代におけるリアルタイムな意思決定を支える次世代アナリティクス基盤として、2016年のプロジェクト公開以降、グローバルで急速に採用を拡大しています。2021年に米国法人設立、2022年にClickHouse Cloud提供開始以降、わずか4年で世界3,000社以上に導入され、ARR（年間経常収益）は前年比4倍の成長を遂げています。Microsoft、OpenAI、Sony、Tesla、Deutsche Bank、Netflix、eBay、Trip.coといった業界を代表する企業から信頼されているClickHouseは、日本国内でも、楽天グループ、LINEヤフー、NEC、スマートニュースなど、大量かつ即時のデータ分析を重視する企業をサポートしています。

#### **▪️ClickHouse CEOのAaron Katzのコメント：**

このたび、豊富なエンタープライズビジネスの経験と卓越したリーダーシップを持つ金古氏を、ClickHouse日本法人の代表取締役社長として迎えられることを大変嬉しく思います。AIエージェントの活用が進む中で、リアルタイムかつ大規模なデータ分析に加え、AIエージェントのオブザーバビリティ（可観測性）を支えるデータ基盤の重要性は、これまで以上に高まっています。日本市場は、AIとデータを活用した高度な意思決定への関心が非常に高く、まさに今、ClickHouseの価値が最も発揮される市場の一つです。金古氏のリーダーシップのもと、日本のお客様やパートナーと共に、AI時代におけるデータマネジメントの新たなスタンダードを築いていくことを楽しみにしています。

#### **▪️ClickHouse株式会社 代表取締役社長 金古毅のコメント：**

このたび、ClickHouse株式会社の代表取締役社長に就任することを大変光栄に思います。AIがビジネスの中核に組み込まれる時代において、データを「蓄積する」だけでなく、「即座に分析し、意思決定につなげる」ことの重要性は飛躍的に高まっています。ClickHouseは、高速かつスケーラブルなデータ分析基盤として、日本企業の課題に真正面から応える次世代のデータマネジメント基盤です。これまで日本およびグローバル企業で培ってきた経験を活かし、日本のお客様がAIとデータを競争力に変えるためのパートナーとして、日本市場に根差した体制と顧客支援を強化し、日本企業のイノベーション創出と競争力強化に貢献してまいります。

#### **▪️ClickHouse株式会社 代表取締役社長 金古毅のプロフィール：**

1993年に株式会社トーメン（現・豊田通商）へ入社し、海外通信プラントにおけるプロジェクトマネジメント業務に従事。2000年に日本マイクロソフト株式会社へ転じ、OEMビジネスからクラウドビジネスまで幅広い領域でパートナービジネスを統括し、執行役員として成長を牽引した。2019年にレッドハット株式会社へ常務執行役員として参画し、パートナーアライアンスおよび中堅市場を担当。2020年からは副社長執行役員として日本市場全体の事業拡大に貢献した。2022年にはニュータニックス・ジャパン合同会社の代表執行役員社長に就任し、多様な業種・業態のお客様のDX推進をリード。2026年2月、ClickHouse株式会社に入社し、代表取締役社長に就任。

#### **＜ClickHouseについて＞**

ClickHouseは、リアルタイムデータ処理および分析のために設計された、高速なオープンソースのカラム型データベース管理システムです。高いパフォーマンスを実現するよう設計されたClickHouse Cloudは、卓越したクエリ速度と高い同時実行性能を提供し、膨大なデータ量から即座に洞察を得ることが求められるアプリケーションに最適です。AIエージェントがソフトウェアにますます組み込まれ、これまでよりもはるかに頻繁かつ複雑なクエリを生成するようになる中で、ClickHouseは、こうした課題に対応するために特別に設計された、高スループットかつ低レイテンシのエンジンを提供します。Sony、Tesla、Memorial、Sloan Kettering、Lyft、Instacartといった業界を代表する企業から信頼されているClickHouseは、スケーラブルで効率的、かつモダンなデータプラットフォームを通じて、チームが洞察を引き出し、より賢明な意思決定を行うことを支援します。詳細についてはこちら（[https://clickhouse.com/jp](https://clickhouse.com/jp)）をご覧ください。

LinkedIn: [ClickHouse Japan](https://www.linkedin.com/company/clickhouse-jp/about/)<br>
X: [ClickHouse Japan](https://x.com/ClickHouseJapan) <br>
Facebook: [ClickHouse Japan](https://www.facebook.com/ClickHouseJP)

AI時代に不可欠なデータ分析マネジメント領域において、大量かつ高速なデータ分析基盤で高度な意思決定を可能にし、日本企業のイノベーション創出と競争力強化を実現

large_ClickHouse Japan Country Manager_v2 (1).png

medium_ClickHouse Japan Country Manager_v2 (1).png

small_ClickHouse Japan Country Manager_v2 (1).png

thumbnail_ClickHouse Japan Country Manager_v2 (1).png

ClickHouse Japan Country Manager_v2 (1).png

ClickHouse 日本法人 代表取締役社長に 金古 毅 氏が就任

DoControl uses ClickHouse Cloud to power real-time analytics for SaaS security, governing file access, permissions, and third-party apps. After hitting the limits of Postgres, they migrated to ClickHouse Cloud for faster ingestion, complex filtering, and real-time queries at enterprise scale. They recently launched Dot, an AI-powered security assistant, using ClickHouse MCP to translate natural-language queries into real-time analytics workflows.


The rise of SaaS tools has made it easier than ever for teams to collaborate, but it’s also created a new kind of security challenge. Sensitive files can be shared with a click. Third-party apps proliferate without oversight. And while workplace productivity might boom as a result, organizations often have no idea how much risk they’ve inherited.

[DoControl](https://www.docontrol.io/) is all about identifying and addressing those blind spots. Founded in 2020 to bring control back to modern SaaS environments, the platform helps organizations govern access, detect misconfigurations, manage third-party integrations, and automate remediation across tools like Google Workspace, Microsoft 365, Slack, and more.

For many customers, the impact is immediate. “There’s a ‘wow moment’ when they’re finally able to get accurate visibility into their exposure,” says Amit Fidler, Director of Engineering. “They’re in shock when they see both the scale and risk of the exposure across millions of assets and applications—board materials, compensation data, competitive intelligence, former employee access, and more.”

DoControl empowers organizations to uncover, pinpoint, and remediate these risks within seconds, without compromising business productivity. But as adoption grew and the company started onboarding Fortune 500 customers with billions of assets, they ran into a new challenge: scale.

We caught up with Amit and the DoControl team to talk about outgrowing Postgres, migrating to [ClickHouse Cloud](https://clickhouse.com/cloud), and using [ClickHouse MCP](https://clickhouse.com/blog/integrating-clickhouse-mcp) to deliver AI-powered insights at scale.

## Growing pains with Postgres

Originally, DoControl’s analytics engine ran entirely on Postgres. It worked fine for most use cases, but as the company scaled and began ingesting tens of millions of assets from Google Drive and other SaaS platforms, the limitations quickly became apparent.

“Postgres is a pretty good database,” says Bar Ifrah, Technical Lead. “But the problem is, when you’re trying to build tens of indexes or run aggregations, it just can't do it.” 

Even with the indexes they built, the transactional database struggled to keep up with the volume of events and the complexity of the queries. “It’s not just about aggregation,” Bar adds. “Once we started onboarding enterprise-level customers, we couldn’t ingest all their data at the scale and pace we needed. We just didn’t have a good analytics system.”

Postgres remained the system of record for identity and filtering by ID, but it was no longer viable as the foundation for real-time analytics. The team began exploring alternatives, and eventually found their answer in [ClickHouse Cloud](https://clickhouse.com/cloud).

“We were super excited to start working with ClickHouse,” Amit says. “It has been a game-changer in how we serve the world’s largest companies, in a way that no competitive solution can match.”

## A new analytics engine with ClickHouse

For DoControl, the benefits of ClickHouse Cloud were clear right away.

“It’s much faster than Postgres,” Bar says. “When we added ClickHouse to the architecture, we could remove all the indexes, and ingestion worked much faster than before.”

“Now, we’re able to ingest tens of millions of files quickly and perform complex analytics in real time,” Amit adds. “Even querying a single asset across tens of millions of files and billions of permissions happens in real time, which is fantastic.”

Today, ClickHouse powers every analytics workflow in the product. From customer-facing dashboards to internal investigations, queries that once pushed Postgres to its limits now run smoothly. Whether it’s application data, audit logs, or sharing events, the team can query it live and surface insights instantly in the product UI. 

“This is something we couldn’t do with our previous database,” Amit says.

“The filters we’re allowing customers to run are very complex,” Bar adds. “ClickHouse’s ability to process a lot of data in a short period of time is a game-changer.”

DoControl currently operates ClickHouse instances across both AWS and GCP, an architecture that supports internal requirements and customer needs. ClickHouse Cloud’s multi-cloud support gives the team flexibility to run workloads where it makes the most sense.

With instances ranging from 100 GB to several terabytes across both clouds, DoControl has built a real-time analytics layer that’s sturdy and flexible enough to support its growing user base, while laying the foundation for what comes next.

## Agents, AI, and ClickHouse MCP

As the company looked to the future, the team felt convinced of one thing: the next wave of user interaction wouldn’t happen in a traditional UI. It would happen through conversation, with AI agents acting as the new front end.

So they built [Dot](https://www.docontrol.io/lp/dot), an AI-powered security assistant that helps users investigate events and answer questions about their environment. Dot uses [ClickHouse MCP](https://clickhouse.com/blog/integrating-clickhouse-mcp) (Model Context Protocol) to interact directly with ClickHouse, translating natural-language queries into SQL, performing “very interesting and complex aggregations,” and returning results in real time.

“It really opened a whole wide area of use cases and changed how we think about data,” Amit says. “Because once you take all the ClickHouse knowledge in the world, which we get from working with AI, and combine it with our data, you can achieve marvelous things.”

In one example, the team wanted to detect “impossible travel” events—logins from two distant locations within a short window. Rather than build custom logic, they let Dot try to solve the problem on its own. The agent discovered ClickHouse’s built-in [greatCircleDistance function](https://clickhouse.com/docs/sql-reference/functions/geo/coordinates), which calculates the distance between coordinates. It’s a perfect example of how ClickHouse MCP can open the door to powerful new workflows.

The architecture behind Dot is lightweight and scalable. A supervisor agent interfaces with the UI and routes queries to specialized sub-agents—one for events, one for identities. Each agent uses ClickHouse MCP to issue queries and return results.

“Working with a lot of indexes, like in Postgres, isn’t feasible for AI, since you don’t really know what filter or aggregation the user wants to run, and just guessing isn’t enough,” Bar explains. “You need a real-time analytics engine like ClickHouse with very fast filtering capabilities, because the user isn’t going to stay and watch the chat for 10 minutes.”

The team is now experimenting with multi-agent orchestration, cross-database querying, and even exposing the system through chat apps. As Amit says, “We believe that in the future, most user interactions will not be in the application itself, but within those chat applications.”

## What’s next for DoControl and ClickHouse

With AI use cases expanding and customer demand continuing to grow, the DoControl team is hard at work pushing their infrastructure forward. That includes rolling out [compute-storage separation](https://clickhouse.com/docs/guides/separation-storage-compute) in ClickHouse Cloud, giving them more flexibility to isolate workloads and support high-scale ingestion and querying. “It’s one of the best steps we’ve taken,” Amit says.

Looking ahead, they’re focused on enabling new interfaces, scaling to support more enterprise data, and deepening their AI capabilities. As an engineering-led culture, they’re proud to be early adopters of technologies like the [ClickHouse MCP server](https://clickhouse.com/blog/integrating-clickhouse-mcp).

“We’re always looking for ways to use the most advanced technology to achieve our business needs,” says Itai Birenshtok, DoControl’s VP of Research and Development. “That includes being one of the first companies to use ClickHouse MCP in production.”

The team is always exploring what’s next, always finding ways to combine cutting-edge infrastructure with business value. Whether it’s reducing security risk for customers, ingesting billions of events, or building the next generation of AI-powered assistants, DoControl is all-in on modern, real-time analytics. And ClickHouse is at the heart of it.

Want to see ClickHouse MCP in action?

“We were super excited to start working with ClickHouse. It has been a game-changer in how we serve the world’s largest companies, in a way that no competitive solution can match.”  Amit Fidler, Director of Engineering

large_DoControl User Story Issue 1224.png

medium_DoControl User Story Issue 1224.png

small_DoControl User Story Issue 1224.png

thumbnail_DoControl User Story Issue 1224.png

DoControl User Story Issue 1224.png

How DoControl delivers real-time, AI-driven SaaS security insights with ClickHouse Cloud and MCP

Lovable uses ClickHouse Cloud for observability and AI-powered debugging across millions of AI-generated apps and highly dynamic LLM workflows. ClickHouse MCP lets engineers investigate billions of logs with natural-language prompts, reducing debugging time and keeping development velocity high. ClickHouse also powers real-time analytics for millions of deployed apps, delivering sub-50ms queries with a simple pipeline built by one engineer in a week.

As growth stories go, it’s literally impossible to find one more impressive than [Lovable](https://lovable.dev/)’s. In just eight months after launching, the Swedish startup surpassed $100 million in subscription revenue, making it the [fastest-growing software company in history](https://www.forbes.com/sites/iainmartin/2025/07/23/vibe-coding-turned-this-swedish-ai-unicorn-into-the-fastest-growing-software-startup-ever/).

Their mission is simple but profound: to unlock human creativity by enabling anyone to create software. They do that with an AI-powered platform that lets users build full-stack apps from scratch using nothing more than natural-language prompts.

Today, more than 8 million people use the platform. Together they create over 100,000 projects and ship around 25,000 apps into production every day. The company recently crossed 3 million deployed apps, and that number is climbing fast. As technical staff member Tomas Nordström puts it, “This means we definitely need better observability.”

At our [Open House Roadshow in Amsterdam](https://clickhouse.com/openhouse/amsterdam), Tomas shared how Lovable uses [ClickHouse Cloud](https://clickhouse.com/cloud) to keep up with a system that evolves by the minute, including how engineers debug unpredictable AI behavior with [ClickHouse MCP](https://clickhouse.com/blog/integrating-clickhouse-mcp). He also walked through how Lovable powers web analytics for all of its deployed apps, and where the team is expanding next.

## Use case #1: Observability at scale

Lovable runs a deeply distributed, AI-powered system built from multiple distributed services that power millions of published apps. Every new project triggers a chain of internal API calls, external integrations, and LLM-driven actions. The result is a “very non-deterministic system,” Tomas says, in which understanding system behavior is uniquely challenging. 

“We have a lot of APIs that we’re exposing internally, and then we’re also communicating with a lot of APIs externally as well,” he adds. “It’s quite a stochastic system.”

To make sense of all that activity, the team built a full OpenTelemetry pipeline that streams directly into ClickHouse. Logs and traces from the Go API backend, Cloudflare Workers, their sandbox environment, Temporal workflows, and Kubernetes clusters all land in one unified ClickHouse schema. From there, the team visualizes everything in Grafana, creating a real-time view of how traffic moves across every endpoint—“both the ones we’re exposing,” Tomas says, “and also all of the endpoints we’re communicating with externally.”

ClickHouse gives them the high-volume write throughput they need, plus fast queries across billions of events. And because ClickHouse’s schema model is flexible, the team can evolve their observability pipelines as new services, new models, and new workflows come online, without slowing down development.

## Use case #2: AI-powered debugging

But even with full visibility into their microservices, Lovable still needed a way to understand what happens *between* those services—inside the LLM-driven logic that can change from one request to the next. When an outgoing request fails or behaves strangely, the root cause often lives in a chain of model-driven tool calls that didn’t exist a few minutes earlier. As Tomas puts it, “People are using Lovable in very weird ways that we weren’t expecting.” Those edge cases can be incredibly difficult to trace through billions of log entries.

This is where the [ClickHouse MCP server](https://clickhouse.com/blog/integrating-clickhouse-mcp) has been a “game-changer,” Tomas says. With 20-25 engineers supporting more than 8 million users, Lovable can’t rely on everyone being a SQL expert capable of querying hundreds of billions of log rows during an incident. MCP removes that barrier. Engineers simply describe the issue, and MCP fetches the right traces, recent Git commits, and the current log schema, with no SQL required. 

“MCP has really been the best help we could ask for,” Tomas says. “It’s one of the main use cases where we’ve been sticking to ClickHouse and started falling in love with it.”

## Use case #3: Analytics for 3 million apps

As more people began deploying apps with Lovable, another need emerged: giving users visibility into how their apps were performing in the real world. With millions of deployed apps and usage patterns ranging “from one visit to several million visits per day,” the team needed an analytics layer that could handle extreme multi-tenancy at scale.

After a quick conversation with the ClickHouse team, the solution was clear. “We understood, this is actually a great use case for just building this with ClickHouse,” Tomas says.

Today, every time an app renders an HTML page, a lightweight event is sent via Cloudflare Workers straight into ClickHouse. A small service built around four tables and four [materialized views](https://clickhouse.com/docs/materialized-views) handles the rest, powering real-time dashboards that track visitors, page views, sessions, bounce rates, referrers, devices, and more.

Despite the diversity in traffic, the system is fast and effortless to operate, with queries returning in 50 or so milliseconds. Just as impressive, the pipeline was “created by one engineer in one week,” Tomas says. “It was so easy and really a no-brainer to set up.”

## Use case #4: More ClickHouse applications

Lovable has continued to expand its ClickHouse usage with new features that benefit from its speed, reliability, and low operational overhead. “There’s a lot of use cases where we can continue using ClickHouse,” Tomas says.

A recent example is [Lovable Cloud](https://lovable.dev/cloud), the company’s native backend hosting environment. It came with a new AI gateway that tracks every LLM call—models, tokens, latency, cost—to support usage-based billing. Since the team already knew how to structure, materialize, and aggregate data efficiently in ClickHouse, Tomas says integrating it with the gateway was a natural fit.

Security scanning is another new application, driven by the rise of “vibe coding” and security concerns around the apps it produces. “We’ve taken a responsibility to make sure we try our absolute best to make these apps as secure as possible,” he says. Lovable now scans all deployed apps daily for leaked secrets, permission issues, and other vulnerabilities. Any findings are logged into ClickHouse, materialized, and re-checked every hour via [refreshable materialized views](https://clickhouse.com/docs/materialized-view/refreshable-materialized-view) to determine whether users should be alerted.

## Why ClickHouse matters for Lovable

Lovable’s vision of democratizing software comes with a second goal: democratizing the infrastructure behind it. As Tomas puts it, “We want to be able to move really, really fast—and we want to allow our users to move really, really fast as well.”

Part of that, he says, is exposing ClickHouse more and more to Lovable’s users. “You have a lot of options when using ClickHouse, but you can also take, in a sense, a lot of shortcuts as well. You don’t have to be a database expert.” With the right abstractions, both humans and AI can explore data, ask questions, and understand what’s happening without needing to understand every detail of the underlying schema.

That flexibility matters inside the company, too. With more than 200 commits landing in production each day, engineers need quick answers when something looks off. ClickHouse gives them that speed. Instead of digging through opaque logging pipelines, anyone on the team can jump into ClickHouse and instantly see how a change is behaving in the wild, without having to be a SQL expert. It shortens feedback loops, reduces operational drag, and keeps development velocity high.

Tomas closed his talk with a few words from Lovable itself: “At Lovable, we're making it possible for anyone to build software. ClickHouse makes it possible for anyone—human or AI—to understand and analyze that software at scale.”

Ready to scale your team’s data operations?

“At Lovable, we're making it possible for anyone to build software. ClickHouse makes it possible for anyone—human or AI—to understand and analyze that software at scale.”  Tomas Nordström, Member of Technical Staff

large_Lovable User Story Issue 1222.png

medium_Lovable User Story Issue 1222.png

small_Lovable User Story Issue 1222.png

thumbnail_Lovable User Story Issue 1222.png

Lovable User Story Issue 1222.png

Lovable <3 ClickHouse: AI-powered observability and analytics at the world’s fastest-growing software company

If you build software at scale, there’s a good chance you already know [Buildkite](http://Buildkite). The company's CI/CD platform sits behind the pipelines of engineering organizations like Slack, Reddit, Canva, Airbnb, Shopify, and Uber. Teams use it to ship code confidently, coordinate complex CI flows, and even orchestrate AI model-training workloads.

Within that platform, Buildkite Test Engine helps teams speed up builds by understanding their test suite. It aggregates results from thousands of builds, flags flaky tests, and splits large suites across fleets of machines. As staff software engineer Gordon Chan puts it, “That’s a lot of data that we have to store and present back to customers in a UI and dashboard.”

This year, at ClickHouse meetups in [Wellington](https://clickhouse.com/videos/wellington-meetup-buildkite-clickhouse-test-analytics) and [Melbourne](https://clickhouse.com/videos/melbourne-meetup-buildkite-20sep25), Gordon told the story of how Test Engine went from a simple Rails app to a streaming architecture—and why the team ultimately reached for [ClickHouse Cloud](https://clickhouse.com/cloud) to power customer-facing analytics.

## From Rails app to streaming overload

Test Engine first launched with a traditional architecture using Ruby on Rails backed by Postgres. “It was great at the time, just to get started,” Gordon says. “But as more customers wanted to use the product, we realized the architecture couldn’t serve information at the speed and scale required by our customers. We needed to scale the platform.”

So in 2024, over six months, the team re-architected ingestion, introducing Kafka to propagate test events and Flink to handful stateful processing and pre-aggregations. Data flowed into multiple stores: Postgres for some aggregates, DynamoDB for fast key-value lookups, and Iceberg tables in S3 queried via Athena (and later Trino) for flexible analysis. For a while, it looked like a success. “We unlocked the platform for large enterprise customers,” Gordon says. “They could onboard onto Test Engine, and everyone was happy.”

But as customers saw what was possible, they wanted more. “Our customers had a really strong demand to leverage the data in a way that’s intuitive to them,” Gordon says. They wanted to tag each test execution with arbitrary metadata—instance type, architecture, language version, cloud provider, feature flag—and then slice, dice, and group on the fly.

The existing tools weren’t built for that level of interactive, high-cardinality analytics. Flink was great for “rule-based actions” like detecting flaky tests, but “not very good for aggregations across lots of arbitrary user-specified tags.” DynamoDB was “good for fast retrieval of individual records, but not really capable of doing real-time analytics.” Iceberg plus Athena or Trino offered flexible querying, but it wasn’t nearly fast enough. And Kafka, Gordon says, was “never designed for the type of querying or aggregation we wanted to do.” 

In short, Test Engine had the data, but not the interactive analytics experience customers were asking for. The team knew they needed a different kind of engine.

## Why ClickHouse Cloud was the perfect fit

By late 2024, Buildkite was on the hunt for a “magical database for tagging”—a system that could power real-time analytics across billions of test executions without relying on heavy pre-aggregations. While they evaluated several OLAP options, including Apache Druid and Pinot, it didn’t take long for ClickHouse to emerge as the best fit.

The first reason was obvious: “ClickHouse is blazingly fast,” Gordon says. Beyond that, they wanted something highly available, battle-tested, and capable of scaling without too much maintenance. ClickHouse checked all those boxes. Gordon had watched talks by ClickHouse creator Alexey Milovidov and came away “really impressed” with his bottom-up, hardware-aware approach. That reinforced what he was hearing from “friends and other companies in the industry, who all had good things to say about ClickHouse.”

Another big draw was how easy it was to get started. It took minutes for the team to download the binary, run it locally, and push a sample of production data through. “It was really easy for us to test this locally and actually prove it was really fast, really quickly,” Gordon recalls. ClickHouse’s [SQL compatibility](https://clickhouse.com/docs/sql-reference) contributed to that developer-friendliness. “It made it very familiar and easy for our engineers who are not data engineers to use it.”

ClickHouse’s new [JSON data type](https://clickhouse.com/docs/sql-reference/data-types/newjson) sealed the deal. Test Engine’s vision depended on arbitrary tags: customers should be able to attach whatever metadata they care about and query it efficiently. “The ability to just send metadata into this JSON data type and then have ClickHouse create individual columns for each key was amazing,” Gordon says.

After validating ClickHouse locally, the team spun up a self-hosted instance in AWS and even built a ClickHouse-backed prototype for AWS re:Invent. “Our customers were pretty excited, so we had to look at productionizing that solution,” Gordon says. That pushed them to think about how much operational overhead they wanted to take on. “We didn’t want to do a lot of database operations,” he explains. “We don’t want to worry about updates, patching, scaling. And so [ClickHouse Cloud](https://clickhouse.com/cloud) was a good solution.”

They connected with the ClickHouse team in December, and a month later, after getting the green light from legal, risk, and finance, they became a paying customer. From there, the team quickly moved from prototyping to rolling out their first ClickHouse-powered features—marking the start of a transformation in how Test Engine handled analytics.

## Six months later: From pilot to production

The first production use case was narrow but powerful: enable real-time analytics over tagged test events without relying on pre-computed reports. With ClickHouse Cloud, customers could do things like group P50 test durations by instance type, architecture, or cloud provider and identify patterns like “this newer VM family runs 25% faster for the same price.” 

“We were amazed by the query performance,” Gordon says. “That success gave us confidence to shift more of our workloads to ClickHouse, to unlock more analytical capability for our customers, and to bring more consistency to our back end.”

By the time of [Gordon’s Melbourne talk in September 2025](https://clickhouse.com/videos/melbourne-meetup-buildkite-20sep25), ClickHouse had become the analytical backbone of Test Engine’s operation, replacing a patchwork of pre-aggregations and storage systems with a single, real-time analytics layer.

![Buildkite User Story Issue 1214.jpg](/uploads/Buildkite_User_Story_Issue_1214_a6c8e7b420.jpg)

Test results flow from customer CI/CD pipelines into ClickHouse Cloud for real-time analytics.

In the current setup, customers send test results from their CI/CD pipelines, Kafka buffers and propagates those events, Flink handles stateful processing, and the majority of that data lands in ClickHouse Cloud. The Test Engine UI still runs inside Buildkite’s monolithic Ruby on Rails application backed by Postgres, but almost every analytical query now targets ClickHouse.

The numbers tell the story. When Gordon first spoke in February, Test Engine was ingesting around 3 billion test executions per month. Six months later, that had quadrupled to 12 billion, with sustained peaks above 25,000 events per second. “At the moment, we have about 70 billion records in ClickHouse, and that’s just since the beginning of this year,” he says, noting they haven’t even needed [TTL-based pruning](https://clickhouse.com/docs/guides/developer/ttl) yet.

Importantly, ClickHouse handles both sides of the equation. On the write path, ingesting 25,000 events per second into Postgres was “just not possible really, unless you did a lot of tuning,” Gordon says. “With ClickHouse, it was pretty easy.” 

On the read path, ClickHouse Cloud distributes queries across multiple nodes—“so things can scale when needed,” he says. “And if we find that customers want more complexity, we have more tools to optimize read performance—things like [choosing the correct primary key](https://clickhouse.com/docs/best-practices/choosing-a-primary-key), using [materialized views](https://clickhouse.com/docs/materialized-views), using [skipping indexes](https://clickhouse.com/docs/optimize/skipping-indexes), stuff like that.”

## A healthier cost sheet and happier customers

For Buildkite, ClickHouse’s impact has been massive. As Gordon puts it, “Shifting workloads to ClickHouse Cloud has simplified our backend systems and reduced costs, unlocked more possibilities for analytics, and enabled the team to rapidly deliver new functionality.”

He shared screenshots from a team Slack channel called \#social-salmon, where engineers celebrate GitHub pull requests with more red (deleted) lines than green. As workloads moved to ClickHouse, that channel lit up. “The code base is healthier for it,” Gordon says.

Previously, Flink jobs ran around the clock, pre-aggregating metrics like daily test duration for every test in existence and syncing them into DynamoDB, Postgres, and Iceberg tables, with Kafka topics and ETL glue in between. “This was quite expensive, and it ran constantly, regardless of whether customers needed that data or not,” Gordon says.

Today, much of that machinery is gone. Test splitting data, flaky test analytics, build-level insights, and general search and filtering now run as on-demand queries against ClickHouse. “It was actually really satisfying to tear down the old implementation,” Gordon says. “We deleted a lot of code, dropped many Postgres tables, deleted a lot of Kafka topics, retired a lot of jobs, and managed to completely retire our usage of DynamoDB.”

![image2.png](/uploads/image2_917cd801ae.png)

Buildkite engineers celebrate code deletions as workloads shift to ClickHouse Cloud.

Financially, the impact has been just as huge. Over the same period that event volume quadrupled, Test Engine’s net infrastructure spend dropped by five figures per month. According to Gordon’s napkin math, for every dollar spent on ClickHouse, the team is saving eight dollars elsewhere—“a 1:8 ratio,” as he puts it. Most of that came from scaling down Flink workloads by more than 60%, retiring DynamoDB, and cutting Aurora Postgres capacity in half.

“Thanks to ClickHouse Cloud, we’re doing way more with less, and delivering greater tool capabilities to our customers than ever before,” Gordon says.

That last point about customers is what matters most. The teams who rely on Test Engine now get more speed, more flexibility, and far more control. “ClickHouse has enabled us to deliver on-demand, real-time analytics to our customers, who can now leverage data in ways that are intuitive to them, without having to rely on canned reports,” Gordon says. “It’s given them the freedom to slice and dice the data as needed.”

## Built for speed, designed with sympathy

Gordon closed his Melbourne talk with a quote from racing legend Jackie Stewart: “You don’t have to be an engineer to be a racing driver, but you do have to have mechanical sympathy.”

For Buildkite and the Test Engine team, ClickHouse rewards that kind of sympathy. It’s fast enough to keep up with world-class engineering teams, flexible enough to express the questions they actually want to ask, and simple enough that a small product team can operate it without becoming full-time database admins.

“Migrating to ClickHouse has simplified our tech stack, reduced costs, and unlocked way more capabilities and possibilities,” Gordon says. “Our customers are delighted with the new features we’ve delivered recently and the accelerated delivery speed of those features.” 

At the end of the day, as Gordon puts it, “It’s all about helping teams build and deploy as fast as they can.”

“Shifting workloads to ClickHouse Cloud has simplified our backend systems and reduced costs, unlocked more possibilities for analytics, and enabled the team to rapidly deliver new functionality.”  Gordon Chan, Staff Software Engineer

ClickHouse

Blog posts by ClickHouse

How Silverflow simplified its data platform and cut end-to-end latency by 95% with ClickHouse Cloud

How Langfuse is scaling LLM observability for the agentic era with ClickHouse Cloud

ClickHouse 日本法人代表取締役社長に金古毅氏が就任

How DoControl delivers real-time, AI-driven SaaS security insights with ClickHouse Cloud and MCP

Lovable <3 ClickHouse: AI-powered observability and analytics at the world’s fastest-growing software company

How Buildkite transformed test analytics and cut costs with ClickHouse Cloud

ClickHouse

Blog posts by ClickHouse

How Silverflow simplified its data platform and cut end-to-end latency by 95% with ClickHouse Cloud

How Langfuse is scaling LLM observability for the agentic era with ClickHouse Cloud

ClickHouse 日本法人 代表取締役社長に 金古 毅 氏が就任

How DoControl delivers real-time, AI-driven SaaS security insights with ClickHouse Cloud and MCP

Lovable <3 ClickHouse: AI-powered observability and analytics at the world’s fastest-growing software company

How Buildkite transformed test analytics and cut costs with ClickHouse Cloud

ClickHouse 日本法人代表取締役社長に金古毅氏が就任