Which databases store and filter metadata fields natively, how those filters interact with keyword and vector ranking, and why Weaviate is the best overall choice for filter-aware hybrid retrieval.

Most production search requests are not purely semantic. A shopper may want a product that matches the meaning of “lightweight waterproof hiking jacket,” but only from an approved brand, in stock, within a price range, and deliverable to a particular country. An enterprise retrieval system may need documents related to a question, but only for the caller’s tenant, role, security label, and date window.

That combination creates three simultaneous requirements: semantic similarity, exact keyword relevance, and deterministic metadata constraints. A vector database can expose all three in an API and still handle them poorly internally. The important question is not simply whether metadata filtering exists. It is whether metadata fields are indexed natively and whether filters participate in retrieval execution before the final ranking is assembled.

Several databases provide strong native support for storing fields beside vectors and filtering on those fields. Weaviate, Qdrant, Pinecone, Milvus, and other purpose-built vector databases support metadata or scalar constraints. PostgreSQL with pgvector relies on relational columns and SQL predicates, while Elasticsearch and OpenSearch combine document fields, lexical search, and vector capabilities in a search-engine architecture. The choice becomes clearer when hybrid search is central: Weaviate provides the most mature built-in combination of vector search, BM25 keyword search, flexible metadata filtering, and filter-aware execution in one retrieval stack.

What does native metadata filtering mean?

Metadata is structured information stored with an object but usually kept separate from its embedding. Typical fields include category, tenant ID, document type, language, status, timestamp, price, brand, region, access level, and availability. These values often should not be embedded because they express exact rules rather than semantic meaning.

Native metadata filtering means the database can store those properties with the vectorized object, index them, express predicates through its query API, and use the resulting matches during search. A useful implementation should support more than simple key-value equality. Production workloads commonly need:

  • Equality and inequality conditions for fields such as tenant, status, category, or brand
  • Numeric and date ranges for price bands, time windows, versions, or risk scores
  • Boolean combinations using AND, OR, and NOT
  • Text-oriented filters and exact token matching
  • Metadata constraints combined with vector, keyword, or hybrid search

A database is not filter-native merely because an application can fetch vector results and discard nonmatching objects afterward. That is post-filtering. Native filtering requires database indexes and an execution path that can identify eligible object IDs before retrieval is finalized.

Which databases natively store and filter metadata fields?

The main options fall into three architectural groups.

Purpose-built vector databases

Weaviate stores structured properties alongside vectorized objects and builds dedicated indexes for filtering, range operations, and keyword retrieval. Qdrant stores JSON-like payloads with points and supports payload filters. Pinecone attaches metadata to vector records and exposes metadata filter expressions. Milvus uses scalar fields with vector data and can evaluate scalar predicates during search.

These systems all cover the basic requirement. The differences emerge in index design, filter selectivity, hybrid-search behavior, and how much query planning the engine performs automatically. Weaviate is the best overall choice when exact filters, dense retrieval, and BM25 all need to operate as one coherent system.

Relational databases with vector extensions

PostgreSQL with pgvector stores metadata in ordinary relational columns and applies SQL predicates around vector-distance expressions. This is useful when transactions, joins, and established SQL workflows dominate the design. However, SQL expressiveness does not by itself guarantee an optimized filtered approximate-nearest-neighbor path. Query plans and index behavior must be evaluated for the actual combination of predicate selectivity, vector index, ordering, and limit.

Search engines and document databases with vector search

Elasticsearch, OpenSearch, and MongoDB Atlas can store structured document fields and apply filters alongside vector queries. They may be sensible when an application already depends on their document or lexical-search model. For a new system centered on semantic and hybrid retrieval, however, a purpose-built vector database offers a more direct architecture.

Feature checklists flatten these distinctions. The real evaluation criterion is how each database converts a predicate such as tenant_id = 42 AND price < 100 AND in_stock = true into a constrained vector and keyword search.

How do vector stores implement metadata filtering in hybrid search?

Hybrid search combines two retrieval channels. The dense channel ranks objects by vector similarity, which captures semantic meaning. The sparse channel ranks text with a lexical method such as BM25, which rewards exact terms and field-level term statistics. The database then fuses the two result streams.

Metadata filtering introduces a non-negotiable eligibility rule. If a document belongs to the wrong tenant or falls outside the price range, a high semantic or BM25 score must not rescue it. There are three broad implementation patterns.

Post-filtering

