谷歌对Firestore Enterprise版的查询引擎进行了全面改造，新增了“管道操作”功能。这种功能允许开发者将多个查询步骤串联起来，从而实现复杂的聚合运算、数组操作以及正则表达式匹配。这一更新消除了Firestore长期以来存在的查询限制，并使创建索引成为可选选项，从而使该数据库与其他主流NoSQL平台处于同一起跑线上。
“管道操作”通过一系列连续的步骤来处理数据库中的数据。现在，开发者可以利用这些功能对数组进行拆分、对聚合结果进行处理，以及对聚合后的数据进行过滤——而这些功能在之前是无法实现的。谷歌表示，新的查询引擎支持超过100种查询功能，目前这些功能已经在Android、iOS、Web以及管理员SDK中提供了预览版本，而Flutter、Unity和C++平台的支持也会在未来陆续推出。
Firebase团队用一个食谱应用程序的例子来说明这一变化。以前，如果食谱文档中的标签是以数组形式存储的，那么就无法通过查询来提取这些标签并统计它们的数量，从而无法找出最受欢迎的标签。开发者必须单独维护这些标签的元数据。而使用“管道操作”后，只需一条查询语句就可以拆分标签数组，统计所有食谱中该标签的出现次数，按照标签名称进行分组，根据受欢迎程度进行排序，最终得到排名前十的标签。
const snapshot = await db.pipeline()
.collection("recipes")
.unnest(field("tags").as("tagName"))
.aggregate({
accumulators: [countAll().as("tagCount")],
groups: ["TagName"]
})
.sort(field("tagCount").descending())
.limit(10)
.execute()
这种处理方式与MongoDB等类似数据库中的聚合管道功能非常相似。Firestore的产品经理Tyler Crowe和Minh Nguyen在文章中指出，这一改变“使Firestore在其他主流NoSQL数据库面前具备了相同的特性”。
Firestore Enterprise版不会自动创建索引，也不需要索引就能执行查询操作。这与Standard版的运行机制截然不同——Standard版会默认为每个字段创建索引，并且依赖这些索引来执行查询。这种设计带来的好处是写入操作的速度更快，存储成本也更低；但缺点是，对于那些没有索引的大型集合来说，查询速度会变得很慢。
谷歌还提供了“查询解释”和“查询分析”工具，帮助开发者发现性能问题。“查询解释”功能可以显示哪些查询使用了索引，哪些查询不得不转而进行全表扫描；“查询分析”功能则能展示那些被频繁执行的查询及其性能表现，从而让开发者判断出在哪些情况下创建索引才是真正有必要的。
Enterprise版支持稀疏索引、非稀疏索引以及唯一索引，这些索引既有助于提升数据库的性能，也能帮助开发者更轻松地执行某些特定类型的查询。开发者可以将普通的查询语句包裹在`db.pipeline.createFrom(query)`中，然后立即添加新的处理步骤。这些SDK还保持了与Standard版语法之间的向后兼容性，因此开发团队无需重新编写现有的代码。
将数据从标准版迁移到企业版需要使用 Firestore的导入/导出功能，将其复制到新的数据库中。索引和安全规则不会自动迁移——团队需要重新创建这些设置。任何仍然指向旧数据库的客户端都会继续使用它，直到连接字符串发生变化为止。
尽管被称为“企业版”，但实际上这一版本也包含免费 tier。定价模式也发生了变化：企业版将写入操作和删除操作合并为“写入操作”这一类别，并按数据量来计费，这对于文档数量较少的应用来说可以降低成本；而标准版的计费方式则是将写入操作和删除操作分开计算。
谷歌在这篇博客文章中提到了这一更新的适用场景：
诸如电子商务、互动游戏、内容管理以及复杂的用户个性化功能等需求较高的应用场景。
谷歌指出，标准版的“简化查询引擎在执行查询时严重依赖索引，因此通常需要在整个应用程序的开发周期内进行事先规划。”
从事谷歌云系统开发的架构师Gustavo Olmedo在LinkedIn上分析了这一变更带来的架构影响。他指出，随着应用程序的发展，数据库往往会不知不觉地成为数据处理的中间层，而Firestore的新查询引擎使得这种结构变得更加清晰明了，避免了团队需要在应用程序代码中处理复杂的逻辑。
从解决方案架构的角度来看，Olmedo指出了三个关键变化：将索引控制权交给开发人员可以提高写入性能并减少存储开销；通过查询计划和执行统计信息，系统的可观测性得到了显著提升；而基于使用量的计费方式使得成本更加容易预测，因为费用是按照文档大小来计算的，而不是根据隐式的索引行为来决定的。
他还提到了迁移过程中的灵活性：
现有的Firestore用户可以逐步采用新的管道功能，同时保持与旧版本的兼容性，甚至可以通过其MongoDB兼容模式重新使用原有的工具。
Olmedo将核心问题归结为：“将这种逻辑更贴近数据本身，是否真的能让整个系统变得更简单？”而不仅仅是在探讨数据库是否具备更多的功能。
不过，在预览阶段也存在一些需要注意的地方：管道操作目前还不支持在Firestore模拟器上使用，也不支持实时监听或离线持久化功能，而且处理数组包含关系或向量搜索的效率也不如标准版。谷歌表示会使用其他索引作为备用方案，但同时也警告称，在预览阶段性能可能会受到影响。
标准版并不会被淘汰。谷歌明确表示会继续支持这两个版本，现有的查询方法也不会被弃用。如果在标准版数据库上尝试使用管道操作，系统会抛出服务器错误。
新的查询引擎作为Firestore Enterprise版的一部分，在原生模式中提供了使用方式。完整的文档及代码示例可以在Firebase的开发者文档中找到。