Google Cloud Next is one of the biggest moments in the cloud calendar, and this year ClickHouse made a splash. Not just with a booth, house party and some swag, but a wave of product launches, integrations, and a deepening partnership with Google Cloud.

![image1.jpeg](/uploads/image1_5f14217c2a.jpeg)

This post rounds up our biggest announcements and supporting launches that make ClickHouse a more native part of the Google Cloud ecosystem.

## ClickHouse Cloud on Google Axion {#clickhouse_cloud_on_google_axion}

Google Axion is Google's first custom ARM-based processor, built on ARM Neoverse V2 and offered through the C4A instance family. It represents a meaningful strategic investment from Google in custom silicon designed specifically for cloud-native workloads, with higher memory bandwidth and better performance per watt than comparable x86 offerings.

ClickHouse turns out to be a particularly good match for Axion. ClickHouse is built to push hardware as much as possible, and Axion instances don't flinch under that pressure. Where traditional processors can slow down when queries get heavy and sustained, Axion keeps consistent performance throughout. The result is that the speed gains compound in exactly the workloads where you need them most. The numbers bear this out. In our benchmark run in March 2026, ClickHouse Cloud on Axion took the #1 spot on [ClickBench](https://benchmark.clickhouse.com/) ranking across all systems and configurations. We saw 30-55% faster query performance and data load times cut roughly in half, from 64 seconds down to 26.

