PostgreSQL和ClickHouse虽然都能执行SQL聚合，但底层设计目标完全不同。PostgreSQL是通用关系型数据库，以行式存储和事务一致性为核心，适合频繁插入、更新和点查；ClickHouse是面向分析场景的列式数据库，追求大范围扫描、聚合与压缩效率。实时分析并不是选择一个更快数据库那么简单，而要判断数据写入模式、查询延迟要求、更新频率和SQL复杂度。下面从存储引擎、查询执行、更新能力和选型策略几个角度展开对比。
很多团队在搭建实时报表或用户行为分析系统时，会同时考虑PostgreSQL和ClickHouse。前者生态成熟、事务可靠，后者分析性能突出。要做出合理选择，需要先理解两者在处理分析型查询时的根本差异，而不是只看某个基准测试的耗时数字。
一、存储引擎与数据组织差异
PostgreSQL的堆表采用行式存储，一行内所有列连续存放。对于点查和事务更新，这种布局非常自然，主键或二级索引可以快速定位数据行。但当查询需要对大范围数据做聚合时，行式存储会读取大量与聚合无关的列，造成I/O浪费。例如统计一段时间内的事件类型分布，即使只关心event_type和event_time两列，PostgreSQL也可能扫描整行数据，尤其是索引无法覆盖查询列时。
PostgreSQL的MVCC机制通过保留多个行版本来支持并发更新，这带来事务隔离上的优势，但同时会导致表膨胀。频繁更新和删除会在数据页中留下死元组，后续查询需要跳过这些无效版本，VACUUM维护也会消耗资源。对分析查询来说，这些机制增加了额外开销。
ClickHouse的MergeTree家族则完全围绕列式分析设计。每个列独立存储，数据按排序键物理排序，并进行压缩。查询时只需要读取涉及的列文件，压缩后的数据不仅节省磁盘空间，还能减少扫描字节数。稀疏索引基于排序键快速跳过不相关数据块，配合分区裁剪，可以大幅降低扫描范围。下面分别展示PostgreSQL和ClickHouse面向同一事件数据的建表方式。
CREATE TABLE events_pg (
event_id BIGSERIAL PRIMARY KEY,
user_id BIGINT NOT NULL,
event_type TEXT NOT NULL,
event_time TIMESTAMPTZ NOT NULL,
properties JSONB
);
CREATE INDEX idx_events_time ON events_pg (event_time);
CREATE TABLE events_ch (
event_id UInt64,
user_id UInt64,
event_type LowCardinality(String),
event_time DateTime,
properties String,
sign Int8
) ENGINE = CollapsingMergeTree(sign)
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_type, event_time);
可以看出，PostgreSQL需要显式创建时间索引，数据仍然以行为单位存储。ClickHouse则通过ORDER BY指定排序键，并利用分区按月组织数据。对于分析型扫描，ClickHouse的列式布局和压缩特性通常能带来数量级的I/O降低，而PostgreSQL的堆表设计在大量聚合时会受到行存边界的限制。
二、实时聚合查询性能特征
实时分析查询最常见的形式是按维度聚合指标，例如按事件类型统计PV和UV。PostgreSQL从较新版本开始支持并行顺序扫描和并行聚合，但在行式存储上计算每一行都需要跨列读取，CPU缓存命中率较低。而且count(DISTINCT user_id)这类去重操作需要构建哈希表，数据量较大时会消耗大量内存和临时文件。
ClickHouse在查询执行上采用向量化模型。数据按列块加载到内存，CPU一次处理一批值，同时利用SIMD指令加速比较、过滤和聚合操作。对于去重，ClickHouse提供uniq、uniqCombined等近似算法，精度可控，性能比精确去重高得多。如果业务允许微小误差，可以显著降低查询延迟。
下面是相同聚合查询在两种数据库中的写法，注意ClickHouse的uniqExact用于精确去重，而PostgreSQL使用count(DISTINCT ...)。
SELECT event_type, count(*) AS pv, count(DISTINCT user_id) AS uv FROM events_pg WHERE event_time >= '2024-01-01 00:00:00' AND event_time < '2024-02-01 00:00:00' GROUP BY event_type ORDER BY pv DESC;
SELECT event_type, count() AS pv, uniqExact(user_id) AS uv
FROM events_ch
WHERE event_time >= toDateTime('2024-01-01 00:00:00')
AND event_time < toDateTime('2024-02-01 00:00:00')
GROUP BY event_type
ORDER BY pv DESC;
在数据量较小时，PostgreSQL的查询规划器能选择合适的索引扫描，响应速度可能并不逊色。但当数据规模增长到数千万甚至数亿行，且查询涉及多个维度组合时，ClickHouse的列式扫描和并行执行优势会非常明显。PostgreSQL可能要依赖物化视图或汇总表来降低实时查询压力，而ClickHouse可以直接在大表上完成交互式聚合。
不过，PostgreSQL在分析场景下也并非毫无还手之力。通过合理的覆盖索引、分区表、并行调优和BRIN索引，能够覆盖一些中等规模的分析查询。关键要看查询是否总是命中时间范围或特定索引，如果过滤条件选择性高，行存也可以很快定位数据块。
三、数据更新与实时写入策略
实时分析中的实时除了查询延迟，还涉及数据写入后的可见速度。PostgreSQL支持行级UPDATE和DELETE，事务提交后数据立即可见，强一致性强。这对于需要频繁修正状态、更新订单状态或用户属性的业务非常友好。比如下面的更新操作在PostgreSQL中非常轻量。
UPDATE events_pg SET event_type = 'purchase_completed' WHERE event_id = 1001;
PostgreSQL的行级更新基于MVCC，更新时写入新版本并保留旧版本，配合WAL日志保证崩溃恢复。但在高频更新场景下，表和索引膨胀会带来维护成本，尤其是大表上的随机更新还可能触发大量随机I/O。如果实时分析数据主要来自持续追加的事件流，PostgreSQL的写入吞吐量可能成为瓶颈。
ClickHouse的设计假设是批量写入和追加为主。单行UPDATE和DELETE实际上被实现为异步Mutation，数据库需要重写数据片段，代价远高于PostgreSQL。频繁的小更新会严重拖慢ClickHouse，甚至造成后台合并压力。对于需要修改的历史数据，常见做法是写入新版本行，再通过ReplacingMergeTree或CollapsingMergeTree在合并时去重。
实时数据摄入方面，ClickHouse提供了Kafka引擎、物化视图和Buffer表等机制，可以先将数据写入分布式队列，再由后台任务批量落盘。这种方式虽然牺牲了部分可见性，但能获得非常高的写入吞吐。PostgreSQL则更适合直接作为业务交易库，配合事务写入，再通过逻辑复制或CDC工具将变更同步到分析库。
四、选型判断与混合架构
判断PostgreSQL和ClickHouse哪个更适合实时分析，可以从数据量、更新频率、查询并发、SQL复杂度和运维成本几个维度思考。如果数据总量在几百万到几千万级别，查询结果集不大，且需要与事务数据保持强一致，PostgreSQL完全可以胜任。若每天新增数亿条事件，需要秒级完成多维聚合，并且更新主要是追加写，那么ClickHouse是更自然的选择。
实践中很多系统并不是二选一，而是采用混合架构：PostgreSQL作为在线交易库，保存核心业务实体和最新状态；ClickHouse作为分析库，通过消息队列、CDC或定时同步接收事件数据。分析报表、用户行为漏斗、实时大屏等查询全部指向ClickHouse，业务交易和点查继续由PostgreSQL承担。这样既保留了关系型数据库的事务能力，又获得了列式分析引擎的高吞吐。
在混合架构中，需要注意数据同步的延迟和一致性。例如使用Debezium等工具捕获PostgreSQL的WAL变更，再写入Kafka，由ClickHouse物化视图消费。这种链路可以实现准实时同步，但需要监控每个环节的堆积情况。也可以通过PostgreSQL的外部数据包装器访问ClickHouse，不过跨库查询的延迟和复杂度较高，不适合高频实时分析。
最终选型不是寻找一个万能数据库，而是根据真实工作负载做权衡。PostgreSQL在事务处理、点查、小规模聚合和生态集成上表现优异；ClickHouse在大规模事件扫描、列式聚合、压缩存储和实时导入上优势突出。理解两者的存储和查询模型，能够帮助团队避免在错误场景下强行使用某一种数据库，从而构建更稳定的实时分析系统。
