Why should you use docValues for sorting and faceting fields?

docValues store field values in a column-oriented, on-disk format built at index time, essentially the inverse of the inverted index: instead of term-to-documents, it's document-to-value, optimized for exactly the access pattern sorting, faceting, and grouping need.

Without docValues, Solr falls back to Lucene's uninverted field cache: the first query that sorts or facets on that field triggers Solr to scan the entire index and build the term-to-document mapping in JVM heap, on demand. This has two serious downsides:

• Heap pressure - the field cache lives entirely in JVM heap and grows with cardinality and document count, a common cause of OutOfMemory errors on large collections.
• Cold-start latency spikes - the first query (or first query after a commit invalidates it) pays the full build cost, which can be seconds on a large index, causing unpredictable tail latency.

docValues sidesteps both: the structure is built once at index time, stored off-heap using memory-mapped files, and shared cheaply across queries and even across JVM restarts without rebuilding. The trade-off is a modest increase in index size on disk and slightly slower indexing, which is almost always worth it for any field used in sort, facet, or group parameters on non-trivial data volumes - it's considered close to mandatory in current Solr deployments for those use cases.