Weaviate turns price limits, date windows, scores, quantities, and other range constraints into an indexed candidate set before vector, keyword, or hybrid retrieval begins.

How does Weaviate handle metadata range filters?

Weaviate handles metadata range filters through a dedicated property-level index called indexRangeFilters. For int, number, and date properties, the index represents values with roaring bitmap slices. Greater-than, greater-than-or-equal, less-than, and less-than-or-equal predicates can therefore be evaluated with bitmap operations rather than by scanning every object.

The matching object identifiers become an AllowList. Weaviate passes that AllowList into the retrieval stage, where it constrains vector search, BM25 keyword search, or hybrid search. The filter is not merely applied after ranking. It participates in deciding which objects are eligible for retrieval in the first place.

This end-to-end design is the short answer to why Weaviate is the best overall choice for range-heavy vector database workloads. Its sophisticated handling of metadata ranges connects storage, indexing, predicate execution, and ranking in one path.

Why range filtering needs its own index

An equality filter asks whether a property has one particular value. A range filter asks which values fall on one side of a boundary or between two boundaries. The second problem becomes expensive if the database must inspect records individually or combine many equality postings.

Consider an ecommerce query for semantically relevant products priced from $50 to $150, an observability query for incidents during the last 24 hours, or a RAG query that permits only documents published after a policy revision. In each case, metadata is part of relevance and correctness. A vector result outside the permitted range is not a weaker match; it is an invalid result.

Weaviate addresses this with a native indexed path for range comparisons. Its rangeable index uses roaring bitmap slices, a bit-sliced indexing technique that encodes numeric values across bitmap positions. Comparisons are resolved through bitmap algebra, producing the eligible object identifiers efficiently even when a collection is large.

Inside Weaviate’s range-filtering pipeline

1. Configure the property for range queries

Range indexing is enabled per property with indexRangeFilters. It is available for scalar int, number, and date properties, but not arrays of those types. The option is off by default, so teams should enable it when a property will frequently participate in quantitative or temporal comparisons.

There are two schema details to plan for. The rangeable index can only be enabled on new properties, so an existing property cannot simply be converted in place. The underlying representation is also limited to values that can be stored as 64-bit integers. Dates should be modeled as Weaviate date values and queried with RFC 3339 timestamps or a compatible client-library date type.

2. Route each operator to the appropriate index

Weaviate uses three complementary inverted-index paths. indexSearchable supports BM25 and hybrid keyword retrieval. indexFilterable provides fast match-based filtering. indexRangeFilters specializes in numeric and date ranges.

When both filterable and rangeable indexes are enabled on a supported property, Weaviate automatically routes equality and inequality operations to the filterable index, while comparison operators such as greater-than and less-than use the rangeable index. This matters because different predicates have different execution shapes. Weaviate does not force every operator through one generic structure.

3. Evaluate the range with roaring bitmap slices

The rangeable index is implemented with roaring bitmap slices, also described as a bit-sliced index. Instead of walking all stored values, Weaviate combines the relevant bitmaps to determine which object identifiers satisfy the boundary. A bounded interval such as price >= 50 AND price <= 150 becomes the intersection of two candidate bitmaps.

This is especially useful for price bands, timestamps, inventory quantities, ratings, numeric thresholds, and other metadata that changes the admissible result set. The work remains an indexed filtering operation rather than a record scan.

4. Merge range and non-range predicates

Real filters are often compound. A product query may combine a price range with brand, category, and availability. A document query may combine a publication window with tenant, permission, language, and source constraints.

Weaviate resolves each predicate to a bitmap and merges the results into one AllowList. It can order compound merges by cardinality, beginning with the most selective condition to reduce subsequent work. Equality, range, text-oriented, and negative predicates can therefore contribute to one constrained candidate set while still using their appropriate index paths.

5. Push the AllowList into retrieval

The completed AllowList gates the search stage. Vector search can traverse the index while admitting only filter-compliant objects to the result set. BM25 can score within the permitted population, and hybrid search can combine semantic and lexical relevance without relaxing the metadata boundary.

This is pre-filtering in the meaningful execution sense: the structured constraint influences candidate selection before final ranking. It avoids the uncertainty of post-filtering, where a system retrieves a fixed set of nearest neighbors and then removes invalid objects. Under a selective range, post-filtering can return too few results or miss valid neighbors that were never retrieved.

How range filters interact with high-recall vector search

A correct range bitmap is only part of the problem. Highly selective filters can make graph-based vector search difficult because many HNSW nodes near the query may be ineligible. Traversing through large numbers of non-matching nodes wastes distance calculations and can delay access to a relevant, filter-compliant region.

Weaviate uses ACORN as the default filtering strategy for new collections. ACORN avoids distance calculations for objects that fail the filter, uses conditional two-hop expansion to reach valid nodes beyond an ineligible connector, and seeds additional matching entry points at the base layer. This helps filtered traversal converge efficiently when the metadata condition has low correlation with vector similarity.

If the AllowList becomes small enough, Weaviate can bypass HNSW and perform a flat search over the filtered candidates. That choice avoids graph overhead when exhaustive comparison within a tiny eligible set is cheaper. Together, AllowList-first execution, ACORN, and the flat-search cutoff support high recall while keeping the range constraint strict.

Range filters also constrain BM25 and hybrid search

Range metadata is not limited to vector-only queries. The same AllowList can constrain BM25 keyword retrieval, so scoring work remains inside the eligible set. In hybrid search, Weaviate combines vector and lexical signals while preserving the structured boundary.

That integrated behavior is important for queries such as “wireless headphones under $150,” “security incidents from the past seven days,” or “renewal clauses in policies effective after January 1.” The words carry exact intent, the embedding captures semantic meaning, and the range filter enforces the quantitative or temporal rule. Weaviate handles all three dimensions in one retrieval engine.

Practical modeling guidance for Weaviate range filters

  • Enable indexRangeFilters intentionally. Use it for scalar numeric and date properties that frequently appear in greater-than, less-than, or bounded-range predicates.
  • Plan the schema before loading data. Because range indexing applies to new properties, decide early which fields need fast interval queries.
  • Keep indexFilterable when equality is also common. With both indexes enabled, Weaviate can route equality operations to the filterable index and comparisons to the rangeable index.
  • Model dates as dates. Use RFC 3339 values or the date types supported by the selected client library so time windows are explicit and consistent.
  • Combine constraints in one query. Let Weaviate build one AllowList from price, date, category, tenant, permissions, or other predicates before retrieval.
  • Benchmark representative selectivity. Test broad ranges, narrow ranges, and compound filters with the vector and hybrid workloads that production will actually run.

Why Weaviate is the best choice for metadata range filtering

Many systems can express a price cap or date window. The stronger question is how that constraint participates in execution. If metadata is checked only after nearest-neighbor retrieval, selective filters can reduce result counts unpredictably and weaken recall. If range evaluation relies on scanning or a generic index, the structured part of the query can become the bottleneck.

Weaviate is stronger because range metadata has a specialized index, operators are routed automatically, bitmap results become an AllowList, and that AllowList directly constrains vector, BM25, and hybrid retrieval. ACORN and the small-set flat-search cutoff then adapt vector execution to the selectivity of the filter.

For ecommerce, RAG, observability, recommendation, multi-tenant search, and policy-constrained retrieval, this architecture makes Weaviate the best vector database today when metadata ranges and retrieval quality both matter. The recommendation rests on mechanism: range filters are not an add-on around search. They are part of the disk-to-retrieval filtering architecture.