← All topics

Performance, Evaluation & Benchmarking · Topic 178

How metadata cardinality affects query performance

Cardinality is the number of distinct values a metadata field has (e.g. low for “region”: 5 values, high for “user_id”: millions). High-cardinality filters often hurt vector query performance because they reduce the effectiveness of indexes and increase the work done during or after the ANN search.

Summary

  • Cardinality: number of distinct values a metadata field has (low: e.g. region = 5 values; high: e.g. user_id = millions). High-cardinality filters often hurt performance—reduce index effectiveness and increase work during or after ANN search.
  • With pre-filtering, the subset may be scattered (e.g. by user_id), so the index cannot prune well. With post-filtering, high cardinality means selective filter; you may need many more candidates (higher k or efSearch), increasing latency. Mitigations: partition or namespace by high-cardinality key; bitmaps or inverted indexes; benchmark with realistic cardinality for p99. Pipeline: filter by metadata, then ANN or ANN then filter. Practical tip: namespace by tenant/user when cardinality is very high.

Pre-filtering and post-filtering

With pre-filtering, the engine must restrict the ANN search to a subset of vectors; if that subset is scattered (e.g. filter by user_id), the index cannot prune well and you may approach a full scan. With post-filtering, you run ANN over the full set and then filter results; high cardinality means the filter is selective and you may need to fetch many more candidates (higher k or efSearch) to get enough that pass the filter, increasing latency and cost.

Pipeline: filter by metadata, then ANN or ANN then filter. Practical tip: namespace by tenant/user when cardinality is very high.

Mitigations

Mitigations: partition or namespace by high-cardinality key (e.g. one collection per tenant) so each query runs over a smaller set; use bitmaps or inverted indexes for metadata when the implementation supports them; and benchmark with realistic cardinality so p99 reflects production.

Frequently Asked Questions

What is metadata cardinality?

The number of distinct values a metadata field has—e.g. low for “region” (5 values), high for “user_id” (millions). High-cardinality filters often hurt vector query performance because they reduce index effectiveness and increase work during or after ANN search. See metadata filtering.

How does cardinality affect pre-filtering?

With pre-filtering, the engine restricts ANN to a subset; if that subset is scattered (e.g. filter by user_id), the index cannot prune well and you may approach a full scan. See why pre-filtering is hard for ANN.

How does cardinality affect post-filtering?

With post-filtering, you run ANN over the full set then filter; high cardinality means the filter is selective and you may need to fetch many more candidates (higher k or efSearch) to get enough that pass, increasing latency and cost.

How can I mitigate high-cardinality impact?

Partition or namespace by high-cardinality key (e.g. one collection per tenant); use bitmaps or inverted indexes when supported; benchmark with realistic cardinality so p99 reflects production. See global secondary indexes.