---
title: "AIには最高峰のデータスタックが必要:PostgresとClickHouse"
date: "2026-07-23T13:46:23.022Z"
author: "Sai Srirampur"
category: "Product"
excerpt: "AIアプリケーションはデータの爆発的な増加をもたらし、トランザクション処理と分析処理の境界を消し去りつつあります。その結果、PostgresとClickHouseを組み合わせるベストオブブリードのアプローチ——CDC、ネイティブクエリ、そしてオブザーバビリティによって、両者はますます緊密に結びついています——"
---
# AIには最高峰のデータスタックが必要:PostgresとClickHouse
および[ClickHouse](https://clickhouse.com/)に関わってきた中で、AIがアプリケーションからデータベースへの要求をどのように変えてきたかを目の当たりにしてきました。あらゆるAIアプリケーションはデータアプリケーションです。エージェントは膨大なオペレーショナルデータを生成し、ユーザーはそのデータに基づいたリアルタイムの回答を、しばしば同一リクエスト内で期待します。これによって、アプリケーションからデータベースへの要求も変わってきているのです。
この記事では、AIアプリケーションがデータレイヤーに実際に何を求めているのか、なぜPostgresとClickHouseがこうしたワークロードに対する自然な組み合わせになりつつあるのか、そしてこの組み合わせを開発者にとってより身近なものにするために私たちが行っている投資について掘り下げていきたいと思います。
**TL;DR** AIは前例のない規模でデータ増加を加速させ、トランザクション処理(OLTP)と分析処理(OLAP)の[ワークロード](https://clickhouse.com/resources/engineering/oltp-vs-olap)の従来の境界線を崩しつつあります。こうした要求に応えるには、それぞれの用途に最適化されたベスト・オブ・ブリードのデータベース、すなわち[Postgres](https://www.postgresql.org/)とClickHouseが、それぞれの設計目的を最大限に発揮しつつシームレスに連携する必要があります。
## AIが必要とするもの、そしてデータ環境の変化 {#what-ai-needs-and-how-its-changing-the-data-landscape}
### AIはデータレイヤーを新たな限界へと押し上げている {#ai_is_pushing_the_data_layer_to_new_limits}
AIネイティブなアプリケーションは、従来のソフトウェアよりもはるかに多くのデータを生成します。あらゆるプロンプト、レスポンス、ツール呼び出し、評価、ユーザー操作がデータとなり、データ量とクエリの同時実行数の両方が爆発的に増加しています。
私が語っている規模感を示すデータポイントを紹介します。PostgresとClickHouseを利用しているAIネイティブ企業のサンプルにおいて、**6か月間で平均1,000%以上のデータ増加**、**85 TBを超えるデータ追加**が観測されました。
また、AIがバイブコーディングされたアプリを超えて本番システムに進出するにつれ、トレードオフも変化しています。アプリケーションはミッションクリティカルな意思決定を行い、より大きなサーフェスエリアと規模で運用されるようになっており、データレイヤーの信頼性とセキュリティに対する要求水準も高まっています。
こうした要求に応えるため、AIには膨大なデータをリアルタイムで取り込み、処理し、クエリでき、常に可用性が高くセキュアなデータレイヤーが必要です。高速なプロビジョニングや即時のブランチ機能は素晴らしいものですが、基盤となるデータスタックが高速で、信頼性が高く、セキュアでなければ意味がありません。
### AIはOLTPとOLAPがリアルタイムで連携することを必要としている {#ai_needs_oltp_and_olap_working_together_in_real_time}
LLMを活用したアプリケーション、AIが生成するインサイト、異常検知、レコメンデーションエンジン、自然言語インターフェースはいずれも、トランザクションデータベースと分析データベースの間により緊密なフィードバックループを必要とします。トランザクションデータベースに書き込まれたデータは、不正の疑いのある取引を評価する場合であれ、本番インシデントを診断する場合であれ、ほぼ即座に分析クエリで利用可能にならなければなりません。
こうしたシナリオでは、時間単位や分単位のETLでウェアハウスにデータを移動するという従来のパターンでは十分ではありません。トランザクションデータベースと分析データベースは、データが書き込まれてから分析に利用可能になるまでの間隔が数秒しかない、リアルタイムで動作する必要があります。
### オープンソースの基盤とコストが重要 {#open_source_foundations_and_costs_matter}
AIインフラの世界でも同様の変化が起きています。プロプライエタリなLLMのロックインや膨れ上がるトークンコストへの警戒感が高まる中、チームはデータスタックの柔軟性と経済性についても再考しています。オープンソースデータベースはこの両方を解決します。セルフホスト型またはマネージド型のデプロイメント、ニーズに応じてベンダーを切り替えられる自由度、そしてしばしば大幅に低いコストを提供してくれるのです。
## なぜPostgres + ClickHouseが勝ち残っているのか {#why-postgres-clickhouse-is-winning}
上記の要求は、AIネイティブ企業が選ぶデータスタックを再構築しています。PostgresとClickHouseは、強力なオープンソース基盤の上でクラス最高峰のリアルタイムトランザクションと分析を組み合わせることで、ますますデフォルトの選択肢になりつつあります。
なぜこれが起きているのかを理解していきましょう。
### PostgresとClickHouseはベスト・オブ・ブリードなオープンソースデータベース {#postgres_and_clickhouse_are_best_of_breed_open_source_databases}
一方で**Postgres**は、世界で最も人気のあるオープンソーストランザクションデータベースです。低レイテンシのCRUD操作、ACID準拠、豊富なインデックス、事実上あらゆるクエリをサポートする完全なSQLインターフェース、堅牢な拡張フレームワーク、そして広大なORMおよびアプリケーションエコシステムなど、トランザクションに対する盤石なサポートを提供し、あらゆる場所でWebおよびAIアプリケーションのデフォルトのバックエンドとなっています。
一方で**ClickHouse**は、地球上で最速の分析データベースです。カラムナストレージ、スキップインデックス、増分マテリアライズドビュー、分散キャッシュ、ネイティブJSONおよび全文検索、最近導入された遅延マテリアライゼーション、そして何百もの最適化など、超高速のリアルタイム分析に徹底的にフォーカスした専用機能を提供しています。
どちらもエンタープライズ対応であり、高可用性、信頼性、セキュリティに関する実績ある機能を備えています。
さらに、両者は大規模で活発なコミュニティに支えられた、同じオープンソースの哲学を共有しています。豆知識として、Postgresは最近オープンソースデータベースとして30周年を迎え、ClickHouseは10周年を迎えました。
GitLab共同創業者による、PostgresとClickHouseがどのように補完し合い、ほとんどのデータ問題を解決するかについての[ブログ](https://about.gitlab.com/blog/two-sizes-fit-most-postgresql-and-clickhouse/)。
#### 開発者はPostgresとClickHouseを愛用している {#developers_love_postgres_and_clickhouse}
Postgresは業界でも最も豊富なツールとインテグレーションのエコシステムを提供し、ClickHouseは馴染みのあるSQL、単一バイナリで手軽にできるローカル開発、そして大規模なチューニングをほとんど必要としない分析パフォーマンスを兼ね備えています。この2つが組み合わさることで、「ただ動く」という驚くほどシンプルな開発体験が実現されます。これは、数万のスタートアップやAIネイティブ企業から、[GitLab](https://about.gitlab.com/blog/two-sizes-fit-most-postgresql-and-clickhouse/)、[Instacart](https://tech.instacart.com/real-time-fraud-detection-with-yoda-and-clickhouse-bd08e9dbe3f4)、[Cloudflare](https://blog.cloudflare.com/http-analytics-for-6m-requests-per-second-using-clickhouse/)のようなエンタープライズに至るまでの、圧倒的な採用率にも反映されています。
[DB-Engines](https://db-engines.com/en/ranking)では、PostgresとClickHouseがそれぞれ最も人気のあるオープンソースOLTPおよびOLAPデータベースとして示されており、両者とも人気が伸び続けています。
### PostgresとClickHouseでOLTPとOLAPを統合する {#unifying_oltp_and_olap_with_postgres_and_clickhouse}
***私たちのアプローチはシンプルです。OLTPとOLAPのそれぞれで先頭を行くオープンソースデータベースとしてPostgresとClickHouseを採用し、開発者にとって両者の統合を可能な限りシームレスかつネイティブなものにすることです。***
これを実現するために、私たちはスタック全体にわたって投資を続けてきました。データ移動については、[PeerDB](https://github.com/PeerDB-io/peerdb)があります。これはPostgres向けの[ClickPipes](https://clickhouse.com/docs/integrations/clickpipes/postgres)を支える基盤であり、1桁秒台のレプリケーションでチェンジデータキャプチャ(CDC)を提供します。マルチテラバイト規模のPostgresデプロイメントを運用する1,000社以上の企業で実戦経験を積んでいます。[並列スナップショット](https://clickhouse.com/docs/integrations/clickpipes/postgres/parallel_initial_load)、自動スキーマ進化、ネイティブなPostgresおよびClickHouseモニタリング、レジリエントなレプリケーションなど、専用機能を実装しており、エンタープライズスケールのCDCがお客様にとってほぼ魔法のように感じられるようになっています。
クエリについては、[`pg_clickhouse`](https://github.com/clickHouse/pg_clickhouse)拡張機能により、アプリケーションはPostgresから直接ClickHouseにクエリを実行できます。これによってPostgresがトランザクションと分析の両ワークロードに対する単一のインターフェースとなり、分析クエリは透過的にClickHouseへプッシュされます。
オブザーバビリティについては、[`pg_stat_ch`](https://github.com/ClickHouse/pg_stat_ch)がスタックを補完し、Postgresのクエリテレメトリをストリーミングしてクリックハウスに送信することで、低オーバーヘッドで長期的なオブザーバビリティとパフォーマンス分析を実現します。テレメトリはPostgres自身ではなくClickHouseに保存されるため、OLTPパフォーマンスに影響を与えることなく、数か月分の実行統計を保持し、高カーディナリティな分析を実施できます。
さらに私たちは、[**Postgres managed by ClickHouse**](https://clickhouse.com/cloud/postgres)をリリースしました。これは完全マネージドのPostgresサービスであり、Postgresをローカル NVMe ストレージと組み合わせることで[業界トップクラスのOLTPパフォーマンス](https://clickhouse.com/blog/postgresbench)を実現し、CDCおよびpg_clickhouseを介したClickHouseとのネイティブ統合を提供します。高可用性、PITR、リードレプリカ、フォーク、エンドツーエンドの暗号化が標準搭載されており、開発者に[エンタープライズ対応](https://clickhouse.com/blog/enterprise-postgres-service-in-clickhouse-cloud)の統合データスタックを提供します。
これ以外にも、PostgresとClickHouseの統合をさらに深めながら、それぞれが得意分野で力を発揮できるようにするための、複数の取り組みが進行中です!
以下の図はUnified Data Stackを示しており、OLTP向けのPostgres、OLAP向けのClickHouse、両者間の継続的なレプリケーション、そしてpg_clickhouse拡張機能を介した統合クエリレイヤーが強調されています。
#### ベスト・オブ・ブリードと統合ストレージアーキテクチャの比較 {#comparing_best_of_breed_and_unified_storage_architectures}
過去10年間、データベース業界ではOLTPとOLAPを単一のデータベースエンジンに統合しようとする試みが何度もありました。より最近では、統合ストレージやデータレイクを中心に構築されたアーキテクチャも見られます。
こうしたアプローチは技術的には興味深いものの、開発者をプロプライエタリなプラットフォームに縛り付け、根本的に異なる要件を持つワークロードを単一のシステムで最適化することを求めます。OLTPとOLAPが存在するのには理由があります。行指向ストレージと列指向ストレージは、それぞれ異なるアクセスパターンとパフォーマンス特性に最適化されているのです。
同様に、データレイクはデータウェアハウジングのユースケースには優れていますが、リアルタイムで顧客およびエージェント向けのアプリケーションが要求する低レイテンシ・高同時実行性向けには設計されていません。こうしたアーキテクチャの上にオペレーショナルな機能を積み重ねることは可能ですが、オープンテーブルフォーマットや汎用ストレージレイヤーをサポートする必要性による制約からは逃れられません。その結果、リアルタイム分析専用に構築されたMergeTreeのようなストレージエンジンのパフォーマンスに匹敵することが困難となるトレードオフを、必然的に伴うことになります。
この違いはClickHouseにおける私たちの戦略、すなわちベスト・オブ・ブリードなアプローチをも反映しています。私たちは、MergeTreeをリアルタイム分析における最良のエンジンにすることに注力しつつ、データウェアハウジングのユースケース向けにオープンテーブルフォーマット周辺の革新を継続しています。
## AIの未来はベスト・オブ・ブリードなデータスタック {#the-future-of-ai-is-a-best-of-breed-data-stack}
AIはOLTPとOLAPの区別をなくしているのではなく、これまで以上に重要にしています。この時代を象徴するアプリケーションには、あらゆるインタラクションを確実にキャプチャできるトランザクションデータベース、そのデータをリアルタイムで処理できる分析データベース、そして両者間のシームレスな統合が必要です。
私たちは、未来は根本的に異なるワークロードを最適化しようとする単一のプロプライエタリなプラットフォームにあるのではないと考えています。それは、PostgresとClickHouseの上に構築されるオープンでベスト・オブ・ブリードなデータスタックであり、各データベースが最も得意なことをしながら、一つのものとして連携するのです。
それが私たちが目指しているビジョンです。PeerDBおよびClickPipesを用いたエンタープライズグレードのCDCから、`pg_clickhouse`、`pg_stat_ch`、そして**Postgres managed by ClickHouse**に至るまで、あらゆる投資はPostgresとClickHouseが開発者にとって単一の統合されたスタックのように感じられるようにすることを目的としています。
---
## ClickHouseが管理するPostgresを試す
ClickHouse + Postgresは、スケールするアプリケーションのための統合データスタックとなりました。ClickHouse CloudでManaged Postgresが利用可能になったことで、このスタックは初日から選択すべき構成となります。
[Sign up](https://clickhouse.com/cloud/postgres?loc=blog-cta-1373-clickhouse-postgres-sign-up&utm_blogctaid=1373)
---