你可以把量化交易的数据问题想成一间不断进货的仓库：交易员既要马上拿到刚送来的货，研究员又要翻查几年前的库存，而且两边最好看到同一套记录。逐笔行情越细，数据越多；如果实时系统和研究系统各存一份，还可能出现回测与实盘输入不一致。
Brevan Howard正在尝试用QuestDB承接这项工作。Brevan Howard是一家以全球宏观和利率交易著称的大型另类资产管理机构。QuestDB则是开源时序数据库——专门存储带时间戳、持续追加的数据，擅长按时间范围查询和聚合。
需要先说明信源边界：目前全部信息来自QuestDB于2026年7月17日发布、经GlobeNewswire转载的一份企业通稿，没有Brevan Howard官方声明或第三方材料交叉确认。
一套底座，两种速度
据QuestDB通稿，Brevan Howard已部署QuestDB，为实时及历史市场数据服务提供底层支持，使用场景包括系统化交易和交易前分析。
这里最棘手的是Tick数据，也就是逐笔报价或成交记录。它保留了市场变化的细节，适合研究执行成本和交易前状态，但数据量很大。系统一边要持续接收新记录，一边又要快速查询旧记录。通稿称，这套部署用于低延迟摄取和查询大规模Tick数据与成交数据。不过，材料没有给出吞吐量或延迟数字，因此“低延迟”和“大规模”只能视为QuestDB对部署目标与能力的描述，不能当作已经独立验证的性能结果。
QuestDB还提供一套面向资本市场的交易前分析工具。其中包括ASOF JOIN、Window Joins和Horizon Joins等原生SQL功能。SQL是查询数据库的通用语言；这些时间序列连接功能，可以按时间关系把不同数据表中的记录对齐。例如，分析某笔成交时，需要找到当时最近的一条行情，而不是机械地寻找时间戳完全相同的记录。
为什么实时与历史要共用数据
系统化策略通常先在历史数据上研究和回测，再被改造成能稳定接收实时数据、控制延迟并在故障后恢复的生产系统。这个过程叫“研究生产化”。难点不只在策略本身，也在数据接口：研究时看到的数据如果经过另一套清洗、压缩或对齐方式，实盘结果就可能偏离回测。
据通稿，QuestDB支持Parquet等开放格式——Parquet是一种便于存储和分析表格数据的文件格式，使同一批数据可以进入实时交易流程，也可以用于历史研究。这个设计的看点，不是简单地“换一个数据库”，而是试图缩短实时行情与历史分析之间的距离。
对专业交易机构而言，这类底座很少直接产生策略收益，却决定研究能否顺利进入生产环境。Brevan Howard的采用案例因此值得关注：它展示了头部宏观基金如何把逐笔行情、实时查询、交易前分析和历史研究放到同一套数据架构中考虑。
局限与未知
- 通稿没有说明这是整体重构、替换旧系统，还是局部部署，因此不能据此断言Brevan Howard“全面重做”了数据底座。
- 材料没有披露上线时间、部署规模、数据量、延迟、可用性、成本变化或与旧系统的性能对比。
- “覆盖市场数据全生命周期”“降低硬件需求”及“无供应商锁定”等说法来自QuestDB单方宣传，不能视为Brevan Howard的实测结论。