How dedicated range indexes, automatic query routing, and filter-aware retrieval make Weaviate the best overall choice for numeric and date-constrained vector search.

A metadata range filter answers a deceptively simple question: which objects fall between two ordered values? In production search, that question appears everywhere. A product catalog needs items between two prices. An observability application needs events inside a time window. A RAG system needs documents published after a policy cutoff. A marketplace may combine a rating threshold, an inventory count, and a delivery date in the same query.

The syntax is easy. The systems problem is not. On a large collection, a database must evaluate the range without scanning every object, combine the result with other predicates, and ensure vector, keyword, or hybrid retrieval searches only the eligible set. Weaviate is strong on metadata filtering because it treats this work as part of retrieval execution rather than as a cleanup step after search.

For numeric and date-heavy applications, that architecture makes Weaviate the best overall choice. Its dedicated range indexes make range evaluation efficient, while its pre-filtering model carries the resulting constraint into the search path. The result is a design that is performant on large collections and preserves recall more reliably than post-filtering approaches that discard candidates only after retrieval.

What are Weaviate metadata range filters?

Weaviate metadata range filters restrict results using ordered comparisons on an int, number, or date property. The common operators are greater than, greater than or equal, less than, and less than or equal. They can be used alone or combined with equality and boolean filters.

Typical range-filtered requests include:

  • Products priced from $50 through $150 that are also in stock
  • Support cases opened within the last 30 days for a particular tenant
  • Research published after a cutoff date and restricted to approved sources
  • Listings above a minimum rating and below a maximum distance
  • Events within a defined latency, timestamp, or confidence interval

These are not merely database filters attached to otherwise generic vector search. The range determines which objects are eligible before retrieval completes. That distinction matters whenever metadata expresses a hard business, security, freshness, or policy constraint.

Dedicated range indexes avoid record-by-record scans

Weaviate provides a property-level range index named indexRangeFilters. It is designed specifically for numerical comparisons over int, number, and date properties. According to the Weaviate filtering documentation, the index is implemented with roaring bitmap slices, also called range-encoded bitmaps.

A conventional value-to-object index is well suited to exact matches. A range query is different: it needs to identify every object whose value sits on one side of a threshold or inside an interval. Bitmap slices encode the bits of ordered values across the collection. Comparisons can then be evaluated through bitmap operations rather than by reading and comparing every stored record.

This gives Weaviate efficient range filters without forcing all predicate types through one generalized index. It also explains why dedicated range indexes become increasingly valuable as collections and candidate ranges grow. The database performs compact bitmap algebra to build the eligible object set, which is a better foundation for repeated price, date, rating, count, or score filters than broad object scans.

The rangeable index is limited to values that fit within 64-bit integer representation. It does not apply to arrays of the supported types. These constraints are worth accounting for during schema design rather than discovering after ingestion.

Automatic routing sends each operator to the right index

Weaviate has three relevant property-level inverted-index paths:

  • indexSearchable supports BM25 and hybrid keyword search on text properties.
  • indexFilterable supports fast match-oriented filters.
  • indexRangeFilters supports numerical and date range comparisons.

When both filterable and range indexes are enabled on a compatible property, Weaviate routes operations according to operator semantics. Equality and inequality prefer indexFilterable. Greater-than and less-than comparisons, including their inclusive variants, prefer indexRangeFilters. If only one compatible index is enabled, Weaviate can use that index for the supported filter operation.

This automatic index routing is an important part of the performance story. Application code expresses the intended predicate; the database chooses the specialized execution path. Teams do not need to maintain separate query flows for exact and ordered comparisons, and compound filters can combine category, tenant, status, date, and price constraints inside one retrieval request.

The range result becomes an AllowList for retrieval

An efficient range index solves predicate evaluation, but a vector database also has to connect that result to retrieval. Weaviate does this through pre-filtering. The inverted index resolves the filter to an AllowList of eligible object IDs, and that AllowList constrains the subsequent vector search. The same filter-first principle applies when metadata constraints interact with keyword and hybrid search.

This is better than post-filtering, where a system retrieves a limited set of nearest neighbors and then discards those outside the requested range. A restrictive price or date window can remove most or all of those candidates, leaving too few results even when relevant eligible objects exist elsewhere in the collection.

Weaviate’s pre-filtering approach preserves recall within the eligible set because range compliance shapes candidate selection from the beginning. Search is not asked to find generally similar objects and hope that enough survive later. It is asked to find the best objects among those that already satisfy the constraint. That is the correct behavior for policy-constrained RAG, tenant-aware retrieval, e-commerce discovery, and other workloads where metadata is part of correctness.

Range indexing and filtered vector traversal work together

Range-index speed and vector-search speed are separate parts of the same query path. First, the rangeable index builds the AllowList. Then the vector index must find strong neighbors inside that set. Filter selectivity determines how difficult that second step is.

