AI 驱动的应用功能，例如生成洞察、异常检测、推荐，以及面向产品数据的自然语言接口，都需要在事务写入和分析读取之间建立紧密的反馈闭环。
其标准架构是 Postgres + ClickHouse：
- Postgres 负责事务和应用状态，ClickHouse 负责分析。
- ClickHouse 提供快速摄取、针对数十亿行数据的亚秒级查询，以及面向客户应用所需的并发能力。
随着应用越来越具备智能体能力，这种组合也变得更加关键。
智能体必须持续查询实时产品数据，这会同时提升查询频率和并发度。
ClickHouse 通过原生的 Postgres + ClickHouse 集成来解决这一问题，提供自动数据复制和统一的开发者体验，无需再管理单独的 CDC 管道。 自然语言分析界面 (有时也称为 AI Analyst) 正从实验走向生产环境。
用户用日常英语提问，并期望在几秒内得到答案。这对基础设施的含义在于：一条自然语言查询不会只生成一条 SQL 查询——通常会在短时间内连续生成数十条，因为智能体需要探索可用数据集并评估多条推理路径。
因此，内部分析师工作负载在并发和延迟特征上，开始越来越像面向外部客户的工作负载。传统数据仓库是为低频、批处理式查询而设计的。它们优化的是大量查询下的整体吞吐量，而不是高并发下的亚秒级响应时间。在这种架构上运行 AI Analyst 工作负载，要么会带来不可接受的延迟，要么成本增长速度快于其创造的价值。ClickHouse 从一开始就是为高并发交互式查询而构建的：可支持 PB 级数据、数千并发用户，以及针对数十亿行数据的亚秒级响应时间。
传统可观测性技术栈建立在三个彼此分离的支柱之上——指标、日志和链路追踪——并通过对数据进行预聚合和采样来控制存储成本。对于人工主导的工作流，这种权衡可以接受，但对 AI SRE 来说却行不通。
自动化事件分诊、根因分析和异常关联需要细粒度、高基数、长保留周期的数据。一个 AI 智能体如果要将某种错误模式与三天前的一次部署事件关联起来，就无法依赖采样日志或降采样指标。支撑 AI SRE 的架构，是以存储在列式存储中的宽结构化事件为基础的单一事实源。全保真事件只存储一次，而指标、链路追踪和 SLO 都是在查询时从中派生，而不是在摄取时预聚合。
ClickHouse 非常适合这种模型：
- 对日志和事件数据提供高压缩
- 针对高基数宽事件提供亚秒级查询
- 能以生产基础设施规模高效摄取
- 成本模型基于算力和存储，而不是按每 GB 摄取收费
ClickStack 是 ClickHouse 基于这一模型构建的可观测性技术栈，并使用 OpenTelemetry 作为数据采集层。
它既提供开源版本，也提供托管服务。 
