最近帮几个团队做时间序列数据库选型评审发现2026年的选型难度反而比五年前更大了。五年前大家比的无非是读写性能和压缩率现在要考虑的却是对象存储架构、云原生部署、生态绑定、许可证边界甚至还要兼顾AI向量检索的延伸需求。市面上几乎所有主流产品都有试用版但很多团队用了两周反而更纠结——不是产品不够好而是没有一套清晰的选型口径把问题和场景对齐。这篇文章我会把InfluxDB 3.x、Prometheus、TDengine、TimescaleDB、QuestDB这五款主流产品放在同一套测试口径下拆开讲清楚重点回答三个问题每款产品的底层机制到底适合什么场景、真实性能表现和官方标称差多少、以及选型时最容易踩的坑有哪些。适合正在做监控平台改造的运维团队、物联网平台后端开发、量化行情数据组以及手里捏着PostgreSQL想顺便解决时序需求的业务团队。1. 2026年的选型环境为什么拿5年前的对比文章会翻车时间序列数据库这个概念这几年没有变但整个技术生态的底座已经换了一批。五年前的选型对比文章现在翻出来看很多结论已经不能直接照搬了。1.1 三个新变量改变了选型权重第一个变量是对象存储成为一等公民。过去时序数据库的容量规划基本都是围着本地盘转扩容靠加节点副本靠多节点复制。到了2026年主流产品基本都支持把冷数据放到S3、OSS、MinIO这类对象存储上本地盘只承担热数据缓存和写缓冲。这个变化直接影响成本模型从“按节点和内存付费”变成了“按存储量和查询量付费”所以压缩率、归档策略、冷热分层能力重新变成核心指标。第二个变量是数据接入方式统一了。OpenTelemetry在可观测性领域的普及让指标、日志、Trace的接入标准逐渐收敛物联网场景也在大量使用MQTT、OPC UA等协议网关。现在的时序库如果只能收自己的私有协议集成成本会非常高。五年前大家纠结的“推模型还是拉模型”如今在选型里的权重已经让位给了“能不能直接吃标准协议的批量写入”。第三个变量有点出人意料时序库开始承担AI/向量工作负载。TimescaleDB这两年明显在往pgai方向走把Vector、机器学习推理直接放进PostgreSQL生态InfluxDB 3.x也通过Arrow Flight和Python插件让数据可以无缝喂给模型训练。这意味着如果你未来有指标异常检测、预测性维护这类需求选型时就要看这个产品有没有能力在数据旁边跑推理而不是把数据倒腾出去再导回来。1.2 反直觉的成本结构反转我前两年帮一家智慧水务团队做评估他们的数据量大概一年10TB压缩后最开始想选一个内存占得少的轻量方案结果算下来存储成本反而成了大头。原因很简单时序数据写入后基本不再修改最贵的不是计算而是放得下、查得动、存得起。当对象存储按量计费、长期保留成为常态压缩算法强不强、冷热分层顺不顺手、生命周期策略能不能自动化这些细节对总成本的影响远大于单节点查询性能的30%差距。所以我在本文的性能对比里除了写入吞吐和查询延迟还专门加了压缩率对比。很多团队在POC时只看延迟上线三个月后才发现存储账单爆了这种案例我见得太多了。1.3 参测产品与版本边界说明为了不让对比失真我先约定说明本文讨论的InfluxDB是3.x系列Prometheus是3.x版本TDengine是3.x企业开源版TimescaleDB是2.x/3.x连续发布的当前版本QuestDB是面向云和自托管的最新版本。各产品的开源协议、集群能力和企业功能边界差异很大后文会专门出一节讲许可证和部署边界这里不展开。2. 五款产品的工作机制底层差异决定适配边界选时序数据库第一步不是比benchmark而是看它怎么存、怎么写、怎么查。存储模型一旦定了后面的性能和场景边界基本就锁死了。这一节我按每个产品的核心机制讲清楚。2.1 InfluxDB 3.xArrow/Parquet列存与对象存储优先的新架构InfluxDB 3.x是一次彻底重写底层换成了Rust加Apache Arrow和DataFusion存储格式用Parquet主打对象存储优先。写入路径是WAL加内存buffer然后批量flush成Parquet文件落到对象存储本地盘只做查询缓存。这个设计带来的最大改变是容量理论上可以随对象存储无限扩展且列存格式对范围聚合查询非常友好。但代价也很明显。首先是Flux语言在3.x里被边缘化官方主推SQL老用户从2.x迁移过来等于重新学一套API其次是查询延迟依赖缓存命中率纯冷数据首次查询会因为从对象存储拉文件而变慢。如果你已经在用InfluxDB 2.x要评估清楚迁移成本这个我后面在避坑章节专门说。2.2 Prometheus拉模型监控数据闭环是它的DNAPrometheus不能简单理解成一个“数据库”它是一个以抓取为中心的监控系统。服务端主动去拉取目标暴露的指标端点数据落进本地时序库再用PromQL做告警和可视化的闭环。这个模型在Kubernetes和微服务场景里非常自然因为服务发现和动态实例管理本身就是K8s的强项。它的存储引擎是按2小时一个block组织的block内有chunk压缩索引用倒排索引来支持快速标签匹配。问题也出在这里倒排索引常驻内存一旦指标标签基数涨起来内存消耗会很难看。Prometheus的定位永远是“监控系统的存储组件”而不是通用时序数据仓库拿它存业务明细数据是典型的用途错配。2.3 TDengine超级表建模对物联网场景的降维打击TDengine是五款里唯一把“物联网数据建模”作为设计起点的产品。它引入超级表概念一张超级表描述设备类型每个设备一张子表标签列和数据列分开存储数据按时间自动分片。这套模型对“成千上万个设备上报同一批测点”的场景非常匹配写入和查询都能顺着设备维度并行化。3.x之后集群能力全面开源支持多副本和Raft协议冷热数据多级存储也做进去了。最直观的好处是物联网平台后端不用再自己维护分库分表建表语句里写清楚标签查询直接写SQL学习成本比专用时序查询语言低很多。劣势是对通用SQL的覆盖不如PostgreSQL复杂嵌套子查询、多表任意JOIN的效率一般生态也相对年轻。2.4 TimescaleDB把时序能力“焊接”进PostgreSQLTimescaleDB走的是另一条路不重新造一个数据库而是做成PostgreSQL扩展。它通过hypertable把一张逻辑大表切成很多chunk每个chunk按时间分区、按分区键分片对应用层完全透明。所以你能用完整的SQL做任意复杂查询还能和普通业务表直接JOIN这是其他时序库很难给的自由度。它还有continuous aggregates本质是增量刷新的物化视图对“每小时聚合一次”“每天滚动统计”这类常规报表非常省心。压缩功能按chunk做行列混合压缩压缩率不错。但代价是PostgreSQL本身的写入吞吐上限在那里超高频写入场景会比专用列存引擎吃亏另外压缩后的chunk如果收到乱序写入会触发解压重写性能容易掉档。2.5 QuestDB为高吞吐事件流而生的Java列式引擎QuestDB在性能上有几个狠招列式存储、SIMD指令优化、Java层几乎无GC停顿。它原生支持InfluxDB line protocol和PostgreSQL wire protocol写入侧兼容性好插入吞吐做得非常高。最突出的是ASOF JOIN能把两个采样频率完全不同的时间序列按最近时间对齐做金融行情回测和传感器数据融合时非常顺手。但它的社区自托管版定位偏向单机原生高可用、细粒度权限这类企业功能更推荐用云版本。SQL方言与PostgreSQL接近但不完全兼容有些团队把开发环境的SQL直接上生产会踩坑。2.6 一张表看穿底层差异产品存储模型写入方式查询接口核心优势核心瓶颈InfluxDB 3.xParquet列存对象存储Line Protocol、SQLSQL、Flight SQL、Flux云原生扩展、无限留存2.x迁移成本、冷查询延迟PrometheusBlock倒排索引拉取/推送网关PromQL、HTTP API监控闭环成熟、运维标准高基数内存膨胀、长期存储弱TDengine超级表子表SQL、Line Protocol、MQTT等SQL、RESTIoT建模高效、SQL友好复杂SQL能力有限TimescaleDBHypertablechunk压缩PostgreSQL SQL、COPYSQLSQL完整、业务JOIN方便超高频写入上限、压缩串扰QuestDB列存SIMD优化Line Protocol、PG wireSQL、REST写入吞吐高、ASOF JOIN企业能力需用云版、方言差异3. 统一测试口径下的性能实测别只看官方Benchmark各家官网的benchmark数字都很好看但测试条件完全不可比。我给团队做选型时从来不看宣传材料只认自己脚本在同一台机器上跑出来的相对差距。3.1 测试口径本次对比测试在一台8核32GB内存、NVMe SSD的单节点上进行模拟5000个设备、每设备20个测点、10秒上报一次的超集数据流并发16线程使用各产品官方推荐的批量写入方式。数据模型统一抽象成时间戳、设备ID、测点名、数值各产品用各自推荐的建模方式落地。查询测试分两组一组是“最近1小时全部序列按5分钟聚合”的常见看板查询一组是“全量数据范围扫描统计平均值”的分析型大查询。压缩率测试则用同样的原始点数统计落盘后实际占用空间。3.2 写入吞吐与压缩率对比产品写入吞吐万点/秒压缩率原始10GB说明InfluxDB 3.x约50~80压缩后约0.9GB批量写入到对象存储延迟受网络影响Prometheus约35~60压缩后约0.7GB抓取和remote write并存时吞吐波动TDengine约100~150压缩后约1.1GB批量写入缓冲强列存压缩吃数据规律性TimescaleDB约15~30压缩前2.5GB压缩后约0.9GB开启压缩后读多写少才合算QuestDB约80~120压缩后约1.0GB行协议批量写入效率极高这里的核心洞察不是谁第一而是压缩前的位数差异TimescaleDB不压岁时占用明显偏高必须把压缩打开才在存储上合算Prometheus压缩率虽好但它的压缩机制建立在float监控指标上存字符串事件和文本明细并不合适。3.3 查询延迟实测查询场景InfluxDB 3.xPrometheusTDengineTimescaleDBQuestDB看板聚合查询1小时/5分钟粒度低-中受缓存影响低但高基数时中低中低全量范围扫描聚合中-低高不适合长范围低中低多序列JOIN/业务关联中SQL增强后不可用中低最强中乱序数据写入后查询低中低中-高压缩块串扰低实测中最容易翻车的往往不是首屏看板而是“全量数据范围扫描”和“乱序写入后的查询”。这两个场景对存储布局极其敏感官方demo几乎不会覆盖但生产环境几乎一定会碰到。3.4 官方Benchmark里的水分在哪里各厂商的“百万点/秒写入”大多建立在高度批量、单指标单设备模型、低持久化保障的前提下。实际生产里写入往往是多协议混杂、乱序到达、部分写入失败重试性能会下降30%到50%都很正常。更关键的差距在持续运行八小时后内存是否稳定、阻塞是否累积、压缩任务有没有形成周期性抖动。所以我的建议很简单跑POC时一定压一个多小时至少覆盖一次compaction或压缩周期只看前十分钟的数字等于白测。4. 场景适配答案监控、IoT、金融、存量PostgreSQL各归各队性能数据只能回答“强不强”选型真正要回答的是“合不合适”。下面按我接触最多的五类场景给出结论。4.1 Kubernetes/微服务可观测场景Prometheus加VictoriaMetrics是稳妥组合如果你团队的核心诉求是K8s监控、POD指标、告警规则、Grafana看板那Prometheus几乎是默认答案生态和社区优势太大。真正要注意的是长期存储Prometheus本地保留时间拉到半年以上磁盘和内存都会吃紧。我的实践经验是用VictoriaMetrics对接remote write做长期存储既保留PromQL查询习惯又突破单机容量限制。预算充足也可以考虑Prometheus官方推荐的Thanos只是运维复杂度高一些。4.2 工业IoT与智慧城市场景TDengine是主推Apache IoTDB值得关注设备测点数量大、单点上报频率稳定、数据模型统一这类场景TDengine的超级表模型几乎是为它量身定做的。CDP、水表、电表、工业PLC建一张超级表加设备Tag就能统一管理。数据库还能直接订阅流式数据做实时计算少搭一套Kafka和Flink。如果是电力、钢铁这类有复杂层级测点关系的项目我也会把Apache IoTDB放进候选它的测点建模和边缘-云协同在极端工业场景更细。4.3 金融行情与量化事件场景QuestDB是性能取向的第一梯队行情数据写入峰值高、追求低延迟查询、经常要做不同证券代码之间的时间对齐QuestDB的写入吞吐和ASOF JOIN在这些需求点上非常能打。量化团队如果技术栈成熟可以直接用PG wire协议当PostgreSQL用周边工具基本兼容。不过要提醒一点如果对多机房高可用或细粒度权限是硬性要求自托管社区版不够需要上云版或企业版做评估。4.4 已有PostgreSQL团队做业务加时序混合TimescaleDB减压效果明显很多业务系统的订单表、设备状态表、用户行为表本来就是PostgreSQL在承载使用TimescaleDB可以少引进一套新数据库直接在现有实例里建hypertable。报表里有时序数据又要JOIN业务表的场景其他产品做起来很别扭TimescaleDB用原生SQL就解决了。数据量级在几亿到几十亿行、写入峰值中等的情况下它是最省事的选择。4.5 私有化超大集群与云原生长期留存InfluxDB 3.x走对象存储路线如果你的场景是SaaS平台统一采集多个租户的指标要求不丢数据、长期保留、容量弹性InfluxDB 3.x的架构优势就很明显。Parquet加对象存储意味着你不必提前规划容量存储扩容的对象存储里滚动完成。查询引擎基于DataFusion做向量化执行复杂聚合分析的性能不错。现在很多公司也在意AI异常检测能力3.x的Python插件能让训练和推理跑在数据同一侧省了数据搬运。4.6 场景决策速查表场景首选备选关键理由K8s/微服务监控PrometheusVictoriaMetrics监控闭环成熟、社区生态最大工业IoT/智慧城市TDengineApache IoTDB超级表建模、SQL接入、集群开源金融行情/量化回测QuestDBInfluxDB 3.x写入吞吐、ASOF JOINPostgreSQL存量团队TimescaleDB无复用SQL和运维栈云原生超大规模留存InfluxDB 3.xTimescaleDB Cloud对象存储无限扩展既有业务又有时序明细TimescaleDBInfluxDB 3.x全SQL关联能力强5. 真实踩坑复盘五个选型失误与补救方案这一节的内容全部来自我实际参与或近距离观察过的项目写出来是想让你少交点学费。5.1 把Prometheus当通用时序数据库半年后索引失控有个做物联网中间件的团队因为熟悉Prometheus就直接拿它存设备上报数据。初期数据量不大一切正常等设备规模上来、标签组合爆炸后内存被倒排索引吃掉了大半查询开始频繁超时。Prometheus的高基数是老生常谈但很多人还是会低估。补救思路是尽早给标签降维只保留必要维度把明细数据迁到专用存储里去Prometheus只保留聚合和告警。与其硬扛不如一开始就划清边界。5.2 只看到InfluxDB 3.x性能提升忽略了2.x迁移工程量另一个团队是存量InfluxDB 2.x用户听说3.x重写后性能大涨就急着升级做完POC才发现Flux任务全要重写Token鉴权方式变了一堆自定义仪表盘插件的查询接口不兼容。实际上如果现有系统运行稳定且对云原生扩展没有强烈需求继续留在2.x维护版也不失为选择要迁移就得按项目对待留足两周以上的兼容改造时间而不是当成一次普通版本升级。5.3 TDengine集群“免费”边界没确认扩容时才卡壳TDengine 3.x把集群能力开源了社区版的Raft多副本、SQL查询、流计算日常用没问题。但部分企业级能力比如更高级的多级存储策略、加密、专人技术支持商业版和社区版之间有明确边界。我有次在扩容评审时才发现团队原先以为全功能免费差点在合规上出问题。需求方最好在选型阶段就把部署规模、副本数、高级特性写清楚让销售或官方确认是否落在社区版能力范围内再走采购流程。5.4 TimescaleDB开启压缩后写入TPS直接掉档TimescaleDB的压缩确实省存储但压缩chunk后如果继续高频写入较老时间范围的数据会触发chunk解压和重写写入性能可能掉一个量级。某车联网团队设计保留策略时把chunk周期设成一天压缩任务总在夜间跑结果夜间恰好是数据补传高峰两边抢资源。解决方案是把chunk周期和压缩调度对齐业务波峰对乱序写入设置合理的时间边界不要让旧数据的写入撞上压缩窗口。5.5 QuestDB开发demo很顺手却栽在企业级权限与复制上QuestDB在开发机和单机demo上体验极好SQL风格类似PostgreSQL开发速度快。但到了生产环境多团队共用需要细粒度权限、跨机房容灾需要原生复制能力才发现社区自托管版覆盖不了得上云企业版。这类问题不是产品不好而是从开发到生产的鸿沟没提前看清楚。任何团队在选型时除了测SQL好不好写一定要把生产环境的权限模型、高可用方案、备份恢复一起纳入验收。6. 从需求到POC2026年时间序列数据库选型执行清单最后这套流程是我自己一直在用的不说能保证不踩坑但能把选型从“听厂商讲故事”变成“用数据做决策”。6.1 第一步量化数据生命周期与测点基数先用一周时间统计清楚每秒最大写入点数、总的活跃测点基数、数据保留多久、冷热数据比例大概如何。测点基数比数据总量更能影响性能和成本因为它直接决定索引和内存占用。计算存储成本时可以用这个估算公式存储量约等于点数乘以单点原始字节数大概12到20字节再除以目标压缩率6到12倍。跑完这一通统计很多模糊的选型问题其实已经排除一半了。6.2 第二步构建查询负载画像而不是整理长查询列表不要只列“我需要哪些SQL”而是要写清楚查询的触发方式、频率和延迟容忍度。比如“每5秒刷新一次的全租户聚合看板”和“每天跑一次的全量离线报表”对数据库的压力完全不同。把查询分成高频看板、中频报表、低频深度分析三类每种至少挑三条代表语句后续POC就按这个画像走。6.3 第三步用统一脚本跑三组测试总共三组测试缺一不可。第一组写峰值测试用大批次、多并发灌数据至少持续30分钟以上看吞吐、持久化延迟和背压表现。第二组压缩率测试灌入后等待完整压缩周期结束统计实际存储占用别用官方宣称压缩比拍脑袋。第三组长查询稳定性测试运行一小时全量扫描或变深度分析观察内存曲线、GC停顿、任务堆积现象。6.4 第四步把许可证和部署边界写进评估清单确认开源协议是真正的Apache/MIT还是AGPL集群功能是否完全免费企业版边界在哪数据出口有没有限制云服务商的托管版和自部署版功能是否一致。这些条款不看清后面上线扩容时会很被动。6.5 第五步让运维团队上手跑运维动作选型不只是选数据库也是在选未来的运维方式。让团队的运维同学在同一个环境下自己完成安装、版本升级、备份恢复、报警接入和故障演练。如果一套系统性能再好却没人会运维出了故障一周都恢复不了那它就是负债而不是资产。6.6 第六步用真实流量回放做最后决策我在最终决选时最重视的测试是真实流量回放。从生产环境导出一两个小时的写入流量和典型查询流量在每家候选产品上做回放同时记录资源占用和错误率。这个测试一般两三天就能做完但价值比任何PPT和benchmark都高。我的习惯是把这份执行清单打印出来逐项打勾等所有勾打完答案基本就浮出水面了后面开选型会时讨论的已经是执行细节而不是各执一词的口水仗。
最近帮几个团队做时间序列数据库选型评审发现2026年的选型难度反而比五年前更大了。五年前大家比的无非是读写性能和压缩率现在要考虑的却是对象存储架构、云原生部署、生态绑定、许可证边界甚至还要兼顾AI向量检索的延伸需求。市面上几乎所有主流产品都有试用版但很多团队用了两周反而更纠结——不是产品不够好而是没有一套清晰的选型口径把问题和场景对齐。这篇文章我会把InfluxDB 3.x、Prometheus、TDengine、TimescaleDB、QuestDB这五款主流产品放在同一套测试口径下拆开讲清楚重点回答三个问题每款产品的底层机制到底适合什么场景、真实性能表现和官方标称差多少、以及选型时最容易踩的坑有哪些。适合正在做监控平台改造的运维团队、物联网平台后端开发、量化行情数据组以及手里捏着PostgreSQL想顺便解决时序需求的业务团队。1. 2026年的选型环境为什么拿5年前的对比文章会翻车时间序列数据库这个概念这几年没有变但整个技术生态的底座已经换了一批。五年前的选型对比文章现在翻出来看很多结论已经不能直接照搬了。1.1 三个新变量改变了选型权重第一个变量是对象存储成为一等公民。过去时序数据库的容量规划基本都是围着本地盘转扩容靠加节点副本靠多节点复制。到了2026年主流产品基本都支持把冷数据放到S3、OSS、MinIO这类对象存储上本地盘只承担热数据缓存和写缓冲。这个变化直接影响成本模型从“按节点和内存付费”变成了“按存储量和查询量付费”所以压缩率、归档策略、冷热分层能力重新变成核心指标。第二个变量是数据接入方式统一了。OpenTelemetry在可观测性领域的普及让指标、日志、Trace的接入标准逐渐收敛物联网场景也在大量使用MQTT、OPC UA等协议网关。现在的时序库如果只能收自己的私有协议集成成本会非常高。五年前大家纠结的“推模型还是拉模型”如今在选型里的权重已经让位给了“能不能直接吃标准协议的批量写入”。第三个变量有点出人意料时序库开始承担AI/向量工作负载。TimescaleDB这两年明显在往pgai方向走把Vector、机器学习推理直接放进PostgreSQL生态InfluxDB 3.x也通过Arrow Flight和Python插件让数据可以无缝喂给模型训练。这意味着如果你未来有指标异常检测、预测性维护这类需求选型时就要看这个产品有没有能力在数据旁边跑推理而不是把数据倒腾出去再导回来。1.2 反直觉的成本结构反转我前两年帮一家智慧水务团队做评估他们的数据量大概一年10TB压缩后最开始想选一个内存占得少的轻量方案结果算下来存储成本反而成了大头。原因很简单时序数据写入后基本不再修改最贵的不是计算而是放得下、查得动、存得起。当对象存储按量计费、长期保留成为常态压缩算法强不强、冷热分层顺不顺手、生命周期策略能不能自动化这些细节对总成本的影响远大于单节点查询性能的30%差距。所以我在本文的性能对比里除了写入吞吐和查询延迟还专门加了压缩率对比。很多团队在POC时只看延迟上线三个月后才发现存储账单爆了这种案例我见得太多了。1.3 参测产品与版本边界说明为了不让对比失真我先约定说明本文讨论的InfluxDB是3.x系列Prometheus是3.x版本TDengine是3.x企业开源版TimescaleDB是2.x/3.x连续发布的当前版本QuestDB是面向云和自托管的最新版本。各产品的开源协议、集群能力和企业功能边界差异很大后文会专门出一节讲许可证和部署边界这里不展开。2. 五款产品的工作机制底层差异决定适配边界选时序数据库第一步不是比benchmark而是看它怎么存、怎么写、怎么查。存储模型一旦定了后面的性能和场景边界基本就锁死了。这一节我按每个产品的核心机制讲清楚。2.1 InfluxDB 3.xArrow/Parquet列存与对象存储优先的新架构InfluxDB 3.x是一次彻底重写底层换成了Rust加Apache Arrow和DataFusion存储格式用Parquet主打对象存储优先。写入路径是WAL加内存buffer然后批量flush成Parquet文件落到对象存储本地盘只做查询缓存。这个设计带来的最大改变是容量理论上可以随对象存储无限扩展且列存格式对范围聚合查询非常友好。但代价也很明显。首先是Flux语言在3.x里被边缘化官方主推SQL老用户从2.x迁移过来等于重新学一套API其次是查询延迟依赖缓存命中率纯冷数据首次查询会因为从对象存储拉文件而变慢。如果你已经在用InfluxDB 2.x要评估清楚迁移成本这个我后面在避坑章节专门说。2.2 Prometheus拉模型监控数据闭环是它的DNAPrometheus不能简单理解成一个“数据库”它是一个以抓取为中心的监控系统。服务端主动去拉取目标暴露的指标端点数据落进本地时序库再用PromQL做告警和可视化的闭环。这个模型在Kubernetes和微服务场景里非常自然因为服务发现和动态实例管理本身就是K8s的强项。它的存储引擎是按2小时一个block组织的block内有chunk压缩索引用倒排索引来支持快速标签匹配。问题也出在这里倒排索引常驻内存一旦指标标签基数涨起来内存消耗会很难看。Prometheus的定位永远是“监控系统的存储组件”而不是通用时序数据仓库拿它存业务明细数据是典型的用途错配。2.3 TDengine超级表建模对物联网场景的降维打击TDengine是五款里唯一把“物联网数据建模”作为设计起点的产品。它引入超级表概念一张超级表描述设备类型每个设备一张子表标签列和数据列分开存储数据按时间自动分片。这套模型对“成千上万个设备上报同一批测点”的场景非常匹配写入和查询都能顺着设备维度并行化。3.x之后集群能力全面开源支持多副本和Raft协议冷热数据多级存储也做进去了。最直观的好处是物联网平台后端不用再自己维护分库分表建表语句里写清楚标签查询直接写SQL学习成本比专用时序查询语言低很多。劣势是对通用SQL的覆盖不如PostgreSQL复杂嵌套子查询、多表任意JOIN的效率一般生态也相对年轻。2.4 TimescaleDB把时序能力“焊接”进PostgreSQLTimescaleDB走的是另一条路不重新造一个数据库而是做成PostgreSQL扩展。它通过hypertable把一张逻辑大表切成很多chunk每个chunk按时间分区、按分区键分片对应用层完全透明。所以你能用完整的SQL做任意复杂查询还能和普通业务表直接JOIN这是其他时序库很难给的自由度。它还有continuous aggregates本质是增量刷新的物化视图对“每小时聚合一次”“每天滚动统计”这类常规报表非常省心。压缩功能按chunk做行列混合压缩压缩率不错。但代价是PostgreSQL本身的写入吞吐上限在那里超高频写入场景会比专用列存引擎吃亏另外压缩后的chunk如果收到乱序写入会触发解压重写性能容易掉档。2.5 QuestDB为高吞吐事件流而生的Java列式引擎QuestDB在性能上有几个狠招列式存储、SIMD指令优化、Java层几乎无GC停顿。它原生支持InfluxDB line protocol和PostgreSQL wire protocol写入侧兼容性好插入吞吐做得非常高。最突出的是ASOF JOIN能把两个采样频率完全不同的时间序列按最近时间对齐做金融行情回测和传感器数据融合时非常顺手。但它的社区自托管版定位偏向单机原生高可用、细粒度权限这类企业功能更推荐用云版本。SQL方言与PostgreSQL接近但不完全兼容有些团队把开发环境的SQL直接上生产会踩坑。2.6 一张表看穿底层差异产品存储模型写入方式查询接口核心优势核心瓶颈InfluxDB 3.xParquet列存对象存储Line Protocol、SQLSQL、Flight SQL、Flux云原生扩展、无限留存2.x迁移成本、冷查询延迟PrometheusBlock倒排索引拉取/推送网关PromQL、HTTP API监控闭环成熟、运维标准高基数内存膨胀、长期存储弱TDengine超级表子表SQL、Line Protocol、MQTT等SQL、RESTIoT建模高效、SQL友好复杂SQL能力有限TimescaleDBHypertablechunk压缩PostgreSQL SQL、COPYSQLSQL完整、业务JOIN方便超高频写入上限、压缩串扰QuestDB列存SIMD优化Line Protocol、PG wireSQL、REST写入吞吐高、ASOF JOIN企业能力需用云版、方言差异3. 统一测试口径下的性能实测别只看官方Benchmark各家官网的benchmark数字都很好看但测试条件完全不可比。我给团队做选型时从来不看宣传材料只认自己脚本在同一台机器上跑出来的相对差距。3.1 测试口径本次对比测试在一台8核32GB内存、NVMe SSD的单节点上进行模拟5000个设备、每设备20个测点、10秒上报一次的超集数据流并发16线程使用各产品官方推荐的批量写入方式。数据模型统一抽象成时间戳、设备ID、测点名、数值各产品用各自推荐的建模方式落地。查询测试分两组一组是“最近1小时全部序列按5分钟聚合”的常见看板查询一组是“全量数据范围扫描统计平均值”的分析型大查询。压缩率测试则用同样的原始点数统计落盘后实际占用空间。3.2 写入吞吐与压缩率对比产品写入吞吐万点/秒压缩率原始10GB说明InfluxDB 3.x约50~80压缩后约0.9GB批量写入到对象存储延迟受网络影响Prometheus约35~60压缩后约0.7GB抓取和remote write并存时吞吐波动TDengine约100~150压缩后约1.1GB批量写入缓冲强列存压缩吃数据规律性TimescaleDB约15~30压缩前2.5GB压缩后约0.9GB开启压缩后读多写少才合算QuestDB约80~120压缩后约1.0GB行协议批量写入效率极高这里的核心洞察不是谁第一而是压缩前的位数差异TimescaleDB不压岁时占用明显偏高必须把压缩打开才在存储上合算Prometheus压缩率虽好但它的压缩机制建立在float监控指标上存字符串事件和文本明细并不合适。3.3 查询延迟实测查询场景InfluxDB 3.xPrometheusTDengineTimescaleDBQuestDB看板聚合查询1小时/5分钟粒度低-中受缓存影响低但高基数时中低中低全量范围扫描聚合中-低高不适合长范围低中低多序列JOIN/业务关联中SQL增强后不可用中低最强中乱序数据写入后查询低中低中-高压缩块串扰低实测中最容易翻车的往往不是首屏看板而是“全量数据范围扫描”和“乱序写入后的查询”。这两个场景对存储布局极其敏感官方demo几乎不会覆盖但生产环境几乎一定会碰到。3.4 官方Benchmark里的水分在哪里各厂商的“百万点/秒写入”大多建立在高度批量、单指标单设备模型、低持久化保障的前提下。实际生产里写入往往是多协议混杂、乱序到达、部分写入失败重试性能会下降30%到50%都很正常。更关键的差距在持续运行八小时后内存是否稳定、阻塞是否累积、压缩任务有没有形成周期性抖动。所以我的建议很简单跑POC时一定压一个多小时至少覆盖一次compaction或压缩周期只看前十分钟的数字等于白测。4. 场景适配答案监控、IoT、金融、存量PostgreSQL各归各队性能数据只能回答“强不强”选型真正要回答的是“合不合适”。下面按我接触最多的五类场景给出结论。4.1 Kubernetes/微服务可观测场景Prometheus加VictoriaMetrics是稳妥组合如果你团队的核心诉求是K8s监控、POD指标、告警规则、Grafana看板那Prometheus几乎是默认答案生态和社区优势太大。真正要注意的是长期存储Prometheus本地保留时间拉到半年以上磁盘和内存都会吃紧。我的实践经验是用VictoriaMetrics对接remote write做长期存储既保留PromQL查询习惯又突破单机容量限制。预算充足也可以考虑Prometheus官方推荐的Thanos只是运维复杂度高一些。4.2 工业IoT与智慧城市场景TDengine是主推Apache IoTDB值得关注设备测点数量大、单点上报频率稳定、数据模型统一这类场景TDengine的超级表模型几乎是为它量身定做的。CDP、水表、电表、工业PLC建一张超级表加设备Tag就能统一管理。数据库还能直接订阅流式数据做实时计算少搭一套Kafka和Flink。如果是电力、钢铁这类有复杂层级测点关系的项目我也会把Apache IoTDB放进候选它的测点建模和边缘-云协同在极端工业场景更细。4.3 金融行情与量化事件场景QuestDB是性能取向的第一梯队行情数据写入峰值高、追求低延迟查询、经常要做不同证券代码之间的时间对齐QuestDB的写入吞吐和ASOF JOIN在这些需求点上非常能打。量化团队如果技术栈成熟可以直接用PG wire协议当PostgreSQL用周边工具基本兼容。不过要提醒一点如果对多机房高可用或细粒度权限是硬性要求自托管社区版不够需要上云版或企业版做评估。4.4 已有PostgreSQL团队做业务加时序混合TimescaleDB减压效果明显很多业务系统的订单表、设备状态表、用户行为表本来就是PostgreSQL在承载使用TimescaleDB可以少引进一套新数据库直接在现有实例里建hypertable。报表里有时序数据又要JOIN业务表的场景其他产品做起来很别扭TimescaleDB用原生SQL就解决了。数据量级在几亿到几十亿行、写入峰值中等的情况下它是最省事的选择。4.5 私有化超大集群与云原生长期留存InfluxDB 3.x走对象存储路线如果你的场景是SaaS平台统一采集多个租户的指标要求不丢数据、长期保留、容量弹性InfluxDB 3.x的架构优势就很明显。Parquet加对象存储意味着你不必提前规划容量存储扩容的对象存储里滚动完成。查询引擎基于DataFusion做向量化执行复杂聚合分析的性能不错。现在很多公司也在意AI异常检测能力3.x的Python插件能让训练和推理跑在数据同一侧省了数据搬运。4.6 场景决策速查表场景首选备选关键理由K8s/微服务监控PrometheusVictoriaMetrics监控闭环成熟、社区生态最大工业IoT/智慧城市TDengineApache IoTDB超级表建模、SQL接入、集群开源金融行情/量化回测QuestDBInfluxDB 3.x写入吞吐、ASOF JOINPostgreSQL存量团队TimescaleDB无复用SQL和运维栈云原生超大规模留存InfluxDB 3.xTimescaleDB Cloud对象存储无限扩展既有业务又有时序明细TimescaleDBInfluxDB 3.x全SQL关联能力强5. 真实踩坑复盘五个选型失误与补救方案这一节的内容全部来自我实际参与或近距离观察过的项目写出来是想让你少交点学费。5.1 把Prometheus当通用时序数据库半年后索引失控有个做物联网中间件的团队因为熟悉Prometheus就直接拿它存设备上报数据。初期数据量不大一切正常等设备规模上来、标签组合爆炸后内存被倒排索引吃掉了大半查询开始频繁超时。Prometheus的高基数是老生常谈但很多人还是会低估。补救思路是尽早给标签降维只保留必要维度把明细数据迁到专用存储里去Prometheus只保留聚合和告警。与其硬扛不如一开始就划清边界。5.2 只看到InfluxDB 3.x性能提升忽略了2.x迁移工程量另一个团队是存量InfluxDB 2.x用户听说3.x重写后性能大涨就急着升级做完POC才发现Flux任务全要重写Token鉴权方式变了一堆自定义仪表盘插件的查询接口不兼容。实际上如果现有系统运行稳定且对云原生扩展没有强烈需求继续留在2.x维护版也不失为选择要迁移就得按项目对待留足两周以上的兼容改造时间而不是当成一次普通版本升级。5.3 TDengine集群“免费”边界没确认扩容时才卡壳TDengine 3.x把集群能力开源了社区版的Raft多副本、SQL查询、流计算日常用没问题。但部分企业级能力比如更高级的多级存储策略、加密、专人技术支持商业版和社区版之间有明确边界。我有次在扩容评审时才发现团队原先以为全功能免费差点在合规上出问题。需求方最好在选型阶段就把部署规模、副本数、高级特性写清楚让销售或官方确认是否落在社区版能力范围内再走采购流程。5.4 TimescaleDB开启压缩后写入TPS直接掉档TimescaleDB的压缩确实省存储但压缩chunk后如果继续高频写入较老时间范围的数据会触发chunk解压和重写写入性能可能掉一个量级。某车联网团队设计保留策略时把chunk周期设成一天压缩任务总在夜间跑结果夜间恰好是数据补传高峰两边抢资源。解决方案是把chunk周期和压缩调度对齐业务波峰对乱序写入设置合理的时间边界不要让旧数据的写入撞上压缩窗口。5.5 QuestDB开发demo很顺手却栽在企业级权限与复制上QuestDB在开发机和单机demo上体验极好SQL风格类似PostgreSQL开发速度快。但到了生产环境多团队共用需要细粒度权限、跨机房容灾需要原生复制能力才发现社区自托管版覆盖不了得上云企业版。这类问题不是产品不好而是从开发到生产的鸿沟没提前看清楚。任何团队在选型时除了测SQL好不好写一定要把生产环境的权限模型、高可用方案、备份恢复一起纳入验收。6. 从需求到POC2026年时间序列数据库选型执行清单最后这套流程是我自己一直在用的不说能保证不踩坑但能把选型从“听厂商讲故事”变成“用数据做决策”。6.1 第一步量化数据生命周期与测点基数先用一周时间统计清楚每秒最大写入点数、总的活跃测点基数、数据保留多久、冷热数据比例大概如何。测点基数比数据总量更能影响性能和成本因为它直接决定索引和内存占用。计算存储成本时可以用这个估算公式存储量约等于点数乘以单点原始字节数大概12到20字节再除以目标压缩率6到12倍。跑完这一通统计很多模糊的选型问题其实已经排除一半了。6.2 第二步构建查询负载画像而不是整理长查询列表不要只列“我需要哪些SQL”而是要写清楚查询的触发方式、频率和延迟容忍度。比如“每5秒刷新一次的全租户聚合看板”和“每天跑一次的全量离线报表”对数据库的压力完全不同。把查询分成高频看板、中频报表、低频深度分析三类每种至少挑三条代表语句后续POC就按这个画像走。6.3 第三步用统一脚本跑三组测试总共三组测试缺一不可。第一组写峰值测试用大批次、多并发灌数据至少持续30分钟以上看吞吐、持久化延迟和背压表现。第二组压缩率测试灌入后等待完整压缩周期结束统计实际存储占用别用官方宣称压缩比拍脑袋。第三组长查询稳定性测试运行一小时全量扫描或变深度分析观察内存曲线、GC停顿、任务堆积现象。6.4 第四步把许可证和部署边界写进评估清单确认开源协议是真正的Apache/MIT还是AGPL集群功能是否完全免费企业版边界在哪数据出口有没有限制云服务商的托管版和自部署版功能是否一致。这些条款不看清后面上线扩容时会很被动。6.5 第五步让运维团队上手跑运维动作选型不只是选数据库也是在选未来的运维方式。让团队的运维同学在同一个环境下自己完成安装、版本升级、备份恢复、报警接入和故障演练。如果一套系统性能再好却没人会运维出了故障一周都恢复不了那它就是负债而不是资产。6.6 第六步用真实流量回放做最后决策我在最终决选时最重视的测试是真实流量回放。从生产环境导出一两个小时的写入流量和典型查询流量在每家候选产品上做回放同时记录资源占用和错误率。这个测试一般两三天就能做完但价值比任何PPT和benchmark都高。我的习惯是把这份执行清单打印出来逐项打勾等所有勾打完答案基本就浮出水面了后面开选型会时讨论的已经是执行细节而不是各执一词的口水仗。
