Summary

$search facet lacks the ability to

1. Generate facets over multiple fields
2. Perform non-count aggregations such as min/max/avg/sum

This results in having to use $group after $search, which is very inefficient.

New Syntax here: https://docs.google.com/document/d/1OcbFT7mu_RAV4461nCMZZoSQZvy4EikRXtcjfVZ-64Q/edit?tab=t.wyioaawyxzcc#heading=h.35mpqh7ze5qn 

Motivation

Who is the affected end user? Developers building search applications must rely on $group after $search and cannot achieve the performance they need.

Who are the stakeholders?

How does this affect the end user?

Customers have to use inefficient workarounds that are resource-heavy, resulting in needing to scale up their cluster (using $group for aggregations and/or issuing several sub-queries for each facet field combination) 

How likely is it that this problem or use case will occur?

Highly likely for 30% of $search customers.

If the problem does occur, what are the consequences and how severe are they?

Performance

Is this issue urgent?

Search Aggregations launch at NYC .local 2026 (Sept 30, 2026). Support for Builders is a nice-to-have, and can be a fast follow. Work is expected to complete mid-August and available for local testing. 

Is this ticket required by a downstream team?

No

Is this ticket only for tests?

Unsure

Acceptance Criteria

Builders can use language-native methods to construct $search queries with the new facet functionality.