2025 时序数据库行业盘点：格局正在收缩，金仓走了一条不一样的路

当时序数据库从“谁都能做”走到“活下来的不多”，真正的分水岭，已经不再是写入 TPS，而是能不能撑住复杂业务、长期成本和下一阶段智能化需求。

如果把过去几年比作时序数据库的“淘金热”，那么 2024～2025，明显已经进入了冷静期。

一方面，时序数据本身的需求并没有减弱。金融行情、工业传感器、能源监测、城市运行数据，仍然在以秒级、毫秒级的频率持续增长；另一方面，市场却在明显收缩——截至 2025 年中，全球可见的时序数据库产品数量，从一年前的 55 个减少到 41 个。
产品少了，但数据更多了，这本身就说明了一件事：这个领域已经不再容得下“只解决一个问题”的工具型产品。

市场规模在 2024 年达到约 3.88 亿美元，但真正能长期留下来的，开始取决于更现实的三个问题：

• 存得起吗？
• 能不能和业务数据一起用？
• 为未来的智能分析准备好了吗？

在这三点上，金仓时序数据库（KES TSDB）并没有走“专用时序数据库”的老路，而是坚持了一条并不轻松、但很清醒的方向：融合。

---

一、第一道坎：数据无限增长，存储成本谁来兜底？

这是所有时序系统都会遇到的现实问题

时序数据有一个很残酷的特性：只要系统还在运行，数据几乎就不会停。

一个中等规模的智能工厂，几万传感器 7×24 小时上报；一个电力调度系统，监控指标按秒采集；一个金融行情系统，高频波动持续写入。
很多系统在最初上线时“跑得飞快”，但一年、两年之后，存储账单会变成真正的压力源。

不少早期时序数据库，重点放在写入性能，却在压缩策略、生命周期管理上相对粗放，最后的结果是：

数据确实存下来了，但用不起了。

金仓的处理方式，更偏向“工程思维”

KES TSDB 在这件事上的思路，并不激进，但很务实。

第一层，是压缩本身。
它不是靠一种“万能算法”，而是根据字段类型自动选择更合适的编码方式——数值型、浮点型、枚举型，各自用不同策略组合。实际项目中，5:1～10:1 的压缩比是一个相对稳定、可预期的区间，而不是实验室里的极限值。

第二层，是数据冷热分离。
金仓允许用户按时间定义数据“温度”，系统自动把历史数据迁移到低成本存储。
这一点在能源、电力、制造行业尤其关键：

• 热数据，关系到实时决策
• 冷数据，更多用于审计、回溯、分析

两类数据如果混在一起，成本一定失控。

一个容易被忽视的优势

很多厂商在宣传写入性能时会很激进，但企业真正关心的，往往是：

三年、五年之后，这套系统还能不能撑得住成本？

在这一点上，金仓并没有追求“跑分第一”，而是把注意力放在全生命周期的存储可控性上。这反而让它在能源、工业这类“数据只增不减”的行业里，更容易落地。

---

二、第二个分水岭：时序系统，真的只能做“时序”吗？

现实业务，远比“画曲线”复杂

专用时序数据库在“指标记录”这件事上确实很强，但问题在于：
真实业务几乎从来不是只看一条曲线。

运维人员会问：

• 这次 CPU 峰值，发生在哪类服务器上？
• 是哪个业务、哪个应用导致的？

制造企业会问：

• 异常温度，集中在哪批设备？
• 是否和设备型号、投产时间有关？

金融系统更不用说，时序数据几乎一定要和交易、账户、客户信息一起分析。

而这正是很多专用时序数据库的短板：
它们的数据模型相对封闭，对复杂 JOIN、分析函数支持有限，最后往往不得不把数据再同步回关系库，形成新的数据链路和复杂度。

金仓的选择：从一开始就不分家

KES TSDB 的核心思路是：

时序数据不是“外来者”，而是数据库内核的一等公民。

它不是在关系库上外挂一个时序插件，而是在统一内核中同时支持关系模型和时序模型。这带来的一个直接结果是：SQL 还是那个 SQL，但能干的事完全不一样了。

例如下面这种场景，在金仓里是非常自然的：

SELECT di.device_id, di.location, AVG(st.temperature)
FROM t_device_info di
JOIN t_sensor_temperature st ON di.device_id = st.device_id
WHERE di.location = '上海工厂A车间'
  AND di.risk_level = '高危'
  AND st.ts >= NOW() - INTERVAL '1 day'
GROUP BY di.device_id, di.location;

这里没有“时序语言”和“业务语言”的切换，
时序表、关系表是平等参与计算的。

对企业来说，这种统一意味着什么？

• 不用维护多套数据库体系
• 不用做复杂的数据同步
• 分析逻辑更贴近业务本身

这一步，其实是在赌趋势

金仓押注的是一个判断：

时序数据库的价值，正在从“记录工具”转向“决策基础设施”。

一旦进入决策层，单一模型就一定不够，多模融合几乎是必然要求。这也是它在工业互联网、智慧能源、复杂金融场景中，逐渐显现优势的原因。

---

三、第三场竞争，已经提前开始：AI 与时序数据

行业共识已经很明确

时序数据，是做预测、异常检测、趋势分析的天然素材。
Gartner 预测，到 2025 年，超过 60% 的企业会使用基于时序数据的预测分析，这并不夸张。

但分歧在于：
AI 能力到底应该“塞进数据库”，还是“和数据库协同”？

金仓的态度，其实相当克制

KES TSDB 当前并没有把自己包装成“自带大模型的时序数据库”，而是选择通过 PostgreSQL ML（pgai） 提供开放能力：

• 支持多种机器学习算法
• 可以在数据库侧完成训练和推理
• 也可以对接外部 AI 平台和模型

这条路，对使用者的技术能力要求更高，但也更灵活、更可控。

更重要的是，金仓已经明确了演进路线：

• 趋势分析、异常检测
• 专用时序模型
• 云边协同的智能分析

不是“有没有 AI”，而是什么时候、以什么方式融合。

一个经常被忽略的事实

很多时候，AI 项目失败不是因为模型不行，而是数据太散、太乱。

而金仓的优势恰恰在这里：
通过内核级融合，提前把时序数据、业务数据、元数据打通，形成天然可用的多模态数据基础。

从这个角度看，它更像是在为 AI 提前“修路”，而不是急着展示算法。

---

写在最后：金仓真正押对的是什么？

如果只用一句话总结，金仓押中的并不是某一项技术，而是一个趋势判断：

未来的时序数据库，不会是“更快的记录工具”，而是“更稳的融合数据底座”。

维度	专用时序数据库	金仓 KES TSDB
核心定位	专注时序写入	融合数据处理
成本控制	依赖压缩	压缩 + 生命周期管理
查询能力	时序为主	完整 SQL + 关联分析
AI 支撑	各自为战	融合数据先行
典型场景	监控、指标	工业、能源、金融决策

在金融、能源、运营商、制造等行业的实践已经证明，这条路并不轻松，但是走得通。

当时序数据库进入“下半场”，
真正的竞争，已经从“谁写得快”，变成了：

谁能陪企业把数据用五年、十年。

这一点上，金仓显然不是短跑选手，而是在准备一场更长的比赛。