分拆系统vs集成系统：分拆的目标是广度而非深度

即便[[联合数据库与分拆数据库统一读取与统一写入两条路径]]描绘的分拆方式真正成为未来主流，它也不会取代现有形式的数据库——为流处理组件维护状态、给批处理和流处理器的输出提供查询服务，仍然离不开数据库；MPP数据仓库这类专用查询引擎针对特定工作负载（如探索性分析查询）优化，依然表现出色。运行多种不同基础设施本身就有代价：每种软件都有自己的学习曲线、配置问题和运维怪癖，因此部署尽可能少的活动部件永远是有必要的考量；相比用应用代码把多个工具拼接起来的系统，单一集成软件产品往往能在它设计针对的工作负载类型上实现更好、更可预测的性能——为不需要的规模构建系统是白费精力，还可能把自己锁死在不灵活的设计里，这本质上是一种过早优化。分拆的目标从来不是要在某个具体工作负载的性能上跟单一数据库竞争，而是让你能组合多个不同的数据库，从而在比单个软件能覆盖的范围更广的工作负载区间里获得更好的整体表现——这是关于广度而非深度，与[[Hadoop与MPP数据库对比之处理模型多样性任意代码与声明式查询的融合]]所讨论的存储和处理模型多样性是同一个道理。因此：如果有一项技术真能满足你的所有需求，用它就好，不必强行用更低层的组件重新发明它；只有当没有单一软件满足所有需求时，拆分和联合的优势才会显现。