每年都有团队拿着不同的时序数据库选型报告来问我说实话这类报告“保质期”非常短。2026年再看时间序列数据库这个赛道格局已经和三五年前完全不同了可观测性、物联网平台、金融行情、车联网、工业数字化这几条主线同时爆发数据量从GB级一路冲到PB级选型不能再靠“谁写入快选谁”这种单一标准来判断。这次我基于实际项目和社区反馈挑了目前活跃度最高、社区成熟度最好的5款主流产品来做一个深度对比InfluxDB 3.x、TimescaleDB、TDengine 3.x、QuestDB和VictoriaMetrics。文章不会只列Benchmark数字而是围绕数据模型、存储引擎、查询能力、分布式架构、运维成本和场景适配来拆解最后我会直接给出一份“你对号入座”的选型建议。如果你正处在TSDB选型的十字路口这篇文章应该能帮你省下至少两周的调研时间。1. 为什么2026年还要重新聊TSDB选型需求侧已经变了先说个很反直觉的现象数据库技术发展得很快但今天最困扰选型团队的往往不是“功能不够”而是“选择太多、误区太多”。前几年大家选时序数据库核心诉求基本就是两条能扛住高频写入、压缩比别太离谱。很多项目连查询需求都没想清楚就上了车等到数据量级上来才发现产品在查询性能、运维复杂度、云原生适配这些维度上完全撑不住。到了2026年时序数据的使用方式已经发生了几个非常明显的变化。第一时序数据不再是“写入后就不怎么读”的冷数据。大量业务需要实时做异常检测、降采样、滚动聚合、同比环比甚至把时序特征直接喂给AI模型做预测。这要求数据库不仅写得好还得查得好特别是对时间窗口类查询、多维聚合要有体力。第二数据规模上了新台阶。一家中型物联网平台一天的采样点就可能达到百亿级一套Kubernetes集群的可观测性数据单月的指标序列也动辄几千万条。这直接逼着数据库在列式存储、高压缩率、对象存储对接这些方向上做到极致否则成本和运维根本扛不住。第三团队基因开始反过来决定选型方向。有的团队能接受一套类SQL的学习成本有的团队只有Prometheus生态背景还有的团队业务本身就是重度PostgreSQL用户。产品再强如果和团队已有技术栈完全不搭落地一样是灾难。所以这次对比我不会脱离业务场景去空谈“谁最强”而是把每款产品的“性格”讲透再告诉你它在什么场景下值得用、什么场景下千万别碰。下面是参与对比的5款产品。2. 参评的5款主流产品定位、血统和各自“性格”2.1 InfluxDB 3.x从独有存储引擎走向列式湖仓一体InfluxDB是很多人接触时序数据库时的第一站。早期版本靠自研的TSM引擎和InfluxQL打天下生态里Telegraf、Chronograf、Kapacitor这一套TICK组合非常经典。但从3.x开始InfluxDB选择了把存储层彻底重构废弃原来的纯LSM路线的TSM架构转向以Apache Arrow Parquet为底层文件格式的列式存储并且允许直接对接对象存储S3、MinIO等作为持久化层。这意味着2026年的InfluxDB 3.x在架构上更接近“湖仓一体”数据落地是Parquet文件计算层可以下推既保留它原有的时序写入语义又获得了更好的压缩效率和更灵活的查询引擎。对于已经深度使用InfluxQL或正在考虑云上托管时序方案的团队这会是一个熟悉又陌生的InfluxDB。但它也有需要适应的点Flux语言在3.x里基本让位给了更主流的SQL如果你过去的存量查询大量依赖Flux迁移需要重新评估。2.2 TimescaleDB扛着PostgreSQL大旗的时序“套件”TimescaleDB给人的感觉不像一个“新数据库”更像一套精心设计的PostgreSQL扩展。它通过把时序数据自动按时间切片成chunk对外呈现一张统一的Hypertable超表从而让应用层几乎无感知地享受时序优化能力。PostgreSQL的血统给它带来两个巨大优势一是SQL能力完整和普通业务表做JOIN、用窗口函数、跑GIS查询都是顺手的事二是生态极其丰富PostgreSQL的备份恢复、监控运维、迁移工具等全都能复用。它的压缩能力也升级得很务实把行存数据按列压缩对设备数据、监控数据的压缩比相当可观。如果你所在的团队本来就是PostgreSQL重度用户TimescaleDB的学习成本和长期维护成本都会非常低。2.3 TDengine 3.x面向物联网的集群原生方案TDengine从诞生之初就明确瞄准物联网、工业互联网场景。它的核心设计里有两个很突出的点其一是“超级表子表”模型把设备元数据抽象成标签Tag时序数据按设备打散存储天然适合设备和点位海量、每个设备独立采样的场景其二是原生集群能力不需要额外依赖HBase、ZooKeeper之类的第三方组件装好就能组集群多副本、高可用、负载均衡都是内置的。到了3.xTDengine在存储引擎和流式计算方面做了不少重构整体架构更偏向云原生既可以通过传统方式部署也能跑在Kubernetes上。它的语法看起来像SQL但在建库、建表、分区、窗口语义上有自己的一套约定刚上手时不能完全当标准SQL用。如果你只想在物联网场景里快速落地一套能横向扩展的时序平台TDengine的集成度和整体一致性是五款里最让人省心的之一。2.4 QuestDB单机性能狂魔SQL基因纯正QuestDB是这5款里“内功”最特别的一个。它用Java实现却在性能优化上做到非常激进底层用SIMD指令加速数据扫描写入路径按追加模式优化查询引擎针对时序窗口聚合做了大量精细调度。官方展示过的百万行/秒以上写入吞吐和秒级聚合能力在实际的单机压力测试里确实也经常让人觉得惊艳。更重要的是QuestDB支持的是“正宗”SQL而不是类SQL。时间序列语义通过SAMPLE BY这类扩展实现这让熟悉标准SQL的工程师上手阻力非常小。它还兼容InfluxDB的行协议Line Protocol所以很多原来用InfluxDB的采集端可以直接把数据转投过来。不过QuestDB开源的分布式能力和更新删除能力相对有限它更适合单个工作节点就能扛住的归档查询、金融行情、低延迟分析这类场景。2.5 VictoriaMetrics云原生监控场里的高性能Prometheus兼容库如果你在维护Kubernetes或做可观测性平台大概率早就听过VictoriaMetrics的大名。它最初是作为Prometheus的高性能远程存储后端出现的兼容Prometheus查询语言还推出了更强的MetricsQL可以在不改变现有监控体系的前提下把指标存储规模和查询性能提升一个量级。VictoriaMetrics的定位非常清晰指标、监控、告警、降采样。它默认的数据模型就是带标签的指标序列和Prometheus的label思想一脉相承。部署形态上既有零依赖的单机版单个二进制解决也有拆分成vminsert、vmselect、vmstorage的集群版运维起来比动辄依赖一堆组件的分布式方案轻得多。它最不擅长的是和业务表做关联因为它根本没有关系模型但在可观测性这个垂直赛道上它几乎是当前最值得优先考虑的开源自托管方案。下面先用一张表把这5款产品的基本信息拉通一下方便你建立整体印象。产品许可证存储引擎部署形态最擅长场景InfluxDB 3.xMIT/商业双许可列式Parquet对象存储单机/云原生集群能力偏商业版通用时序平台、可观测性、事件流TimescaleDBTimescale License/Apache 2.0PostgreSQL行存列存压缩PostgreSQL扩展支持单机/多节点关系型业务时序混合场景TDengine 3.xAGPL/商业双许可自研列式时序存储引擎原生集群云原生友好物联网、工业互联网大规模设备接入QuestDBApache 2.0自研列式存储mmap单机为主官方云托管高吞吐写入、低延迟窗口聚合VictoriaMetricsApache 2.0自研列式块压缩存储单机或集群Prometheus生态、Kubernetes可观测性3. 存储与压缩机制决定成本和性能的底层胜负手选时序数据库很多人一上来先比每秒写入行数但半年后真正让架构师头疼的往往是磁盘成本和查询性能。这两件事的根子都在存储引擎的设计上。3.1 存储模型的分岔路列式原生、行存扩展、还是混合形态2026年仍然有产品使用LSM树风格的行式存储吗有比如一些老牌依赖还保留但主流趋势已经明显偏向“列式优先”。原因很简单时序数据的查询大多是扫描某个时间范围内的大量点位列式存储只需要读取涉及的列压缩率高、IO开销小聚合计算也顺手很多。InfluxDB 3.x从头改用Parquet列式文件本质是把“时序写入”和“分析查询”两种负载在存储层做了一个折中写入时先收集到内存并排序再按批次落成高效的列式文件长期数据可以直接躺在S3这类对象存储上。这个设计对高吞吐写入不是问题但如果业务对“写入后立即能查到几秒内的最新值”有强需求就要额外注意缓存层和查询路由的配置。TimescaleDB走的是另一条路默认行存数据进PostgreSQL的堆表配合压缩策略可以透明转成列存。这样常规业务查询、事务、实时写入都保持和普通PostgreSQL一致只有到了阈值才触发压缩。它的好处是灵活坏处是如果你对查询性能要求极端苛刻纯行存的开销仍然存在。好在PG生态成熟你可以用连续聚合、物化视图等手段把热数据查询成本压下来。TDengine在3.x里进一步强化了列式存储能力。它的底层把每个时间分区的数据按列组织配合标签索引进行过滤在多设备多测点的大规模扫描场景下优势明显。加上它针对时间戳、整型浮点做了专属编码存储引擎的“时序味道”特别浓。QuestDB的存储思路也很纯粹每个表按列拆成独立文件使用内存映射方式读取查询阶段疯狂利用SIMD做数据并行扫描。这让它在纯时序聚合场景里能跑出很高的单机性能。但它的架构更偏向append-only如果你有高频的更新删除需求它并不是第一选择虽然新版本对upsert有一定支持。VictoriaMetrics则是典型的高密度列式块存储写入数据按压缩块编码块内部时间戳和值都用类似优化编码的变种处理再叠加全局索引。它不会把数据丢给外部对象存储而是自建分片目录管理简洁、稳定、压缩比高尤其适用于指标持续累积的监控场景。3.2 压缩算法与压缩比Gorilla家族、Delta编码与ZSTD的较量讨论压缩比之前先理解时序数据的规律同一指标的时间戳间隔稳定、数值波动有限这给压缩算法留下了很大空间。目前主流方案基本都吸收了Gorilla论文的路线对时间戳和浮点值做变长编码、异或存储能极大压低每个采样的比特数。InfluxDB 3.x的Parquet文件本身支持Snappy、ZSTD等通用压缩同时对时间戳和连续数值也会做编码优化TimescaleDB压缩底层也是列式化之后用LZ4、ZSTD这类算法压缩TDengine自研编码对常见设备数值做了专门优化QuestDB默认对流式数据做轻量列压缩支持压缩选项但侧重性能VictoriaMetrics在时间戳编码和浮点XOR编码上做了很多精细打磨实测压缩比在监控场景下常常说得上是第一梯队。我在同一个设备采样项目里用同一批数据做过粗略对比原始数据大约是1.2TB的JSON和CSV混合导入到5款产品后磁盘占用分别是InfluxDB 3.x约35GB、TDengine约28GB、TimescaleDB经压缩后约45GB、VictoriaMetrics约30GB、QuestDB约55GB。当然这个对比并不严格和字段类型、数据规律、压缩阈值设置都有关系但量级差异基本能反映现实压缩率是决定长期成本的第一要素。至于怎么选我给个实用建议在做POC的时候一定要把“真实数据压缩比”当成第一项产出指标而不是拿官方宣传的数字来估算费用。3.3 写入路径上的热点乱序写入和去重策略时序写入的理想状态是“时间戳单调递增依次到达”但实际上乱序数据太常见了断网补偿上报、网关缓存重传、设备时钟漂移都会让数据库收到比当前时间更早的数据点。乱序写入对LSM类存储并不致命但会显著放大写放大。InfluxDB的写入模型天然接受乱序多副本一致性靠自身机制处理TimescaleDB对乱序数据写入到超表中也比较成熟但过度乱序会让chunk合并压力变大TDengine要求时间戳尽量有序3.x对乱序的处理已经改善很多但性能最好的状态仍然是规整的追加写入QuestDB的优化则明显绑定了有序追加如果你的采集端乱序率很高写入性能会明显下滑VictoriaMetrics在块合并过程中需要处理乱序样本大量乱序会造成比较高的CPU和IO开销。我自己踩过的真坑是某项目在接入端加了一层缓冲和批量重排把乱序率控制在5%以内QuestDB的单节点写入吞吐直接提升了大约3倍。这说明很多时候瓶颈不在数据库本身而在于数据管道有没有做对齐。去重机制同样值得关注。InfluxDB和VictoriaMetrics都默认对同一序列同一时间戳的重复数据“后者覆盖前者”TimescaleDB可以在PG约束层面实现唯一键去重TDengine按主键时间戳和标签维度去重QuestDB支持按主键时间戳upsert。选型时你需要明确业务到底允不允许同序列重复上报如果允许要多线程并行去重如果不允许就要在写入层把唯一标识设计好。4. 查询能力SQL是门槛时序语义才是灵魂存储层决定你花钱的下限查询层决定你干活的上限。这一节我会把每款产品的查询语言和特色能力拆开讲因为很多选型失败都是“只看了写入性能没看查询语法是否符合团队经验”。4.1 查询语言的统一硝烟SQL正在重新成为最大公约数2021年前后时序数据库的查询语言还分成好几大阵营InfluxDB的InfluxQL和Flux、Prometheus的PromQL、TDengine的类SQL、TimescaleDB和QuestDB的标准SQL。到了2026年格局已经明显收敛SQL成为了绝对主线连InfluxDB 3.x都大力强化标准SQL支持Flux基本退居停滞维护状态。VictoriaMetrics虽然主打PromQL兼容但也提供了SQL-like的查询视图和更多算子MetricsQL整体复杂度大幅提升。从团队招聘和协作效率来看标准SQL习惯的团队在接入TDengine、QuestDB、TimescaleDB时几乎是无痛的InfluxDB和VictoriaMetrics则更适合已经熟悉对应查询范式、做监控告警系统的同学。如果你团队里两种人都很多建议优先选择SQL更流畅的产品因为培养一个新的PromQL专家比培训一个读得懂SQL的工程师难得多。4.2 时序专用能力连续聚合、窗口采样与降采样光有SELECT和GROUP BY还不够时序查询的真正灵魂是“时间窗口上的聚合”。下面我拿一个常见查询“每台设备最近7天每小时的平均温度”为例展示5款产品的表达方式差异方便你快速感受语法亲和度。如果用的是QuestDB一个SAMPLE BY 1h就搞定面向时间戳的窗口查询然后叠加WHERE和GROUP BY这是目前最符合SQL直觉的写法。如果用的是TimescaleDB可以写time_bucket(1 hour, ts)做时间分桶再配合普通的GROUP BY连续聚合可以直接把每小时结果实时维护成一张物化视图查询时连原始表都不用碰。如果用的是TDengine写INTERVAL(1h)进行时间窗口切分结合超级表和标签过滤器PARTITION BY tbname很方便虽然语法细节有独特性但语义清晰。如果用的是InfluxDB 3.x既可以用SQL函数处理时间窗口也保留InfluxQL的GROUP BY time(1h)写法存量脚本迁移成本低。如果用的是VictoriaMetrics那得从监控视角去思考更常见的是rate()、increase()、rollup_rate()这类算子面向“指标在窗口内的变化率/总量”预聚合而非纯粹的SQL聚合。此外降采样能力几乎是所有产品都在卷的方向。TimescaleDB的连续聚合、TDengine的流式窗口、InfluxDB历史数据下推到对象存储时的裁剪查询VictoriaMetrics的downsampling在实际项目中都能帮你把长期历史数据的查询成本降下来。我的经验是要在POC阶段就把“一年后的历史数据查询SLA”写进验收标准因为很多产品冷热数据表现差异极大。4.3 关联查询能力纯时序库与关系型时序库的天然差异时序数据本身只有“序列时间戳值”但业务查询往往要关联资产档案、设备型号、地域站点这些非时序元数据。这一点如果你依赖的是PostgreSQL扩展的TimescaleDB优势会非常明显可以直接和业务表做任意JOIN甚至通过PG的FDW扩展访问外部系统。TDengine用标签设计部分化解了这个问题把不常变的元数据作为标签查询时标签过滤和聚合可以下推到存储层性能和便利性都很好。但如果你需要和三方业务库做深度JOIN还是得把数据导到分析系统里。InfluxDB和VictoriaMetrics的思路都是“把元数据塞进tag/label”这适合简单等值过滤遇到复杂的元数据关系比如一个设备绑定多个维度、维度还会动态变化就会很吃力。QuestDB支持SQL JOINS跨表关联能力在单机内也够用但它的定位决定了你不该拿它当“业务数据库”来设计关系模式。5. 从单机到集群架构演进、运维边界与成本核算很多团队一开始都是从单机试用开始跑着跑着发现要扩容、要高可用、要容灾。这个阶段才发现最开始没搞清楚“分布式能力到底是内置的还是商业版的”是选型里最痛的坑。5.1 各产品的分布式形态原生集群、外部依赖与商业化限制TDengine 3.x在集群能力上是开源里最不含糊的安装部署不需要额外组件多副本、负载均衡、节点故障切换都是内建能力用起来的方向很“数据库原生”。如果你做的是物联网需要组织多个边缘节点、汇聚到中心集群它的接入层组件和集群拓扑管理能省不少心。InfluxDB 3.x开源版在集群能力上相对保守。它把分布式和云原生管理能力更多放在商业化版本里开源版很适合单机或小规模独立部署但如果你想快速横向扩展成多节点集群要去了解商业授权的边界。VictoriaMetrics集群版是开源的组件拆分清晰但它不提供自动分片后的强一致性容灾机制多副本策略需要自己搭配好在外围有vmagent、vmalert等配套可观测性领域用起来非常顺手。QuestDB开源版长期主打单机也对“高可用能力”放在企业版/云托管版里做得更完整。如果你只跑一个高吞吐节点它省心一旦要跨地域容灾得认真看官方托管方案或自己搭复制链路。TimescaleDB的单实例能力和PostgreSQL生态完美绑定但它真正的多节点能力访问节点数据节点相对更适合“少写多读、业务拆分清晰”的场景并且运维复杂度比单PG实例高不少。5.2 高可用与容灾的实操姿态除了备份还要考虑恢复RTO选型时不光要问“支不支持多副本”还要问“节点挂了多久能恢复”。我见过不少团队选了带多副本的产品但因为没用对部署形态故障恢复时长依然以小时计。如果以自托管方式部署TimescaleDB的恢复基本等于PostgreSQL恢复备份工具、PITR时间点恢复都能复用TDengine原生集群支持自动选主和数据副本恢复速度取决于副本数量和网络状态VictoriaMetrics推荐把storage数据盘和外部备份搭配使用或者利用集群版副本策略来抗单节点故障InfluxDB 3.x长期数据在对象存储上节点本身更多是“无状态缓存”的形态恢复数据的路径反而更像云原生应用QuestDB则要看是否启用了官方的高可用方案否则单机故障时恢复会很被动。高可用复杂度从低到高排序的话在我个人经验里是TDengine原生集群做得好、TimescaleDB托底靠PG生态、InfluxDB 3.x云原生形态更吃基础设施、VictoriaMetrics需要自己拼副本、QuestDB要依赖商业版或旁路方案。这句话仅供你把评估重点放在“用现有团队人力是否兜得住”上。5.3 算一笔账同样100亿条/天存储和内存成本差多少我直接用一组便于理解的估算数据来演示。假设你每天写入100亿条采样点每条采样包含时间戳、一个设备ID标签和一个浮点测值去掉各种协议开销后原始数据量大约1TB/天保留90天就是约90TB原始数据。InfluxDB 3.x落盘Parquet压缩后估算总存储约为20TB到35TB取决于标签基数和数值规律因为默认架构贴近对象存储磁盘成本还和所选对象存储单价强相关。TimescaleDB未压缩前约90TB如果启用了列式压缩实际落盘约25TB到45TB。TDengine自研编码后设备数据压缩率往往很可观估算约20TB到40TB。QuestDB默认压缩和段文件管理起步约40TB到60TB它更追求查询性能存储成本相对偏高。VictoriaMetrics监控场景的列式和块压缩效率很高按相同保留周期估算约18TB到30TB。内存方面差异更微妙InfluxDB 3.x依赖内存缓存来保鲜热数据SQL查询并发高时内存会明显上涨QuestDB用mmap映射列文件一定程度上把内存压力交给了OS页缓存TDengine的内存占用和vnode数量相关需要仔细规划写入并发TimescaleDB的内存和PG共享同一套buffer pool调优方法有大量资料可依。“花多少钱”不能只看存储还得算节点资源、副本数、备份存储和运维人力四笔开销。6. 场景适配决策表拿你业务的对号入座聊完底层能力最后进入最关键的落地环节。我给每一个主流场景给出推荐排序和理由建议不要直接照抄而是核对一下你所在团队的真实约束。6.1 物联网/工业设备接入首选TDengine其次InfluxDB 3.x物联网最大的痛点是“设备数量多、点位多、很多设备有间隔上报”这种模式在数据库层面经常表现为高基数序列和海量小步长写入。TDengine的超级表标签模型和原生集群在IoT场景里属于“长在自己的赛道上”设备元数据用标签存采集值用数据表存扩容甚至不用停服务。InfluxDB 3.x适合那些已经有Telegraf采集体系或需要处理非结构化标签业务的团队。如果要接的设备协议五花八门InfluxDB生态的采集器组合会更灵活。QuestDB和VictoriaMetrics在物联网场景都能用但前者对乱序写入的容忍度有限后者则缺少真正的设备档案管理语义长期都会给你找额外的事。6.2 云原生监控与可观测性VictoriaMetrics是当前最顺的选择如果你的核心场景就是Prometheus指标、Kubernetes监控、告警数据、SRE SLO那VictoriaMetrics在2026年的地位基本是自托管监控后端的默认答案。它兼容Prometheus协议又提供了指标量分析更顺手的MetricsQL单机版一个二进制就能扛下大量指标且不需要引入复杂的对象存储组件。InfluxDB 3.x在可观测性也能做但它的强项更多是“多类型可观测数据统一存储”指标、事件、Trace都可以落进去。如果团队原本就是Prometheus生态迁移到VictoriaMetrics比去学一套全新平台要快得多。6.3 金融行情/高并发窗口聚合QuestDB和单机极限性能派金融行情场景的特点是单机也能承受很高流量查询通常是集中在一个标的上的时间窗口快照、最新价、分钟聚合、K线计算。QuestDB在低延迟聚合、SQL窗口函数和内存映射读取方面几乎没有对手单节点能扛下的负载远超传统关系库甚至一些分布式TSDB。当然如果是大盘级别的多市场全量行情可能需要拆分成多分片再汇聚此时QuestDB开源的单节点瓶颈就会出现。这种场景下也可以考虑把QuestDB当热数据节点冷数据落到其他列式平台。VictoriaMetrics做了监控优化不适合金融K线的精确语义TDengine的窗口聚合也很强然而低延迟回放不如QuestDB在极致压缩中快。6.4 关系型业务与时序数据混合TimescaleDB几乎无痛承接如果你的业务本来就跑在PostgreSQL上时序数据只是业务数据的一部分比如用户行为留存、订单生命周期里的状态变更、设备档案和采样值同时要查那我非常推荐直接在PostgreSQL上加TimescaleDB扩展。它最大的价值是让团队不用引入第二套技术栈业务表和超表之间可以透明地JOIN运维、权限、备份全都统一。InfluxDB 3.x和TDengine对“元数据深度关联业务库”的场景都不如TimescaleDB自然。你可能会说“可以把元数据冗余进tag”但一旦元数据频繁修改tag更新会变成一场数据治理噩梦。时序建在关系型之上反而会让一辈子心累。一张场景决表与选型前的POC建议按场景快速给一个不绝对但大概率正确的决表核心诉求首选次选避雷提示物联网平台、海量设备接入TDengineInfluxDB 3.xQuestDB对乱序写入敏感云原生监控、Prometheus生态VictoriaMetricsInfluxDB 3.xTimescaleDB不是监控体系自带组件金融行情、低延迟聚合QuestDBInfluxDB 3.x多节点强一致需额外方案PostgreSQL体系内做时序TimescaleDB不推荐硬换别动辄引入第二套存储通用时序平台、数据中台InfluxDB 3.xTDengine新老版本查询语法差异要盘清最后聊聊我自己的习惯。每当我需要给一个新项目出选型结论我不会只看产品能力表而是先带着真实数据做一轮为期两周的POC验证三件事一是压缩率和写放大二是高频查询的P99延迟三是故障恢复演练时团队能不能按手册操作。这个过程通常比所有网上对比文章都有价值因为只有你自己知道“一天100亿条数据”在你们机房里的真实模样。再分享一个很多人都忽略的小技巧选型时一定要把“历史数据的生命周期管理”顺便问清楚。很多项目半年后才发现清理旧数据不是简单的DELETE而是和压缩、分区、对象存储归档强相关的操作。谁能在你的运维体系里把数据像流水一样安全地流进、存住、流出谁才是最后留到生产环境里的那个数据库。