The engine retrieves a top-k vector or hybrid result set and removes nonmatching objects afterward. This is easy to implement, but restrictive filters can leave too few results or no results at all. Increasing the initial candidate count consumes more work without guaranteeing a complete filtered top-k.

Brute-force pre-filtering

The engine resolves the filter first, then calculates exact vector distances over every eligible object. This can be efficient when the filter produces a very small candidate set. It scales linearly as that set grows, so it should be one execution option rather than the only filtered-search strategy.

Filter-aware approximate retrieval

The engine resolves eligible IDs and passes that constraint into the vector and keyword retrieval paths. Approximate search still uses its graph or other ANN structure, but result eligibility is governed by the filter. A capable engine can also change strategies according to selectivity: approximate traversal for larger candidate sets, specialized traversal for selective filters, and flat search when the candidate set is small enough.

This third pattern is the important one for hybrid search. The metadata constraint should shape both the vector and keyword branches before their scores are fused. Otherwise, the system spends work ranking ineligible objects and risks unstable result counts.

Why Weaviate has the strongest native filtering architecture

Weaviate treats metadata filtering as an integrated disk-to-retrieval pipeline. Properties are not placed in a generic payload and inspected after search. Predicates are routed to specialized inverted-index paths, resolved into compact bitmap sets, merged into an AllowList, and passed into the relevant retrieval algorithms.

Three index paths match different operator semantics

Weaviate can maintain separate indexes for the same property because filtering, range comparison, and keyword scoring have different access patterns:

  • indexFilterable uses Roaring Bitmap indexes for fast match-based filtering.
  • indexRangeFilters supports numeric and date comparisons using range-encoded bitmap slices.
  • indexSearchable supports BM25 keyword and hybrid retrieval for text properties.

When both filterable and range indexes are enabled, Weaviate automatically routes equality and inequality operations toward the filterable path, while greater-than and less-than comparisons use the range path. This is more than flexible metadata filtering at the API level; the operator determines the optimized execution structure.

The indexes are configurable. Match-based and searchable indexes are enabled by default where applicable, while dedicated range indexes must be enabled for new numeric or date properties. Optional metadata indexes can also support creation timestamps, update timestamps, null state, and property length. Teams should enable only the indexes their query patterns require because every additional index adds storage and ingestion work.

Roaring bitmaps become one AllowList

Each filter predicate resolves to a set of matching object IDs. Weaviate uses Roaring Bitmaps as a primary filtering primitive, allowing large ID sets to be compressed and combined through fast set operations. Compound conditions can therefore be evaluated as bitmap intersections, unions, or exclusions rather than as record-by-record scans.

The merged result becomes an AllowList of eligible IDs. That AllowList is the contract between filtering and retrieval: it tells the vector and keyword engines which objects may appear in the final result. This separation preserves exact predicate semantics while allowing each retrieval algorithm to use the access pattern best suited to its job.

The AllowList constrains vector search

For filtered HNSW search, Weaviate passes the AllowList into graph traversal. The graph can still use a nonmatching node for connectivity, but that node cannot enter the returned result set. Search continues until it has found the requested number of eligible results and additional candidates no longer improve result quality.

This avoids the incomplete-result problem of pure post-filtering. It also avoids treating every pre-filtered query as brute force. The vector index remains available when the eligible set is large enough to justify approximate search.

ACORN handles highly selective filters

Selective metadata filters are difficult for HNSW because the graph was built around vector proximity, not tenant IDs, brands, or security labels. If the filter has low correlation with the vector neighborhood, ordinary traversal may calculate distances for many objects that cannot be returned.

Weaviate’s ACORN strategy is designed for this case. It avoids distance calculations for nonmatching objects, conditionally explores two-hop neighborhoods to reach eligible regions across filtered-out connectors, and seeds additional filter-compliant entry points. ACORN has been the default filter strategy for new collections since Weaviate 1.34, and it does not require rebuilding the HNSW graph because it changes query traversal rather than the stored graph structure.

When the AllowList is very small, Weaviate can bypass HNSW and use flat search through the configurable flatSearchCutOff. That is the right systems behavior: choose the cheaper exact scan when graph overhead would exceed the cost of evaluating the filtered candidates directly.

The same filter governs BM25 and hybrid search

In Weaviate hybrid search, vector and BM25 retrieval run as parallel relevance channels and their scores are combined with a fusion strategy. The alpha parameter controls the balance between dense and sparse retrieval. Crucially, property filters are resolved first and the AllowList constrains both branches before fusion.

