What is Metadata Filtering?
Also called attribute filtering.
Metadata filtering restricts a search to records whose stored attributes satisfy given conditions, such as tenant, language, document type, author, or date range. The filter is applied alongside similarity scoring rather than after the fact, so results are both relevant and permitted. It is the mechanism that makes shared vector collections safe for multiple tenants.
Every stored vector normally carries a payload of structured fields written at ingestion time. Filters reference those fields with conditions such as equality, set membership, numeric ranges, or timestamp comparisons. Because the filter narrows what the search may return, it does double duty: it improves precision by excluding irrelevant categories, and it enforces access boundaries by excluding records a caller may not see.
How the filter interacts with the index determines correctness and speed. Post-filtering runs the similarity search first and then discards non-matching results, which is simple but can return far fewer items than requested when the filter is selective. Pre-filtering or filtered traversal evaluates the condition during search, keeping result counts stable at higher per-candidate cost. Highly selective filters sometimes make a plain scan of the matching subset the fastest option.
Security depends on the filter being applied server side and derived from the authenticated caller, never from client-supplied parameters that a request could tamper with. A tenant filter passed in by the frontend is an access control bug waiting to happen. Systems handling strict isolation often go further and separate tenants into distinct collections or namespaces so that a missing filter cannot leak data.
Filters need the same care as the vectors themselves. Fields must be written consistently at ingestion, indexed if they are queried often, and kept in sync when source records change, since a stale permission field silently grants or denies access. Recency filters deserve particular attention because they interact with how documents are updated and superseded over time.
Key points
- Restricts search by stored attributes like tenant, type, or date
- Pre-filtering keeps result counts stable; post-filtering can undershoot
- Filters must be server side and derived from the authenticated caller
- Highly selective filters can beat index traversal entirely
- Stale metadata silently breaks both relevance and access control
In practice
A shared collection holds documents for four hundred customer workspaces. Every query carries a filter on workspace identifier taken from the verified session, plus an optional filter on document type. A search for onboarding checklist inside one workspace never touches vectors from another, even though all of them live in the same index and some are far closer to the query in embedding space.