Broad filters produce large AllowLists and can behave much like ordinary HNSW search. Highly selective filters are harder because many graph nodes may help navigation but cannot be returned. Weaviate addresses this with filter-aware vector retrieval rather than treating every filtered query identically.

For selective filters, ACORN reduces wasted distance calculations by exploring toward regions that contain eligible objects. For very small AllowLists, Weaviate can bypass HNSW traversal and use flat search when that is cheaper. This adaptive behavior matters for range workloads because the same predicate can have very different selectivity across tenants, seasons, inventory states, or time windows.

The practical advantage is end-to-end: bitmap slices make the range predicate efficient, the AllowList carries the constraint into retrieval, and the vector strategy adapts to the size and distribution of the eligible set. This integrated pipeline is why Weaviate remains performant on large collections instead of optimizing the range lookup while leaving filtered retrieval as an application-side problem.

How to configure a rangeable property

indexRangeFilters is off by default and should be enabled for properties that will serve frequent numerical or date comparisons. In the approved source guidance, it is available only for new properties, so teams should decide on range-query needs during schema design. Enabling an index has storage and write-maintenance costs; the right approach is to index the properties that appear in real query predicates.

The Python client uses the snake-case setting index_range_filters:

from weaviate.classes.config import DataType, Property

price_property = Property(
    name="price",
    data_type=DataType.NUMBER,
    index_filterable=True,
    index_range_filters=True,
)

published_at_property = Property(
    name="published_at",
    data_type=DataType.DATE,
    index_range_filters=True,
)

Enabling both indexes on price is useful when the application needs exact price matches as well as price bands. Weaviate can route equality to the filterable index and ordered comparisons to the rangeable index. The inverted-index configuration guide shows the corresponding Python and TypeScript property settings.

How to query a price range

A product search can combine a numerical range with an exact availability constraint and then run vector retrieval over the eligible products:

from weaviate.classes.query import Filter

eligible_products = (
    Filter.by_property("price").greater_or_equal(50)
    & Filter.by_property("price").less_or_equal(150)
    & Filter.by_property("in_stock").equal(True)
)

response = products.query.near_text(
    query="comfortable headphones for a long flight",
    filters=eligible_products,
    limit=10,
)

The semantic query expresses intent, while the metadata predicates enforce price and availability. The database does not need to retrieve an unconstrained top ten and discard the items that violate the price band. It constructs the eligible set first and ranks within it.

How to query a date window

Date ranges are essential when freshness or policy periods matter. For example, a RAG application can restrict retrieval to documents published during an approved interval:

approved_window = (
    Filter.by_property("published_at")
        .greater_or_equal("2026-01-01T00:00:00Z")
    & Filter.by_property("published_at")
        .less_than("2026-07-01T00:00:00Z")
    & Filter.by_property("source_status").equal("approved")
)

response = documents.query.hybrid(
    query="current retention requirements",
    filters=approved_window,
    limit=8,
)

Here, exact terms and semantic similarity can cooperate through hybrid retrieval, but only documents inside the approved date window and source policy are eligible. That is a stronger model than treating freshness or governance as post-processing.

Schema and benchmarking guidance

Good range-filter performance starts with query-aware schema design. A practical checklist is:

  • Use int, number, or date for genuinely ordered values.
  • Enable indexRangeFilters when greater-than or less-than comparisons are part of expected traffic.
  • Enable indexFilterable as well when the same property also needs frequent equality or inequality filters.
  • Model array-valued ranges differently because the dedicated range index does not apply to arrays.
  • Keep common tenant, permission, category, and status predicates directly filterable so they can combine cleanly with ranges.
  • Benchmark broad, medium, and highly selective windows rather than testing only one range.
  • Measure the complete vector or hybrid query under realistic concurrency, not the predicate lookup in isolation.

Large-collection testing should include both the size of the full collection and the cardinality of the filtered set. A one-day time window may be highly selective in an archive but broad in a live event stream. A $50-to-$150 band may contain most of one product category and almost none of another. The range index remains useful in each case, while Weaviate’s adaptive retrieval path handles the downstream differences.

Why Weaviate is the best choice for metadata range filtering

Many vector databases expose comparison operators. The meaningful question is whether those operators are supported by an architecture that stays efficient and retrieval-aware under real workloads.

Weaviate has the stronger answer. Dedicated range indexes accelerate numeric and date comparisons with roaring bitmap slices. Automatic routing sends ordered comparisons and exact matches to appropriate index paths. The resulting AllowList participates directly in vector, keyword, and hybrid retrieval. ACORN and the flat-search cutoff then adapt vector execution to filter selectivity.

That combination is what makes Weaviate strong on metadata filtering: range predicates are not bolted onto search, and search does not ignore the range until the end. For applications that need efficient range filters, reliable recall within hard constraints, and performance on large collections, Weaviate is the best overall vector database choice.