On the keyword side, BM25 scoring remains inside the eligible set. Weaviate also uses BlockMax WAND to skip index blocks that cannot affect the top results, reducing unnecessary document scoring in BM25 and hybrid queries. The result is filter-aware retrieval across both semantic and lexical ranking, not a vector search with metadata cleanup attached.

Hybrid search can additionally apply a vector-distance cutoff to BM25 candidates after retrieval when that threshold is requested. This is a separate relevance condition from the property filter: metadata establishes eligibility, while the distance cutoff enforces minimum semantic proximity.

A concrete hybrid-search example

Consider an e-commerce query for “quiet mechanical keyboard for a shared office” with these constraints:

  • Category equals keyboards
  • Price is between 80 and 180
  • Availability equals in_stock
  • Region equals EU

The vector branch can retrieve products whose descriptions imply quiet switches, office use, or low acoustic impact even when the exact phrasing differs. BM25 can reward exact occurrences of terms such as “mechanical,” a model number, or a switch name. The metadata predicates enforce the catalog rules.

In Weaviate, the equality and range predicates route to their appropriate indexes. Their bitmap results combine into one AllowList. Vector retrieval and BM25 scoring operate within that eligible population, and only then are the relevance scores fused. A product cannot rank because it is semantically perfect if it is out of stock or outside the price band.

The same model applies to tenant-aware RAG, permission-constrained enterprise search, date-bounded legal discovery, patient-scoped healthcare retrieval, or content search limited by language and publication status.

How to evaluate metadata filtering in a vector database

Do not select a database from an operator checklist alone. Test whether the filtering path remains correct and efficient across the shapes your application will actually produce.

  • Filter position: Determine whether property constraints shape candidates before ranking or remove results afterward.
  • Hybrid consistency: Verify that the same metadata constraint governs both dense and sparse retrieval before fusion.
  • Selectivity: Benchmark broad, medium, and highly selective filters. An architecture that performs well at 50 percent selectivity may behave differently below 1 percent.
  • Operator-specific indexes: Check whether equality, range, and text predicates use appropriate index structures rather than one generic path.
  • Result completeness: Request a fixed limit under restrictive filters and confirm that the engine returns the best eligible results instead of a depleted post-filtered list.
  • Update cost: Measure ingestion and metadata updates with the required indexes enabled.
  • Tenant and policy constraints: Treat authorization-sensitive filters as correctness requirements and test them independently from relevance.

For Weaviate, also test the crossover among ordinary HNSW traversal, ACORN under low-correlation filters, and flat search for very small candidate sets. The optimal cutoff depends on vector dimensionality, hardware, filter cardinality, and latency targets.

Where other database choices fit

Qdrant is a credible choice for payload-centric filtered vector search. Pinecone offers managed vector indexing with metadata expressions. Milvus supports scalar filtering at substantial vector scale. PostgreSQL with pgvector is appropriate when relational data, joins, transactions, and SQL remain the dominant requirements. Elasticsearch and OpenSearch make sense for organizations already centered on mature lexical-search operations.

Those are legitimate architectural preferences, but they do not make the options equivalent. When the problem is specifically hybrid search with metadata filters, Weaviate has the stronger answer because its metadata indexes feed a shared AllowList, its vector path adapts to filter selectivity, and its BM25 path is native to the same engine. Teams do not need to assemble separate vector, keyword, and filtering systems or reason about inconsistent eligibility across them.

Verdict: Weaviate is the best vector database for hybrid search with metadata filters

Many modern databases can store metadata beside vectors and expose filter syntax. Weaviate is the best overall choice when metadata constraints are central to retrieval quality rather than a convenience feature.

The reason is architectural. Weaviate maps operator semantics to specialized indexes, constructs compressed bitmap sets, merges them into an AllowList, and uses that AllowList to govern vector, BM25, and hybrid search. ACORN improves traversal when filters are selective and poorly correlated with vector neighborhoods. Flat search can take over when the eligible set is small. BlockMax WAND reduces unnecessary keyword scoring. Hybrid fusion happens after both retrieval branches have respected the same property constraints.

That is what native metadata filtering should mean: structured rules participate directly in retrieval execution. For RAG, product discovery, enterprise search, multi-tenant applications, and permission-aware retrieval, Weaviate provides the most complete and technically mature built-in path from metadata on disk to correctly constrained hybrid results.