The migration to Axion is ongoing and will be transparent for existing customers. For the full technical breakdown, read the [dedicated Axion blog post](https://clickhouse.com/blog/google-axion).

## Query Google Cloud Lakehouse directly from ClickHouse {#query_google_cloud_lakehouse_directly_from_clickhouse}

The second major co-announcement at Google Next is our Lakehouse Runtime Catalog integration. Lakehouse Runtime Catalog is Google's unified metadata layer for Iceberg tables stored in Google Cloud Storage. With ClickHouse's new native integration, you can point ClickHouse directly at your Iceberg tables managed by Google's Lakehouse Runtime Catalog and query them as if they were native ClickHouse tables. No data movement, no duplication, no ETL pipeline to maintain.

Google is making sustained investments in GCS as an open data platform. Iceberg, Dataplex, and Lakehouse are the layers being built on top of it. ClickHouse's native support for this stack means you can use the right tool for the right job. Lakehouse Runtime Catalog for catalog management and governance, ClickHouse for fast, real-time analytical queries.

The integration uses ClickHouse's DataLakeCatalog engine with `catalog_type='biglake'`. You connect to the Lakehouse Runtime Catalog, and ClickHouse handles schema discovery automatically from the catalog.

You can learn more about the integration in our [dedicated blog post](https://clickhouse.com/blog/google-lakehouse-runtime).

## BYOC on the Google Cloud Marketplace {#byoc_on_the_google_cloud_marketplace}

For enterprise teams with specific data residency requirements, compliance constraints, or a strong preference for keeping compute inside their own GCP account, Bring Your Own Cloud (BYOC) is now generally available on the Google Cloud Marketplace.

BYOC lets you run ClickHouse's managed service while keeping your data and compute entirely within your own GCP account. ClickHouse manages the control plane, and you own the data plane. For many enterprise customers or organizations with hard data residency requirements, this is the preferred choice of deployment, and it's now available through the Marketplace. Which means you can apply existing GCP committed spend toward ClickHouse BYOC.

If your team has been evaluating ClickHouse Cloud on GCP but needed BYOC as a prerequisite to move forward, sign up on the Marketplace and learn more about this release in our [dedicated blog post](https://clickhouse.com/blog/byoc-gcp-ga).

## ClickHouse support for Google Antigravity {#clickhouse_support_for_google_antigravity}

Google Antigravity, Google's AI-native IDE, now has support for ClickHouse through its MCP server. This is part of ClickHouse's broader investment in the [Agentic Data Stack](https://clickhouse.com/ai).

Once connected via OAuth, you never have to orient yourself in your own data again. The agent automatically discovers your organizations, services, databases, and tables. You can ask natural language questions against massive data sets and get answers at ClickHouse speeds. The agent translates your intent into ClickHouse SQL, executes it, and returns structured results in the same conversation.

Going beyond chat, Antigravity generates interactive React-based charts as Artifacts, rendered live in the IDE's integrated browser. When you want to dig deeper into something you see in a chart, you can drag a box over it, leave a comment, and the agent responds to that visual context, queries ClickHouse again, and updates the Artifact in place.

This integration makes it really simple to embed a scalable real-time analytics solution inside your application. We're excited to see what (and how) our community builds with our new native integration for Antigravity. For the full walkthrough, read the [dedicated Antigravity blog post](https://clickhouse.com/blog/google-antigravity).

## GCS ClickPipes support for unordered mode {#gcs_clickpipes_support_for_unordered_mode}

We recently shipped support for unordered mode for our customers running large-scale data pipelines on Google Cloud Storage.

Our original GCS ClickPipes connector required files to arrive in lexicographical order. If you had a backfill, a retry, or late-arriving data with a filename that sorted earlier than already-processed files, those files would be silently skipped. For production pipelines, this is the kind of thing that can impact data quality.

Unordered mode eliminates that constraint entirely. Instead of polling the bucket every 30 seconds and looking for the next file in sequence, ClickPipes now listens for `OBJECT_FINALIZE` Pub/Sub notifications from GCS and processes any new file the moment it lands regardless of its name or order. Exactly-once semantics are guaranteed through a metadata store that tracks processing state across systems, so you don't have to worry about duplicates either.

You can read more about GCS in unordered mode in our [dedicated blog](https://clickhouse.com/blog/clickpipes-gcs-unordered-mode).

## What's coming next {#whats_coming_next}

We're just getting started and our partnership with Google Cloud is only getting stronger. Here's what you can expect later this year.

### Pub/Sub to ClickHouse Dataflow Template

For teams already running Pub/Sub pipelines, we're finalizing a new Dataflow template that brings ClickHouse in as a managed streaming destination. Built in collaboration with the Google Cloud team, it includes flexible windowing, dual dead-letter routing, and configurable write tuning so nothing gets silently dropped. This should be available very soon, stay tuned.

### ClickHouse Sink for Dataflow Job Builder

We're adding official Beam YAML support and a ClickHouse sink to Google's Dataflow Job Builder. Once available, you'll be able to visually assemble a pipeline in the Dataflow console and connect ClickHouse as the destination to any source you're already using. That includes GCP-native sources like BigQuery, GCS, Pub/Sub, and Spanner, or external sources like MySQL, Oracle, and Iceberg. View the [full list of supported sources](https://beam.apache.org/releases/yamldoc/current/).

### BigQuery CDC for ClickPipes

Earlier this year, we announced our [BigQuery ClickPipes in Private Preview](https://clickhouse.com/blog/bigquery-clickpipe-private-preview). Demand has been high, and we're looking to continue investing in this ClickPipe by providing Change Data Capture replication to ClickHouse. This will be a fully managed ClickPipes that captures changes from BigQuery tables in near real-time and lands them in ClickHouse. The same CDC experience we already offer for Postgres, MySQL, and MongoDB, extended to Google's flagship data warehouse.

### Google Cloud Pub/Sub ClickPipes

In addition to the Dataflow template, we're building a native Pub/Sub connector directly in ClickPipes. The Dataflow template and the ClickPipes serve different audiences: Dataflow gives you more control over windowing, transformations, and error routing, while the ClickPipes connector will offer a simpler, fully managed experience for teams that want ingestion from Pub/Sub to be as easy as any other ClickPipes.

### Private Service Connect for ClickPipes on Google Cloud

Many of our customers run their entire production workloads on GCP. For those that do, Private Service Connect has been a highly requested solution for secure, private connectivity between GCP-hosted data sources and ClickPipes. We're excited to be working on this solution and can't wait to make it available for our joint customers.

### Managed Postgres on GCP

Earlier this year, we [launched a managed Postgres service](https://clickhouse.com/blog/postgres-managed-by-clickhouse) in private preview around a simple idea: Postgres and ClickHouse are better together. NVMe-backed Postgres handles your transactions, ClickHouse handles your analytics, and native CDC replication keeps the two in sync in real time. We're excited to share that we're working on the infrastructure to support expansion into GCP later this year.

## Wrap-up {#wrap_up}

Beyond the product announcements, Google Cloud Next was a blast this year. It was amazing connecting with the broader Google community, getting face time with our customers, and letting loose at our [House Party with the Chainsmokers](https://clickhouse.com/houseparty/google-next). If you were there, you know. If you weren't, we can't wait to see you next year.

The conversations we had on the floor this week confirmed what we've been building toward. The way the data ecosystem is evolving, there's a real appetite for fast, open analytics deeply integrated into the Google Cloud ecosystem.


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

Google Cloud Next is one of the biggest moments in the cloud calendar, and this year ClickHouse made a splash. Not just with a booth, house party and some swag, but a wave of product launches, integrations, and a deepening partnership with Google Cloud.

large_Google Cloud Next Blog Banner 26.jpg

medium_Google Cloud Next Blog Banner 26.jpg

small_Google Cloud Next Blog Banner 26.jpg

thumbnail_Google Cloud Next Blog Banner 26.jpg

Google Cloud Next Blog Banner 26.jpg

ClickHouse at Google Cloud Next '26

## ～国内企業のリアルタイムデータ活用を加速させる、パートナーエコシステムを構築～

AI時代のリアルタイムデータプラットフォームのリーディングカンパニーであるClickHouse株式会社（本社：東京都港区、代表取締役社長：金古 毅、以下ClickHouse）は、パートナー企業との連携を強化し、顧客への最適なソリューション提供を目的とした新しいグローバルパートナープログラム「House Mates」を発表いたしました。本プログラムは、本日より日本国内のパートナー企業に対しても正式に適用を開始いたします。

![Japan Press Release_Partner Program_27Apr26.png](https://cms-new.clickhouse.com/uploads/Japan_Press_Release_Partner_Program_27_Apr26_04c24a1447.png)

## ■ パートナープログラム「House Mates」提供の背景

AIおよび機械学習の導入が加速する中、リアルタイムなデータインフラストラクチャへの需要はかつてないほど高まっています。ClickHouseは、その業界をリードする処理速度と効率性により、AIアプリケーションを支えるデータプラットフォームとして世界中で採用されています。

この度提供を開始したパートナープログラム「House Mates」は、ClickHouseを活用してAIソリューションやデータ分析基盤を構築・提供する、国内パートナー企業の卓越した技術力を評価し、そのさらなる成長を強力に支援するために設計されました。

## ■ ClickHouse株式会社 代表取締役社長 金古 毅からのコメント

「日本市場においてClickHouseのビジョンを実現し、真にお客様のビジネス価値に貢献するためには、強力なパートナーエコシステムの構築が不可欠であると確信しています。各領域で深い専門性と知見をお持ちのパートナー様は、ClickHouseにとって単なる協力者ではなく、共に市場を切り拓く『House Mates（同じ家で過ごす仲間）』です。

日本企業のAI実装が加速する今、データの処理速度と効率性は競争力の源泉となります。本プログラムを通じて、パートナーの皆様と共に、AI時代のリアルタイム分析データ基盤であるClickHouseの圧倒的なパフォーマンスを日本中へ届け、次世代のデータ活用を牽引していくことを心から楽しみにしています。」

![Japan Press Release_Partner Program image 2_27Apr26.png](https://cms-new.clickhouse.com/uploads/Japan_Press_Release_Partner_Program_image_2_27_Apr26_1092a09906.png)

## ■ パートナータイプ

本プログラムでは、パートナー企業のビジネスモデルに合わせた複数のタイプを用意しています。

- サービスパートナー： ClickHouseの導入支援、コンサルティング、および移行サービスを提供するパートナー。
- チャネルパートナー： ClickHouse製品の再販（リセール）を行うパートナー。
- テクノロジーパートナー（近日適用予定）： AIプラットフォームやETLツールなどを展開し、ClickHouseとの統合、またはClickHouseを基盤とした製品開発を行う独立系ソフトウェアベンダー（ISV）。

## ■ ClickHouseが提供するパートナー向け支援

パートナー企業が迅速にビジネスを展開できるよう、以下の包括的な支援を提供します。

- ClickHouse Academy: AIコンテクストでのデータ活用を含む、最新のトレーニングと認定資格を提供します。
- 共同マーケティング: 日本国内のAI・データ活用市場に向けた共同キャンペーンや販促資産を提供します。
- 技術・ビジネス支援: ClickHouse Cloudのクレジット提供や、AIアプリケーション構築に最適化された技術支援を実施します。

## ■ パートナーシップを支える3つの認定ティア

パートナー企業の習熟度や実績に応じて、「Prime（プライム）」「Accelerate（アクセラレート）」「Ignite（イグナイト）」の3段階のティア（階層）を設定しています。上位ティアでは、日本市場向けの共同マーケティング支援や、AIソリューション開発に特化した技術サポート等の特典を受けることが可能です。

## ■ ClickHouseについて

ClickHouseは、リアルタイムデータ処理および分析のために設計された、高速なオープンソースのカラム型データベース管理システムです。高いパフォーマンスを実現するよう設計されたClickHouse Cloudは、卓越したクエリ速度と高い同時実行性能を提供し、膨大なデータ量から即座に洞察を得ることが求められるアプリケーションに最適です。

AIエージェントがソフトウェアにますます組み込まれ、これまでよりもはるかに頻繁かつ複雑なクエリを生成するようになる中で、ClickHouseは、こうした課題に対応するために特別に設計された、高スループットかつ低レイテンシのエンジンを提供します。Sony、Tesla、Lyft、Instacartといった業界を代表する企業から信頼されているClickHouseは、スケーラブルで効率的、かつモダンなデータプラットフォームを通じて、チームが洞察を引き出し、より賢明な意思決定を行うことを支援します。

詳細はこちら： https://clickhouse.com/jp<br>
SNS公式アカウント： [LinkedIn](https://www.linkedin.com/company/clickhouse-jp/) / [X](https://x.com/ClickHouseJapan) / [Facebook](https://www.facebook.com/ClickHouseJP)

～国内企業のリアルタイムデータ活用を加速させる、パートナーエコシステムを構築～

small_Japan Press Release_Partner Program_27Apr26.png

thumbnail_Japan Press Release_Partner Program_27Apr26.png

Japan Press Release_Partner Program_27Apr26.png

AI時代のリアルタイムデータプラットフォームClickHouse、新パートナープログラム「House Mates」を日本国内で提供開始

## 世界最高速レベルのデータプラットフォームとAIエージェント運用監視を統合、次世代のAIデータスタックを構築

AI時代のリアルタイムデータプラットフォームのリーディングカンパニーであるClickHouse株式会社（本社：東京都港区、代表取締役社長：金古 毅）は、AIアプリケーションの開発と改善に特化し、リアルタイムでアプリケーションの品質管理やコスト評価するプラットフォーム「Langfuse（ラングフューズ）」の日本国内（AWS 東京リージョン）における正式提供およびサポートを開始することをお知らせいたします。

![ClickHouse + Langfuse.png](https://cms-new.clickhouse.com/uploads/Click_House_Langfuse_7bc64d1a12.png)

## ■ 背景：AIエージェントの「思考プロセス」を可視化する
AIエージェントやLLM（大規模言語モデル）を活用したシステムが急速に普及する中、企業には「AIがなぜその回答やアクションを生成したのか」というプロセスを把握し、信頼性を担保することが求められています。
AIエージェントは、人間が気づかないうちに裏側で膨大なステップ（推論）を繰り返します。ミリ秒単位で複雑なデータの記録・分析が可能な ClickHouse の高速データベースと、Langfuse の深いオブザーバビリティ（可観測性）および評価機能を統合することで、日本の企業が品質やコスト効率を犠牲にすることなくAIプロダクトをスケールさせるための堅牢な環境を提供します。

## ■ Langfuseとは：AIの「運用監視」と「品質改善」を実現
Langfuseは、AIの実行時における内部メカニズムを記録・評価するために設計されたツールです。

- AIアプリケーションの実行を可視化: AIが回答にたどり着くまでのすべてのステップを記録します。開発者はボトルネックやエラーを即座に特定でき、デバッグ作業を大幅に効率化できます。
- リアルタイム評価: AIの回答をスコアリングし、品質基準を満たしているか確認します。プロンプトの最適化などを通じて、データに基づいた継続的な改善が可能になります。
- コストの最適化: トークン使用量をリアルタイムで追跡します。最高のパフォーマンスを維持しながら、運用コストを最小限に抑えるための管理を支援します。

## ■ ClickHouseの役割：Langfuseを支える世界最速のデータプラットフォーム
Langfuseは、1秒間に数億行ものデータを処理できる世界最速のリアルタイムデータプラットフォーム、ClickHouse 上で動作します。これにより、以下の機能が支えられています。

- AIログの即時分析: AIエージェントが生成する膨大な実行記録（トレースデータ）を難なく取り込み、即座に実用的なインサイト（洞察）へと変換します。
- 統合されたベクトル検索: RAG（検索拡張生成）に必要なデータ検索をサポートしています。これにより、企業は「AIの記憶（ベクトル）」と「モニタリング（評価）」を単一のシステムに統合することが可能です。
- 世界トップクラスの実績: Sony、Tesla、Lyftといった業界のリーダーたちから、モダンなデータプラットフォームとして信頼されています。

## AIアプリケーション開発を支える「3つの柱」
Langfuseの正式提供により、ClickHouseはAI開発におけるモダンなエコシステムを完成させました。

- データプラットフォーム（ClickHouse）: AIの実行ログやベクトルデータをミリ秒単位の低遅延で処理する、超高速な基盤を提供します。
- UI/UX（LibreChat）: ユーザーとAIが対話するための、洗練された柔軟なインターフェースを担います。
- AIオブザーバビリティ（Langfuse）: AIの推論プロセスの詳細な記録と、リアルタイムな評価を実現します。

これらを組み合わせることで、フロントエンドのインターフェースからバックエンドのデータ分析まで、一気通貫した「AI特化型の包括的なデータスタック」を構築することが可能になりました。

## ■ ClickHouse株式会社 代表取締役社長 金古 毅のコメント
「AIエージェントをビジネスで実用化するには、AIの動きを透明化し、常に改善できる仕組みが不可欠です。世界最高速の分析エンジンClickHouseと、AIオブザーバビリティの標準であるLangfuseを日本で提供することで、企業が安心してAIをビジネスの核に据えられるよう、強力に支援してまいります。」

## ■ ClickHouseについて
ClickHouseは、リアルタイムデータ処理および分析のために設計された、高速なオープンソースのカラム型データベース管理システムです。高いパフォーマンスを実現するよう設計されたClickHouse Cloudは、卓越したクエリ速度と高い同時実行性能を提供し、膨大なデータ量から即座に洞察を得ることが求められるアプリケーションに最適です。

AIエージェントがソフトウェアにますます組み込まれ、これまでよりもはるかに頻繁かつ複雑なクエリを生成するようになる中で、ClickHouseは、こうした課題に対応するために特別に設計された、高スループットかつ低レイテンシのエンジンを提供します。Sony、Tesla、Lyft、Instacartといった業界を代表する企業から信頼されているClickHouseは、スケーラブルで効率的、かつモダンなデータプラットフォームを通じて、チームが洞察を引き出し、より賢明な意思決定を行うことを支援します。

- 詳細はこちら： https://clickhouse.com/jp
- SNS公式アカウント： [LinkedIn](https://www.linkedin.com/company/clickhouse-jp/) / [X](https://x.com/ClickHouseJapan) / [Facebook](https://www.facebook.com/ClickHouseJP/) (ClickHouse Japan)

【本件に関するお問い合わせ先】 
ClickHouse株式会社<br>
広報担当：橋本<br>
Email: tomoko.hashimoto@japan.clickhouse.com

世界最高速レベルのデータプラットフォームとAIエージェント運用監視を統合、次世代のAIデータスタックを構築

large_ClickHouse + Langfuse.png

medium_ClickHouse + Langfuse.png

small_ClickHouse + Langfuse.png

thumbnail_ClickHouse + Langfuse.png

ClickHouse + Langfuse.png

ClickHouse、国内でAIオブザーバビリティプラットフォーム「Langfuse」を正式提供開始

We are migrating our Google Cloud fleet to Axion C4A instances. The results: 30–55% faster ClickBench queries and \~15% fewer compute credits across production workloads

Summary


## **Why Axion, and why now** {#why_axion_and_why_now}

The C4A instance family, powered by Google Axion processors, offers higher memory bandwidth, and better performance per watt compared to general-purpose x86 instances. 

There was also a concrete operational reason. Several of our largest Google Cloud customers were hitting the performance ceiling of their existing nodes. One customer in particular was experiencing persistent CPU throttling and the lack of capacity under peak query load. Axion gave us a concrete path forward with faster compute and [local SSDs](https://cloud.google.com/blog/products/compute/first-google-axion-processor-c4a-now-ga-with-titanium-ssd).  


## **ClickBench results: Google Cloud takes first place** {#clickbench_results_google_cloud_takes_first_place}

[ClickBench](https://benchmark.clickhouse.com/) is our open, reproducible benchmark for analytical query performance. It uses a production-derived, anonymized web analytics dataset with 100 million rows and 43 queries, covering aggregations, filtering, string operations, and complex multi-column scans.

Before the Axion migration, the December 2024 ClickHouse Cloud Google Cloud results (publicly available at the link above) recorded a data load time of 1,080 seconds for the 24 GB service tier and 613 seconds for the dev tier on x86-based N2D instances.

When we migrated the automated ClickBench test environment to Axion C4A instances in March 2026, the step-change was immediately visible in the benchmark history. Every one of the 43 queries improved by 30-55% per query, uniformly across the full query set. Load time dropped by roughly half. The shift was so consistent that it showed up as a clear overnight discontinuity in the benchmark trend line.

As of March 11, 2026, ClickHouse Cloud on Google Cloud holds first place on the combined [ClickBench ranking](https://benchmark.clickhouse.com/#system=+%E2%98%81w%7C%EF%B8%8Fr%7CC%20c&type=-&machine=-ca2l%7C6t%7Cg4e%7C6ax%7C6ale%7C3al%7Co%E2%98%818%7Ck12%7Ck16%7Cu%EF%B8%8F4%7C0i%7C23%7C%E2%98%815&cluster_size=-&opensource=-&hardware=+c&tuned=+n&metric=combined&queries=-) - the best result across all configurations and systems tracked by the benchmark. You can see the current live results at [benchmark.clickhouse.com](https://benchmark.clickhouse.com/).  

This tracks with what we observed in earlier controlled benchmarking, where we ran ClickBench across equivalent VM sizes (8 CPUs, 32 GiB memory) comparing C4A-standard-8 Axion instances against n2d-standard-8 instances at 1, 2, and 3 replicas. The C4A instances outperformed N2D across every replica count - a consistent advantage rather than a narrow edge on specific query shapes. For compute-bound analytical workloads, the improvements from C4A on N2D is in the range of 50-100%, using ~15% fewer compute credits per query on average. For analytical query patterns similar to ClickBench, the benefit is substantially larger.  

![](/uploads/axion_apr2026_image3_aa1e5c8261.png)

![](/uploads/axion_apr2026_image2_99a5e3ce49.png)

> "*We had high hopes for the Axion migration, and it exceeded them. CPU throttling that had been a persistent problem under peak load essentially disappeared overnight. Our team noticed the difference immediately - the cluster just feels stable in a way it didn't before."*
> 
> -Anders Aagaard *Principal* *Engineer, Nansen* 

There is also a subtler benefit: thermal and frequency stability. x86 instances frequently experience clock frequency variation under sustained load, particularly in multi-tenant environments. Axion Arm-based cores tend to maintain more consistent throughput. Another difference is that x86 1 physical core \= 2 logical vCPUs, while Axion offers one. For ClickHouse, where query latency is directly tied to how many rows per second the CPU can process, that consistency matters.

## **The migration approach** {#the_migration_approach}

We began the Axion migration in our staging environments and internal clusters, and crafted an automated workflow with multiple safety checks and validations along the way. 

From there, we expanded to a controlled rollout across Google Cloud regions, coordinating with the Google Cloud team on regional capacity. This gave us the ability to observe and compare services before and after migration within the same time windows, which is essential for clean performance attribution.

Not everyone waited for the automated rollout. A handful of customers on Google Cloud reached out proactively to migrate early. One, a large analytics platform running high-frequency on-chain data queries, requested C4A instances ahead of the general schedule. Another, a global enterprise customer running demanding analytics at scale, flagged Axion migration as a top priority and was moved to C4A before the broader rollout.  These early migrations gave us production data on Axion performance at scale before the broader rollout. 

For services that require migration, the process follows a few checks:

* Is the service running on [SharedCatalog](https://clickhouse.com/blog/clickhouse-cloud-stateless-compute) (our compute-storage separated storage model)? Services still using legacy attached volumes require an additional step to migrate storage first.  
* What is the service's maintenance window? Migrations are scheduled during low-traffic periods.  
* Is the service among the top-traffic organizations in Google Cloud? These are migrated last, after we've built confidence in the process across a broader set of services.



## **What we observed: fleet-wide efficiency** {#what_we_observed_fleet_wide_efficiency}

To quantify the impact at scale, we analyzed a cohort of 38 services that had completed the x86-to-Axion migration and had at least two weeks of stable pre- and post-migration data. We controlled for services with significant compute credit variance, services that don't scale, and services with unusual traffic patterns around the migration date.

The result: \~15% improvement in compute credits per query across this cohort. Customers are running the same queries and spending 15% fewer credits after their service moves to Axion.  
That number might sound modest in isolation, but it reflects a conservative and rigorous measurement. We are looking at real production traffic, not a synthetic benchmark. The workloads are diverse - dashboards, ingest pipelines, ad hoc analytics, API-backed queries. Not all of them are CPU-bound; some are dominated by Google Cloud Storage read throughput, where the processor architecture matters less. The fleet-wide average, therefore, understates the benefit for compute-heavy workloads.

For services that are primarily CPU-bound - complex aggregations, multi-join queries, heavy decompression - the improvement is substantially larger. ClickBench makes this concrete.  


## **What comes next** {#what_comes_next}

The migration is ongoing. We are progressively expanding to all Google Cloud regions where C4A capacity is available, working through the top-traffic organizations after building a track record of clean migrations across the broader fleet.

Longer term, we expect Axion to become the standard instance type for ClickHouse Cloud on Google Cloud. The performance and efficiency case is clear. The migration tooling is proven.   
For customers on Google Cloud, the migration is transparent. Your data does not move, your queries do not need to change, and the improvement in performance shows up automatically once your service is migrated. We will notify you in advance of your scheduled migration window.  


## **Final thoughts** {#final_thoughts}

The efficiency gains from Axion are real (\~15% fewer compute credits per query across the fleet and 30–55% faster ClickBench results), the migration was seamless, and the customer impact is tangible. For columnar, compute-intensive workloads like ClickHouse, modern ARM processors offer a measurable advantage over general-purpose x86 - and the data from real customer workloads bears out what the benchmarks predict.

The close collaboration with the Google Cloud Axion team, especially in regional capacity planning and co-engineering support throughout this rollout, helped accelerate the upgrade. 

We are migrating our Google Cloud fleet to Axion C4A instances. The results: 30–55% faster ClickBench queries and \~15% fewer compute credits across production workloads.

large_axion_apr2026_image1.png

medium_axion_apr2026_image1.png

small_axion_apr2026_image1.png

thumbnail_axion_apr2026_image1.png

axion_apr2026_image1.png

ClickHouse Cloud on Google Cloud Now Powered by Google Axion Processors: 30–55% Faster Queries, ~15% Fewer Compute Credits

Nava used ClickHouse to build a real-time payments monitoring platform for ELO, one of Brazil's largest card networks, processing 22 million transactions per day. Migrating from Elasticsearch to ClickHouse reduced storage from 12 TB to 2 TB and cut annual infrastructure costs by 87% from R$900,000 to R$120,000. ClickHouse delivers 5x faster aggregations and sub-2-second end-to-end latency, powering 300 real-time dashboards refreshing every five seconds.

[Nava](https://nava.com.br/) was founded in Brazil in 1995 to help large organizations build and manage data center infrastructure. But infrastructure without visibility is only half the picture, and it wasn't long before the company developed its own monitoring and observability products to complement the environments it was building.

The pivot into financial services came in 2012, when Itaú, one of Brazil's largest banking groups, approached Nava to ask for help monitoring the flow of payments through their network. As data engineer and architect Lucas Souza recalls, "With our expertise in observability and monitoring, combined with their domain knowledge, we took on this challenge and decided to create something new—real-time business monitoring for the payments industry."

It was a turning point. Word spread quickly through Brazil's financial sector, and other players in the payments and credit space came looking for the same capabilities. Today, Nava monitors transactions across more than a dozen companies in the payments space, accounting for around 90% of all card transactions in Brazil.

At a [November 2025 ClickHouse meetup in São Paulo](https://clickhouse.com/videos/nava-elasticsearch-migration), Lucas told the story of how Nava helped one of those companies—[ELO](https://www.elo.com.br/), a major Brazilian card network—migrate its analytics infrastructure from Elasticsearch to ClickHouse, cutting costs by 87% and transforming how it monitors 22 million daily transactions.

## How Lucas discovered ClickHouse

Lucas's personal ClickHouse journey began nearly a decade before it made its way to ELO. As a Microsoft SQL Server specialist who spent years speaking at conferences in Brazil and abroad, he used SQL Server as his benchmark for everything.

But around 2014 to 2016, Nava was handling ingestion volumes that pushed relational databases to their limits. "Anyone who works with relational databases knows that if you're ingesting 8,000 or 10,000 records per second, you'll have data page contention," Lucas says.

In-memory solutions helped, but their licensing costs made them impractical to offer competitively to smaller clients. "I needed to find a solution that would meet my niche's needs, that wouldn't compromise performance, that would be as efficient as SQL Server, and that would have low or zero risk," Lucas says.

He evaluated RocksDB, MariaDB, and several other databases before a contact at Percona pointed him toward ClickHouse. It made a strong impression. "ClickHouse is on a different level," he says. "The first time you have contact with it, its performance is absurd."

Coming from a SQL Server background, Lucas had the technical depth to stress-test what he was seeing. ClickHouse held up on every count—compression ratios, query speed, SQL support. He said to himself, "I've found the solution to my problems."

## The limits of Elasticsearch

For the next several years, Lucas and the Nava team built out their ClickHouse expertise internally, waiting for the right opportunity to deploy it into production.

That opportunity arrived in the form of ELO, one of Brazil's leading payment networks. The company processes around 22 million financial transactions every day—over 260 per second—accumulating more than 8 billion transaction records each year.

At the time, Nava was providing ELO visibility into those transactions through a platform built on Elasticsearch, hosted on Google Cloud Platform. But as transaction volumes grew and ELO demanded more from their dashboards, the limitations became harder to ignore.

"The main issue was cost," Lucas says, "both in terms of storage requirements and infrastructure expenses." The Elasticsearch setup required 12 TB of storage and was running up an annual infrastructure bill of R$900,000.

Performance was unreliable, too. Complex aggregations over large date ranges would routinely slow to a crawl, and the team found themselves re-indexing the cluster multiple times a week just to keep pace with demand.

Finally, there was the complexity of the EQL syntax. "Elasticsearch's query language is not user-friendly," Lucas says. "It's a verbose language, a tedious language." Every new dashboard required specialist knowledge; this created a bottleneck as ELO's operations teams waited on developers every time they needed a new view of their data.

## Migrating to ClickHouse

While years of internal testing had built confidence in ClickHouse, Nava had never deployed it in production. Lucas knew that proposing it as the foundation for ELO's monitoring infrastructure was a big step. He made the call anyway.

"We have to take risks all the time," he says. "If you don't take risks and trust in what you do, you'll never get out of your comfort zone, you'll never get anywhere."

The migration preserved the core of ELO's existing data pipeline. Transaction data continues to flow into Kafka, where Nava's custom ETL tool, Dataflow, enriches it against data dictionaries and business rules before loading it into ClickHouse for querying and visualization. What changed was everything downstream of that ingestion layer.

The ClickHouse cluster was deployed on Kubernetes using the Altinity operator, giving Nava fine-grained control over configuration and enabling zero-downtime updates. The cluster runs across four nodes (two shards and two replicas) distributed across ELO's two primary data centers in São Paulo and Rio de Janeiro. Using ClickHouse's [distributed table engine](https://clickhouse.com/docs/engines/table-engines/special/distributed), transactions are routed to the appropriate shard based on site ID, balancing the ingestion load across both locations and doubling the read capacity available for dashboard queries.

Several optimizations were layered on top. [ZSTD and LZ4 compression codecs](https://clickhouse.com/docs/data-compression/compression-in-clickhouse) dramatically reduced storage requirements. [LowCardinality](https://clickhouse.com/docs/sql-reference/data-types/lowcardinality) data types were applied across string columns with fewer than 10,000 distinct values, improving both compression and query speed. [Materialized views](https://clickhouse.com/docs/materialized-views) pre-aggregate common query patterns, and [projections](https://clickhouse.com/docs/data-modeling/projections)—essentially pre-computed execution plans—were added for the date-range comparison queries that had previously caused performance problems in Elasticsearch.

Perhaps the most immediately felt change for ELO's teams was the shift to standard SQL. Where EQL had required specialist knowledge and slowed dashboard development, ClickHouse's [ANSI SQL support](https://clickhouse.com/docs/sql-reference) meant that analysts at any level could query the data and build visualizations without a steep learning curve.

## Cheaper, faster, and easier to use

The difference pre- and post-migration is like night and day. Storage dropped from 12 TB to 2 TB, and ELO's annual infrastructure bill fell from R$900,000 to R$120,000, an 87% reduction. As Lucas puts it, "The smaller the data, the faster it can be transmitted, the faster the access, the greater the amount of data I bring into memory, and the less infrastructure is used."

ClickHouse's query performance tells a similar story. Aggregations that took seconds in Elasticsearch now complete in milliseconds—5x faster on full dataset aggregations, 6x faster on filtered queries, and 9x faster on pre-aggregated data. "The performance is undeniably superior to any other database we evaluated," Lucas says.

ELO now runs approximately 300 operational dashboards around the clock, each refreshing every five seconds. "It takes two seconds from the moment data arrives in Kafka until the moment that data is displayed in my visualization," Lucas says.

The business case for that speed becomes clear when you consider what delayed visibility actually costs. If a payments link goes down in a specific region and ELO's preferred network stops processing, merchants automatically fail over to a secondary network at a higher fee rate. Without real-time monitoring, that situation might go undetected for days—long enough to affect settlement costs and merchant relationships. With ClickHouse-powered dashboards, ELO's operations team can identify a drop in transaction volume at a specific site within seconds and escalate before merchants or cardholders even notice a problem.

ELO has become one of Nava's most vocal advocates as a result. "Today, ELO is practically rolling out the red carpet for us because of the cost they've saved by moving away from Elasticsearch," Lucas says. "At the events they attend, they speak highly of ClickHouse. Why? Because they reduced costs, their application increased in performance, and the ease of creating dashboards is absurdly more productive because of the query language."

## Monitoring financial services across Brazil

Since the ELO migration, Nava has applied ClickHouse across a growing roster of financial services clients, with each adding to the team's depth of experience with the platform.

One of the most demanding recent projects was a migration that involved moving nearly 20 billion records out of MongoDB and into ClickHouse. "Mongo wouldn't stay online because of the sheer amount of document data it had," Lucas explains. "Without needing to do a full replacement, by simply consolidating this data, aggregating it, and using the latest date, the performance was already 10 to 15 times higher."

Nava is also beginning to explore [ClickHouse Cloud](https://clickhouse.com/cloud) for clients who want the performance benefits of the platform without the operational overhead of managing their own cluster. One client, currently running a large Snowflake environment, is evaluating a migration of their analytical workloads to ClickHouse Cloud. As Lucas puts it, "Snowflake is a great product, but the cost of maintaining this data is very high compared to ClickHouse."

For Lucas, five years of production experience with ClickHouse has only deepened his confidence in the platform. "Every single feature we've tested has always been useful in some scenario," he says. What started as a calculated risk on an unfamiliar database has become Nava's go-to solution for high-volume analytical workloads, and the foundation of a monitoring capability that now touches nearly every card transaction in Brazil.

How Nava migrated ELO's payments monitoring platform from Elasticsearch to ClickHouse, cutting storage from 12 TB to 2 TB, slashing annual infrastructure costs by 87%, and delivering sub-2-second end-to-end latency across 300 real-time dashboards.

large_Nava Customer Story.jpg

medium_Nava Customer Story.jpg

small_Nava Customer Story.jpg

thumbnail_Nava Customer Story.jpg

Nava Customer Story.jpg

How Nava helped ELO cut infrastructure costs by 87% by migrating from Elasticsearch to ClickHouse

[永産システム開発](https://eisansystem.jp/)は約40年にわたり、医療・ヘルスケアシステムから大規模データマッチング、最近ではIoT対応プラットフォームまで、精度が重視される分野で高度に専門化されたソフトウェアを開発してきました。これらの多くは水面下で密かに稼働し、ミスが許されない組織のミッションクリティカルなワークフローを支えています。

その考え方は、[2025年7月に東京で開催されたClickHouseミートアップ](https://www.youtube.com/watch?v=fKP-6-_PiZQ)で、永産システム開発の代表取締役である生方守氏が共有した最近の課題にも引き継がれています。きっかけは、クライアントからの支援の依頼という単純なものでした。従来のBIツールを基盤とした既存の分析システムは、増加するデータ量とリアルタイムインサイトへの期待の高まりにより、限界に達し始めていました。

「クライアントはより良い解決策を求めて連絡を取ってきました」と生方氏は述べています。永産システム開発はその後、信頼性を損なうことなくスケール可能かつ実用的なプラットフォームをエンジニア主導で探し求めることになり、最終的にたどり着いたのが[ClickHouse Cloud](https://clickhouse.com/cloud)でした。

<iframe width="768" height="432" src="https://www.youtube.com/embed/fKP-6-_PiZQ" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

## 従来のシステム：高コストで信頼性に欠ける

その課題において最も重要であったのは、ID-POSデータでした。これは、スーパーマーケットやドラッグストアから収集された、個々の顧客IDに関連付けられたPOSレコードです。小売クライアント一般において、バスケット分析やクロス分析、および顧客が店内で自身の身分を明かすと製品がおすすめされるリアルタイムパーソナライゼーションにこのデータが活用されています。時間が経つにつれてそのデータは積み重なり、クライアントによっては年間2億件近くのレコードが蓄積されることもあります。

このワークロードに対して永産システム開発が使用していた分析プラットフォームはQlikViewをベースに構築されており、理論上はスピードを重視して設計されていました。すべてがメモリ内で処理されるため、単純な集計の多くはわずか数秒で完了していました。「しかし、データが増えるにつれて、一部のプロセスの処理に数分かかることがありました」と生方氏は言います。さらに悪いことに、システムは予測や制御が難しい形で不具合が出始めました。「最近では、分析結果がまったく返ってこないケースが増えてきています。これは非常に深刻な問題です。」

プラットフォームを利用するクライアントが増えるにつれ、コスト圧力も強まっていきました。QlikViewのライセンスモデルでは、新規導入のたびに費用が増加していました。生方氏はこれを「ユーザーにとって大きな負担であり大きな懸念事項」と表現しています。システムのメモリ負荷の高い設計は問題をさらに悪化させました。「QlikViewはすべての処理をメモリ内で行うため、必然的に膨大なメモリを消費します」と彼は述べています。「結果として、私たちのサーバコストも増加し続けています。」

## ClickHouseが深刻な課題の解決に貢献

チームが最初に考えたのは、オープンソースの代替手段を探すことでした。目標は、コストを削減しながらパフォーマンスとスケーラビリティの制御を取り戻すことでした。PostgreSQLのような馴染みのある選択肢や、YugabyteDBのような分散システムを評価しました。「どれも私たちが求めていた結果を出すことはありませんでした」と生方氏は語ります。落胆したチームは、より良い解決策が本当に存在するのか疑問を持ち始めました。「どうせ無駄だろうと、私たちはほとんど諦めかけていました。」

その後ClickHouseを見つけたのはほぼ偶然でした。「そのスピードは本当に驚異的でした」と生方氏は言います。「これは実際にうまくいくかもしれない」と考えました。その最初の印象から、さらに詳しく検討する価値があると判断し、最終的には本格的な導入への動きにつながりました。

東京のミートアップで、生方氏は従来のQlikViewベースのシステムと新しいClickHouseの構成の比較を並べて紹介しました。ClickHouseのほうが明らかに高速でしたが、その結果は書面上ではそこまで大きなものではありませんでした。しかし、彼は文脈が重要だと言います。「QlikViewはすべてをメモリ内で処理しています。一方、ClickHouseはそうではありません。これには本当に感心しました。」

いわゆる一般的な構成と比べても、ClickHouseは少ないリソースで安定した結果が出ました。「サーバースペックは標準的な構成より抑えめですし、高負荷寄りの設定でも動かしています。それでも性能は崩れず、結果は非常に安定しています。従来の製品だと、同じことをやろうとするとハードウェアを増やす判断になりがちですが、ClickHouseはその前に解決できる感触があります」と生方氏。

おそらく最も重要なのは、ClickHouseが負荷がかかっている状況でも予測可能な動作をすることです。「QlikViewでは、結果がまったく返ってこないことがよくあります」と生方氏は言います。「これまでのところ、ClickHouseが結果を返さなかったことは一度もありません。」

## サーババランスの洗練された技術

ClickHouseがその有効性を証明した後、新たな疑問が生まれました。それは、効率的に運用するにはどうすればよいかということです。生方氏とチームは、CPUコアとメモリのバランスに焦点を当て、[ClickHouse Cloud](https://clickhouse.com/cloud)の異なる構成のテストを開始しました。ある構成では、30コアと120GBのRAMを使用し、ClickHouseのワークロードにおける出発点として一般的に使用される[メモリ対 CPU コア比 4 GB : 1](https://clickhouse.com/docs/guides/sizing-and-hardware-recommendations#how-many-cpu-cores-should-i-use)を採用しました。

一見すると、メトリクスから疑問が浮かびました。CPU使用率は健全に見えましたが、メモリ使用量は意外に低かったのです。「そのことが、このバランスが本当に最適かどうかについての議論につながりました」と生方氏は言います。ClickHouse日本チームと話し合った後、状況がより明確になりました。「そこでかなりの量のメモリがキャッシュに使われていることを知りました。」

その動作を考慮に入れると、実際の使用量は約100GBに近くなり、最初に見えたよりもその構成のほうがバランスが良く感じられました。ここで得られた結論は決まった答えではなく、むしろプロセスのようなものでした。「もちろん、まだ多くの異なるシナリオを検討する必要があります」と生方氏は言います。チームは引き続き負荷テストを行い、サーバの仕様を調整しながら、さまざまな状況下でClickHouseの動作を観察し、構成を段階的に改善しています。

## 永産システム開発とClickHouseの次なる展開

永産システム開発のClickHouseに関する計画は、現行のシステムをはるかに超えています。「最終的にはユーザー数が増加すると予想しています」と生方氏は語ります。「我々の目標は1,000億レコード規模のデータを扱えるようにすることです。」そのスケールを達成するには、ワークロードの進化に合わせてアーキテクチャの設計をスマートに行い、継続的なテストと反復が必要です。

チームはまた、システムの日常的な利用状況を詳細に分析しています。現在、多くの分析ジョブは業務時間内に実行されています。「その結果、システムは夜間にはほとんど利用されていません」と生方氏は説明しています。利用可能な容量をより有効活用するため、週次や月次処理をオフタイムにシフトし、リソースの利用を平準化する方法を模索しています。

[オートスケーリング](https://clickhouse.com/docs/manage/scaling)もその議論の一部です。また、より意図的で計画的なスケーリングのアイデアも含まれます。「『計画的なスケーリング』という表現が適切かは分かりません。例えば日曜日に完全に運用を停止するのも可能かもしれません。それは有用だと思います」と生方氏は言います。

永産システム開発にとって、ClickHouseは完成されたプロジェクトというよりも、これからの展開のための基盤です。処理時間はすでに改善されており、新しい機能が可能性を広げ続けています。本当の課題は今や運用面にあります。それは、データ量と期待が増え続ける中で、大規模なリアルタイム分析システムをいかに円滑に稼働させ続けるかということです。

チームのデータ運用を拡張する準備はできていますか？[ClickHouse Cloudを30日間無料でお試しください。](https://clickhouse.com/cloud)

- 永産システム開発は複数の小売クライアント向けに、バスケット分析、クロス分析、パーソナライズされたレコメンデーションを大規模にサポートするリアルタイムID-POS分析プラットフォームを構築。
- QlikViewベースのBIスタックをClickHouse Cloudに置き換え、信頼性とパフォーマンスを向上させつつ、ライセンス費用とインフラコストを削減。
- このシステムは現在、クライアントごとに数億件のレコードを処理しており、継続的な最適化により将来的な数百億件への拡張に向けて明確な道筋が示されている。


永産システム開発がいかにClickHouse Cloudを活用し、POS分析を高速、低コストかつ信頼性の高いものにしたか

ClickHouse

Blog posts by ClickHouse