2026年再看时间序列数据库，选型这件事比前几年难了不少。传感器、设备、容器、交易行情，几乎每个系统每秒都在产生带时间戳的数据，数据量是翻着倍往上涨，预算却不会跟着翻倍。最近我把5款主流的时间序列数据库在真实环境里重新过了一遍，从写入、查询、压缩、运维到迁移成本，一点点对比，越比越清楚一件事：不存在一款绝对最强的时序数据库，只有跟你业务场景匹配程度最高的方案。这5款分别是VictoriaMetrics、TDengine、TimescaleDB、InfluxDB、QuestDB，每一款背后都是一种完全不同的技术路线。这篇文章会把这些思路、测试数据和避坑记录都摊开来说，希望能帮你省下几周的调研时间。
1. 选型之前的三个问题：先别急着比性能
时间序列数据库选型最怕一上来就翻性能排行。同一个TSBS压测结果，换个数据模型、换套查询语句，排名可能完全反转。在真正测库之前，我建议所有团队先回答下面三个问题，这三个问题的答案基本决定了你能选的范围。
1.1 数据模型是标签优先，还是关系优先
时序数据模型大致分成三类。第一类是“metric + tag + timestamp + value”的扁平模型，Prometheus、InfluxDB、VictoriaMetrics都是这个思路，标签是维度,value是采样值。第二类是“超级表+子表+标签”的物联网模型，TDengine算典型代表，每个采集点一张子表，标签单独管理。第三类是关系型模型外挂时序语义，TimescaleDB直接在PostgreSQL表上做时间分区，QuestDB则是列存SQL引擎附带时序优化。
这个差异不是实现细节，它直接决定你后续怎么写查询、怎么做维度过滤、怎么压缩。如果业务数据本身就是设备A、设备B、设备C各自上报指标，那你用“一个设备一张子表”的模型会非常顺手；如果指标来源是一个全球化监控系统，维度非常杂，标签模型明显更灵活。选型第一步是盘点你的数据元数据，哪些维度会经常作为筛选条件，哪些维度只是展示字段，这决定了你未来建表的合理性。
1.2 查询负载是点查多，还是聚合分析多
时序库最常见的两种查询：精确取某个设备某个时间点的值，和跨时间段做降采样聚合（比如按小时或按天求平均）。不同引擎对这两种负载的优化思路差异极大。QuestDB用SIMD指令和列式存储把聚合做得飞快，尤其适合金融行情类数据；TDengine的窗口函数和超级表聚合写起来很顺畅；TimescaleDB的Continuous Aggregate则适合提前算好物化视图。
如果业务90%是实时监控图表，你可以忍受一些历史聚合查询慢；但如果要做量化回测，要扫描几天的分钟级行情数据，你必须重点考察列存能力、分区裁剪和SQL优化器。我见过不少项目，POC阶段只用点查和各大数据库都很容易完成的语句去压测，等上线跑两个星期才发现报表聚合查询慢到无法接受，被迫做二级缓存或更换引擎。
1.3 部署形态是自建、集群，还是云托管
自建集群需要考虑高可用、监控、备份、升级，每一项都要人力。InfluxDB开源版很长一段时间不带高可用，集群能力放在商业版里；TimescaleDB可以基于PostgreSQL生态自建，托管方案也比较多；TDengine从2.x到3.x逐步完善了集群和副本机制，但规模大了运维复杂度会上升；QuestDB现阶段单机场景更常见；VictoriaMetrics单机版很强大，集群版则要维护vmselect/vminsert/vmstorage三个组件。
每次在选型会上我都会问一句：团队里有哪些人有能力在这个数据库出问题时接手排查？如果答案是没有，那选型的优先级就要往托管版或商业支持倾斜，而不是单纯比性能。时序数据库是基础设施，基础设施最大的成本往往就是维护成本。
2. 5款主流产品拆解：每一款都代表一条技术路线
2.1 VictoriaMetrics：为Prometheus生态而生的高性能存储
VictoriaMetrics是这5款里我对它的好感度比较高的一个，因为它解决了一个很实际的问题：Prometheus自带的TSDB在大规模、长期存储场景下不太够用，而VictoriaMetrics可以无缝承接Prometheus生态。
它的核心能力是兼容PromQL和Prometheus remote write协议，同时提供一种增强查询语言MetricsQL。Prometheus原本只能存15天左右的数据（取决于配置和磁盘），远不能满足安全审计、容量规划类的“查一年前数据”的需求。VictoriaMetrics单机版就是一个二进制文件，配置起来非常简单，可以作为一个远程存储接收Prometheus推送的数据。它的存储引擎做了大量压缩优化，相同数据量下磁盘占用通常比原版Prometheus低不少，查询速度也更快。官方vmalert还支持告警规则评估，vmagent可以替代Prometheus做指标采集，结构上比传统“Prometheus+Thanos”方案轻不少。
在数据模型上它继承Prometheus的标签模型，所有维度都作为labels存在。优点是非常灵活，缺点是标签基数特别大时会消耗大量内存。实际使用中需要控制标签的数量和取值规模。我见过有些团队把HTTP状态码、用户ID都做成标签，结果时间线数量直接爆炸，查询变慢，存储膨胀。这种问题不是VictoriaMetrics独有，而是标签类时序引擎的通病。
适用场景非常明确：云原生监控、Kubernetes集群监控、Prometheus长期数据存储、可观测性平台。如果业务不是监控指标类数据，比如说需要存业务订单状态变化，它对SQL和明细数据检索能力都比较弱，这个时候选它反而别扭。
在部署和运维层面，我建议中小规模直接上单机版，配合两个副本或定期备份足够满足多数场景。当写入量超过单机能力、或者需要水平扩展时，再考虑集群版。VictoriaMetrics集群版由vmselect、vminsert、vmstorage三类组件组成，都是无状态的，相对比较容易做弹性扩缩容。但除非数据量真的非常大，否则单机版才是最省心的选择。
2.2 TDengine：面向物联网和工业场景的时序数据库
TDengine在国内工业物联网和能源管理领域用得非常广。很多项目选它，不是因为它单点写入性能有多么极限，而是它的数据模型非常适合“一批固定设备持续上报结构化指标”的场景。
TDengine从2.x时代就提出了超级表（STable）概念，超级表是一类设备的统一模板，每个设备对应一张子表，子表名就是设备ID，而设备的位置、型号、所属站点这些静态属性作为标签存储。查询时，你可以在这个超级表上直接写SQL，比如“select avg(current), max(temperature) from meters where location='北京' and ts > now-1h interval(10m)”。TDengine会自动根据标签过滤锁定一批子表，再进行时间窗口聚合。这种“先按标签裁剪、再按时间批量扫描”的模式，对物联网场景极其友好。
它内置的taosAdapter支持MQTT、OPC UA、Kafka等多种接入方式，对工业设备的数据采集很方便。2026年的版本在流式处理上也做得更细了，可以做一些简单的实时计算，比如温度越界告警、功率均值滑动窗口，不需要额外接一套流处理框架。
压缩率是TDengine的一个强项，它针对浮点数、整数做了类型相关的编码，比如差值、变长、压缩位图等，我在实际项目里存工业电表数据，压缩比能做到3到6倍，具体取决于数据规律。如果数据本身就是周期性波动，压缩率会更高。
当然TDengine也不是万能的。它的模型是schema-first，你最好在建库前把标签、字段、类型定清楚，后面频繁改字段结构会有成本。另外，如果你的数据维度高度依赖动态标签（比如每次上报都带一组不确定的业务属性），Tag模型不如InfluxDB那样灵活。TDengine集群部署起步有一定门槛，通常建议至少准备3个节点，数据副本数按扰灾要求配置。数据量不大时单机也够，但单机的吞吐会有瓶颈。
适用场景：物联网平台、工业自动化、设备状态监测、能源与电力数据采集、车联网数据管理。如果是这类业务，TDengine属于优先考虑的对象。
2.3 TimescaleDB：把时序能力做成PostgreSQL插件
TimescaleDB的思路和其他几家都不一样，它不重新写一个存储引擎，而是作为PostgreSQL的一个扩展，把普通PG表变成按时间分区的“超表”（Hypertable）。底层数据实际上还是存在PG表和块（chunk）里，但TimescaleDB会自动管理按时间维度的分区。
这个设计带来一个非常大的好处：团队不需要学一套新数据库。只要你会PostgreSQL，就会用TimescaleDB。包括JOIN、子查询、窗口函数、事务、视图、存储过程这些能力，全部继承自PG生态，迁移成本极低。我见过不少传统制造业的MES系统，原来用PostgreSQL存业务数据，后来要加设备指标存储，直接在同一个实例里CREATE EXTENSION timescaledb就完成了，业务开发人员完全不用换工具链。
TimescaleDB的Continuous Aggregate功能也做得比较成熟。比如你要求按一分钟汇总原始数据，但又要保留一年以上的历史，完全不必每次查询都扫描原始数据，可以建一个分钟级聚合的连续聚合视图，TimescaleDB会在后台自动增量刷新，查询走物化视图，速度提升非常明显。
压缩能力在2.x后做成了自动化策略，可以按chunk生命周期启用列式压缩。但前提是你得正确配置压缩策略，并且要理解压缩前后的查询性能差异。我自己实测下来，如果未开启压缩，TimescaleDB的存储占用会比专用时序引擎高不少，毕竟它背后是通用PG row存储。开启了压缩之后，磁盘占用大幅下降，但对更新删除操作有额外限制，所以冷热分层要提前想清楚。
限制也很明显：高并发写入能力不如VictoriaMetrics、QuestDB这些专属时序引擎。如果每秒需要写入几十万、上百万个点，TimescaleDB需要很好的并行和批量INSERT策略，否则容易成为瓶颈。还有就是要合理调PG参数，比如shared_buffers、work_mem、maintenance_work_mem，默认配置下大查询往往不会太好。很多人在POC阶段只是建了hypertable但没有做参数调整，然后说TimescaleDB慢，这个锅它背得有点冤。
适用场景：已有PostgreSQL技术栈、需要SQL复杂分析、业务数据需要和时序数据做关联的团队。比如订单交易数据分析、设备台账+采集指标关联、财务流水分析。
2.4 InfluxDB：老牌平台，生态成熟但集群成本要留意
InfluxDB是最早被大家熟知的时序数据库之一。2013年开源的1.x版本把“measurement + tag + field + timestamp”这套模型带火了，之后TICK栈（Telegraf采集、InfluxDB存储、Chronograf可视化、Kapacitor告警）在很多监控项目里落地，Telegraf的采集插件生态到今天仍然非常丰富。
2.x版本引入了Flux脚本语言，理念更强大，但学习曲线也上来了。很多人不喜欢Flux的“管道流”写法，觉得比InfluxQL复杂。3.x版本又做了比较大的架构调整，转向对象存储和Parquet格式，支持SQL查询，和Snowflake这类湖仓架构有了一些相似之处。从趋势上看，InfluxDB正在努力把自己打造成一个更大的可观测性数据平台，而不只是时序数据库。
它的优点是生态成熟、上手容易、文档多、案例多。Telegraf采集几百种常见的中间件、系统指标都有现成插件，对中小团队非常友好。高可用能力在开源版一直不是强项，想跑多副本、强一致性，通常要上商业版。到了3.x订阅许可也更复杂，成本要提前算清楚。另外，如果指标基数特别大，InfluxDB依旧会面临内存压力，即使3.x做了很多优化，高基数问题仍然是监控类场景绕不过去的坎。
适用场景：中小规模监控快速落地、系统指标和业务指标采集、物联网简单接入、想要TICK全家桶快速搭建平台的团队。如果你要支撑一个超大规模集群、复杂权限、强一致存储，InfluxDB的商业化和集群成本会让你很纠结，倒不如看看VictoriaMetrics或TDengine。
2.5 QuestDB：为低延迟分析而生的列存引擎
QuestDB是这批产品里性能取向最鲜明的一个。它采用列式存储，纯Java实现，大量使用SIMD指令优化，针对时间序列的扫描和聚合做了比较极致的优化。单机环境下跑时间范围聚合查询，尤其是秒杀级的低延迟，经常能在各种压测里排到前面。
它兼容PostgreSQL wire protocol和InfluxDB line protocol，所以像Grafana这种可视化工具可以直接接。金融行情、量化策略回测、高频数据分析是QuestDB最常出现的场景。比如统计某只股票过去一年每分钟的平均成交量，这种量级的表中做大窗口扫描，QuestDB的表现确实好。
但QuestDB的定位和适用边界也必须说清楚。它不是一个OLTP数据库，不支持复杂事务，同理它的集群高可用方案在过去几年一直在演进，没有成熟到像其他几家那样可以放心在生产环境跑多副本。它也不擅长频繁修改和删除数据，更适合“写一次、查多次”的数据分析模式。企业级功能比如细粒度权限、用户审计、数据生命周期管理，相比其他几家还是弱一些。
实际项目里我更倾向于把QuestDB当作“分析加速层”而非“唯一事实存储”。原始行情数据或日志先落到对象存储或消息队列，需要回测时导入QuestDB，用完可以清理。这套组合兼顾了成本和性能。
适用场景：金融行情分析、量化交易回测、需要超低延迟时间聚合的科研实验、流式数据快速探索和分析。
3. 关键能力横向对比：速度、压缩、易用性
3.1 测试环境与压测方法说明
为了给大家一个相对直观的参考，我自己搭了一套测试环境：8核16G内存、SSD，使用Docker部署各类数据库，数据是模拟的电力设备监控数据，1000台设备，每台设备上报30个指标，每10秒一条记录，连续写5个小时，一共产生大约5400万条记录。并没有做极限调优，都用各自推荐或者默认的配置启动，目的是观察一个中等规模场景下“开箱即用”的效果。
压测项目包括：批量写入吞吐、磁盘占用、最近一小时点查、一周数据窗口的降采样聚合、最后生成的压缩率对比。这里必须提醒，结果只代表我这次环境，不同硬件、不同数据特征、不同版本的配置都会改变具体数字，不要把它当作绝对标准。
3.2 写入性能对比
批量写入是时序数据库最关键的能力之一。默认配置下：
- VictoriaMetrics：支持Prometheus remote write和InfluxDB line protocol，写入速度很高，稳定在50万点/秒以上，甚至更高。
- TDengine：多线程批量写入表现不错，在30万到80万点/秒之间，和表数量、客户端并发相关。
- QuestDB：极快，采用批量INSERT或InfluxLine协议时，单机可轻松达到80万点/秒以上。
- InfluxDB：2.x/3.x版本在默认配置下大约20万到40万点/秒，高基数场景会下降。
- TimescaleDB：用PG的COPY或批量INSERT，可以到10万到30万点/秒，但并发优化比较考验PG调优能力。
这些数字不是极限值，只是代表一个比较“顺手”的区间。如果你的项目每秒需要写入百万级以上，那我建议要做更精细的压测，并且考虑分区策略、批量大小、磁盘选择。
3.3 压缩效果对比
我保留全部5400万条记录，观察磁盘占用。没有启用额外降采样和删除策略，尽量保证公平。
| 数据库 | 磁盘占用 | 参考压缩比 | 说明 |
|---|---|---|---|
| VictoriaMetrics | 约1.1GB | 4.2倍左右 | 压缩算法优化比较好，Prometheus场景优势明显 |
| TDengine | 约1.3GB | 3.5倍左右 | 对数值型数据压缩高效，需要合理设计分区 |
| QuestDB | 约1.5GB | 3.0倍左右 | 列存压缩不错，但会保留不少中间文件 |
| InfluxDB 3.x | 约1.6GB | 2.8倍左右 | 对象存储+Parquet后压缩率可以更高 |
| TimescaleDB（开启压缩） | 约1.7GB | 2.6倍左右 | 不开压缩会高很多，开启后效果明显 |
压缩率会影响存储成本，但也不要迷信压缩比，因为它和数据规律强相关。如果是随机浮点数、高熵数据，任何数据库压缩比都会很差。实际选型应该拿你自己的业务采样数据测一段时间，而不是用网上别人的结果直接拍板。
3.4 查询能力与生态差异
查询建模是选型时最容易被忽略的部分。我梳理了几个关键维度：
| 维度 | VictoriaMetrics | TDengine | TimescaleDB | InfluxDB | QuestDB |
|---|---|---|---|---|---|
| 主要查询语言 | PromQL / MetricsQL | 标准SQL | 标准SQL | InfluxQL / Flux / SQL | 标准SQL |
| 时序窗口聚合 | 强 | 强 | 强 | 中 | 强 |
| 复杂关联查询 | 弱 | 中 | 强 | 弱 | 中 |
| 降采样/连续聚合 | 支持 | 支持 | 支持 | 支持 | 支持 |
| 数据保留与TTL | 支持 | 支持 | 支持 | 支持 | 较弱 |
| Grafana集成 | 很好 | 很好 | 很好 | 很好 | 很好 |
| Prometheus生态 | 原生兼容 | 一般 | 需要适配 | 支持remote write | 支持remote write但生态少 |
把它翻译成人话就是：如果你的团队和监控生态绑定很深，VictoriaMetrics最自然；如果你习惯SQL且要做复杂的业务分析，TimescaleDB最顺手；如果你的场景是物联网设备为主，TDengine的超级表查询优势大；如果你只要极致的分析速度和低延迟，QuestDB值得考虑。
4. 场景适配选型：按业务场景直接给答案
4.1 云原生监控与可观测性：首选VictoriaMetrics
Kubernetes普及这么多年以后，监控方案基本固定在Prometheus生态里。Prometheus负责采集和告警规则，Grafana负责展示，但Prometheus自带TSDB的存储问题一直存在：数据超过一定规模后，查询慢、内存高、不好做长期留存。VictoriaMetrics把这个短板补得很到位。
你可以在Prometheus里配置remote write到VictoriaMetrics单机版，或者直接替换成vmagent采集，再让vmalert承担告警。整个链路都是轻量二进制，部署简单，磁盘占用低，查询性能好。配合Grafana也很流畅。
如果监控规模比较小，比如只有几万条时间序列，直接用Prometheus原生TSDB也够。但当数据量开始增长、需要查更长时间范围时，建议早点引入VictoriaMetrics，省得后面再做数据搬家。
4.2 物联网设备接入与工业运维：首选TDengine
物联网场景有几个特点：设备规模大、写入并发高、数据按设备查询、需要保留较长时间用来做趋势分析。TDengine的超级表模型天然就适合这种“按设备分类、标签筛选、时间聚合”的数据形态。
比如车联网平台，每辆车上报GPS、速度、电压等指标。TDengine可以把每辆车建为一张动态子表，车辆VIN号作为表名，车型、区域、运营商作为标签。查询“华东区域所有车最近一个月平均速度”就是一条SQL，它会自动过滤出相关子表再做聚合，非常清晰。
工业项目里我还推荐用TDengine自带的采集适配器，可以从MQTT或OPC UA直接写入，省了写一堆采集转发程序的功夫。如果完全没有关系型SQL经验，团队可能需要学习一下建库、建超级表的基本概念，但整体上手速度很快。
备选是InfluxDB，特别是在指标标签不固定、经常临时加字段的时候。但钱和性能需要自己权衡。
4.3 金融行情与量化回测：首选QuestDB或TimescaleDB
金融场景对时序数据库的要求很特殊：数据量大、精度要求高、查询多在超大时间窗口内做聚合运算，而且还要能快速迭代。QuestDB用列存加SIMD做窗口聚合，在行情回测里的性能非常突出，加上它兼容PostgreSQL wire协议，Python客户端接起来也很方便。
如果你还需要大量和衍生品合约信息、交易记录做复杂JOIN，那TimescaleDB更合适。因为QuestDB在这些关系型查询上还不如TimescaleDB灵活。量化交易系统通常不会只依赖一个数据库，往往是把几种存储组合起来：消息队列存实时流，QuestDB做快速分析，TimescaleDB或PostgreSQL存订单和账户数据，最后定期归档到对象存储。
4.4 已有PostgreSQL业务系统需要新增时序能力：首选TimescaleDB
这是TimescaleDB最舒服的位置。比如你有一个MES系统，原表在PostgreSQL里，现在要存每台设备的状态、功耗、温度，你不需要给项目再引入一套新数据库，直接在同一个实例里开启TimescaleDB扩展，把指标数据建为hypertable，SQL、备份、权限管理都统一。
很多团队的顾虑是“同一个实例会不会拖垮现有业务”。这个担心很正常，在生产环境最好用独立的PG实例或至少独立库来跑时序负载，避免大聚合查询拖累OLTP业务。TimescaleDB的部署方式灵活，可以用云数据库，也可以自建。
4.5 超大规模平台或统一分析栈：补充替代方案
如果你的数据规模已经大到每天几千亿个点，不是单机或几台机器能解决的，这时候需要认真评估一个更通用的分析型数据库ClickHouse或对象存储+数据湖方案。很多头部互联网公司会把时序数据定期从监控或设备平台中导出到ClickHouse，再对外提供大规模SQL分析。这个方向不在标题的5款之内，但确实是大数据团队常用的补充选项。
ClickHouse背靠广阔的生态，对标准SQL支持好，压缩率和查询性能都很强。但它不是专门的时序数据库，高并发写入冲突、UPDATE/DELETE模型都有不少限制。它更像一个通用OLAP分析引擎，如果业务类型单一聚焦时序，我用上面那些专用引擎的意愿会更高。
5. 实际使用中容易踩的坑：排障经验记录
5.1 高基数是全行业最恐怖的问题
高基数问题几乎会发生在每一款标签模型时序库里。有一次VictoriaMetrics集群查询突然变慢，我们排查了很久，最后发现有个开发同学在打点的时候把“用户ID”放进了label。用户量一大，时间线数量直接呈指数级增长，内存被索引占掉大半，查询性能也跟着崩。
后来我们把这类高维属性全部改成field，只在需要过滤的业务维度上用标签，问题立刻缓解。这个经验对所有Prometheus系和InfluxDB系产品都适用：能作为标签的维度一定要是低基数的、可枚举的。那些每次变化、取值特别多的值，请放到field里。
TDengine的标签也不是越多越好。虽然标签单独存储、过滤效率高，但超大基数标签同样会让超级表的管理成本上升。建议一个超级表的标签数量尽量控制在几十个以内，不要把所有业务属性都堆进去。
5.2 默认配置不能直接上生产
我见过太多团队在生产环境直接跑默认配置的时序库，高并发一上来就卡死，然后怪数据库不行。其实很多时候是“没喂饱”。不同产品调优的点不一样：
- VictoriaMetrics：注意内存限制参数，避免缓存占掉所有内存。
- TDengine：要根据磁盘和内存规划cachesize、pages、wal级别，还有数据落盘频率。
- TimescaleDB：必须调PostgreSQL的shared_buffers、work_mem、maintenance_work_mem、并行worker等，否则大查询压不住。
- InfluxDB：内存和series基数关系很大，热点分区、系列数限制要关注。
- QuestDB：配置JVM堆外内存和文件缓存的平衡，根据数据量预留足够内存。
任何人的最佳实践参数都不一定适合你，正确的做法是做一轮压测，压测时观察CPU、内存、IO和慢查询，再调参，再压测。没有捷径。
5.3 备份、恢复和升级策略必须在选型前确认
选型阶段最容易忽略备份。时序数据本身价值密度低，但不代表可以丢。尤其是做生产监控和金融分析的，丢失数据等于丢失事实。各产品的备份方案差异很大：
- VictoriaMetrics用vmbackup，支持对象存储，文档清晰，我比较推荐。
- TDengine用taosdump，但大数据量备份会非常耗时，需要提前测试。
- TimescaleDB可以用PG生态的pg_dump/pg_basebackup，不过数据量大的话物理备份更合适。
- InfluxDB 1.x和2.x的备份命令不通用，3.x又换了一套，迁移前一定先看官方文档。
- QuestDB有自己的快照机制，但整体生态经验少，可靠性要自己验证。
版本升级也容易踩坑。时序库长期运行，升级可能涉及在线迁移、数据重写，尤其是从2.x到3.x这种大版本更新，一定要先在测试环境完整演练一遍。
5.4 保留策略与降采样要从第一天设计
时序数据不像业务数据，没必要永远保留原始精度。很多人在POC阶段把所有数据都塞在热库里，等过了半年发现磁盘不够用，才开始想着清理。最好的做法是从建库第一天就设计好数据分层：原始数据保留1个月用于实时监控和最近问题排查，降采样到1分钟粒度保留1年，更早的数据归档到对象存储。
VictoriaMetrics有downsampling能力，TDengine有自动按时间分片和TTL，InfluxDB有retention policy，TimescaleDB有retention和连续聚合。关键是你要主动用，而且要定期检查是否真的执行了。我经常看到很多系统因为磁盘告警才发现保留策略没配置，或者配置了但是清理任务一直没跑。
5.5 不要只拿官方Benchmark做决定
每次选型都要提醒一句：网上的排行榜、官方压测结果，只能代表某个特定版本、特定配置下的结果。TSBS这类基准工具确实有价值，但它更像一个起点，不能代替针对业务数据的压测。
我建议的做法是：确定3个候选产品，各建一套单机环境，把你自己的真实数据（至少几天的数据）导进去，再写一组符合真实业务模式的查询，跑一遍看延迟、看资源占用、看操作难度，最后看维护成本。这个过程花不了多少时间，但能帮你过滤掉60%的不合适选项。
写在最后的一点经验
从这次重新评估来看，我最大的感受是：选型比调优重要一百倍，这句话在时序数据库这个细分领域尤其成立。很多团队愿意花好几周去压测，却不愿意花半天梳理业务的数据模型和查询模式，最后往往在一个不合适的模型上死磕调优，浪费更多时间。
如果再让我给一个最简版的选型方向：云原生监控优先看VictoriaMetrics，物联网和工业设备数据看TDengine，已有PG生态体系看TimescaleDB，金融行情和量化回测看QuestDB，中小团队想快速起步且接受生态偏向InfluxDB也完全可以。至于ClickHouse这类通用分析引擎，可以作为大规模分析层去补充，而不是替代专用时序库。
做选型时另一件很重要的事情是别忘记考虑数据增长。别只看眼前的写入量，要想想未来3年数据规模、查询复杂度、成本预算会发生什么变化。时序数据库迁移成本很高，采集端、查询端、可视化面板、告警规则、备份方案全部要跟着换，与其等两年再推翻重来，不如在一开始就把增长的余量留出来。
