在时序数据库领域，TimescaleDB 作为 PostgreSQL 生态的时序化方案，扩时序能力都会优先考虑，是 PG 系时序方案的标杆。而 KaiwuDB 这两年发声也挺多的，作为国产原生时序数据库，在各类基准测试里表现亮眼，往期几篇我也依次分享了KaiwuDB 与 IoTDB、TDengine、InfluxDB 的对比测试数据情况。

这次依然还是想沿用 TSBS 标准基准，想来看看 PG 生态主流时序化方案 VS 国产原生时序新锐，两者技术路线完全不同的情况下到底性能差异如何，分享给同样在时序选型的朋友参考。

一、测试环境与配置

本次测试依然保证两个数据库（KaiwuDB v3.1.0 与 TimescaleDB v2.25.2 ）的运行环境完全一致，排除了环境差异对测试结果的干扰，全程采用 Docker 容器化部署，具体配置如下：

• 2 颗 Intel Xeon Gold 6240 CPU（2.6GHz 基础频率，最高 3.9GHz），共 72 逻辑核（18 核 / 颗 ×2，超线程开启），2 个 NUMA 节点

• 通过 Docker 限制单节点仅使用 16 核，单节点内存上限为 32GB

• 总容量 394.8GB（MemTotal: 394835452 kB），支持 DirectMap4k / DirectMap2M / DirectMap1G 页映射

• 每个容器（节点）绑定单个 1.8TiB Intel NVMe 硬盘

PS：其中，为了保证较好的性能，TimescaleDB 需要针对不同的场景设置不同的 Chunk 参数，不同场景下参数的设置如下表所示。

（此参数的设置，充分参考了对比报告【TimescaleDB vs. InfluxDB: Purpose Built Differently for Time-Series Data. https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/】中推荐的配置参数设置，以确保能够最大化写入性能指标。）

二、核心结论一眼看懂

写入优势：KaiwuDB 在 4/4 个场景中全部领先，吞吐最高超 15 倍，原生架构优势明显。

查询领先：Worker 1 相较于TimescaleDB 平均提升 76.6%，Worker 8 提升 87.6%，几乎全场景更快。

复杂查询：高聚合、lastpoint 等场景差距达百倍级。

稳定性能：数据量上来后，TimescaleDB 性能衰减严重，KaiwuDB 几乎无波动。

三、写入性能（rows/s，数值越高越好）

写入部分使用写入速度作为吞吐指标，统一按 rows/s 展示，数值越高越好。相对差异采用 (KaiwuDB - TimescaleDB) / TimescaleDB 计算。

KaiwuDB 在所有场景下吞吐都大幅领先，尤其在中规模场景，吞吐接近 16 倍差距。原生时序存储引擎对高并发写入的优化，明显强于 PG 时序化方案；TimescaleDB 写入上限偏低，数据量增大后吞吐下滑明显。

四、查询性能（ms，越低越好）

查询部分采用公式 (TimescaleDB 延迟 - KaiwuDB 延迟) / TimescaleDB 延迟计算相对差异。正值表示 KaiwuDB 查询延迟更低，负值表示 TimescaleDB 更优。测试分别在 Worker 1、Worker 8 两种并发下实测，覆盖 15 类典型时序查询，下图为数据差异总览：

通过上图可以看出：

• 单机 worker 1查询：KaiwuDB 在 55/60 个测点延迟更低，平均改善 +76.6%。

• 单机 worker 8查询：KaiwuDB 在 59/60 个测点延迟更低，平均改善 +87.6%。

接下来，我们分别看看小规模（100 设备）、中规模（4000 设备）、大规模及超大规模（10 万 / 100 万设备），在 Worker1（低并发）、 Worker8（高并发）不同情况下的性能情况。

4.1 小规模（100 台）

Worker 1

在单 Worker 低并发下，两者均能快速响应。KaiwuDB 在所有查询类型上全面领先，尤其在 lastpoint（最新点查询）上优势巨大，延迟从 TimescaleDB 的 7114ms 降至 0.9ms。

Worker 8

当并发提升到 8 Workers 后，TimescaleDB 的延迟开始显著增加，性能衰减明显，而 KaiwuDB 依旧保持极低且稳定的延迟。在 lastpoint 和复杂聚合查询上，KaiwuDB 的性能优势进一步扩大，普遍快一到两个数量级。

4.2 中规模（4000 台）

Worker 1

简单查询差距依然不大，但在 double-groupby（双维度分组）等复杂聚合查询上，差距开始急剧拉大。例如 double-groupby-1 查询，TimescaleDB 耗时 6300ms，而 KaiwuDB 仅需 183.69ms，优势高达 97.1%。

Worker 8

并发压力下，TimescaleDB 的多个查询开始进入秒级甚至 8 秒以上（double-groupby-all 达 8073ms），性能严重下滑。KaiwuDB 虽然延迟相比低并发也有所增加，但始终保持在可控范围内（最高 1241ms），表现出极佳的性能韧性。

4.3 大规模（10 万台）

Worker 1

TimescaleDB 性能严重承压，double-groupby-1 查询耗时高达 19715ms（近20秒），基本不具备可用性。KaiwuDB 虽然延迟也增长到秒级（1074ms），但相比 TimescaleDB 仍有近 20 倍的性能优势。lastpoint 查询上，KaiwuDB 同样保持近 20 倍的优势。

Worker 8

TimescaleDB 的性能彻底崩溃，大量复杂查询耗时在 8-22 秒之间。KaiwuDB 的高并发查询延迟虽然也上升至 5-7 秒，但整体可控，且在高负载下无任何失败或超时，稳定性优势彻底拉开。

4.4 超大规模（100 万台）

Worker 1

TimescaleDB 已到达极限，double-groupby-all 查询耗时超过 40 秒，lastpoint 查询也超过 21 秒。值得注意的是，在 single-groupby-1-1-1、single-groupby-1-8-1、cpu-max-all-1 等几个最简单的单维度点查上，TimescaleDB 的响应速度（<1ms）反常地优于 KaiwuDB（~1ms），可能是得益于其极端的缓存策略或执行计划优化，但并不影响整体性能格局。KaiwuDB 在所有复杂查询上依然保持压倒性优势，double-groupby-all 比对方快 91.9%。

Worker 8

并发拉满后，TimescaleDB 在部分双维度聚合查询上出现灾难性延迟，double-groupby-5 耗时 477295ms（约 8 分钟），double-groupby-all 更是高达 1152227ms（约 19 分钟），基本等同于不可用。而 KaiwuDB 即使在如此极限的压力下，所有查询仍能在 5.4 秒内返回，且无任何失败或中断，稳定性优势达到顶峰。