Weaviate 1.40 adds PathSeer for filtered search without reindexing

A new strategy on the same graph

Weaviate 1.40.0 added PathSeer on October 7, 2026. Existing hierarchical navigable small world collections can change their filtered-search strategy without reindexing. The company announced the feature on October 14, 2026. The release also included other graph-search changes, including an Acorn locking change. Comparing strategies within one pinned build helps isolate their effects. Sources: Weaviate, Weaviate on GitHub

Weaviate's documentation says PathSeer changes traversal without adding stored index data, import overhead or memory overhead. Acorn remains the default, with sweeping also available. Existing collections can therefore compare all three strategies on the same graph. The practical question is which meets a workload's recall and response-time requirements. Sources: Weaviate

Why match counts are not enough

Weaviate documents different ways of handling objects rejected by a filter. Sweeping follows graph distances and admits eligible objects into results. Acorn avoids distance calculations for rejected objects, explores multiple hops and adds matching entry points. PathSeer initially explores matching second-hop neighbors. After filling its result set, it skips rejected neighbors of rejected candidates, making decisions per node. Sources: Weaviate

Weaviate defines correlation as the fraction of unfiltered top-10 neighbors passing a filter, divided by overall filter selectivity. This separates the share of objects that qualify from their relationship to the query. Similar match fractions can therefore present different traversal problems. Weaviate also describes its Acorn implementation as a custom adaptation of the paper. Comparisons should identify the implementation and version, not just the algorithm name. Sources: Weaviate

Weaviate labels its negatively correlated BEIR workload as having approximately 4.5% selectivity and reports a correlation score of 0.07. At the published recall target, the company's table shows ACORN ahead of both alternatives. That result makes unfavorable query relationships worth including in a representative test. Random filters alone would leave that part of the comparison unexplored. Sources: Weaviate

The throughput results have several winners

Weaviate reported results from a Weaviate 1.40 build on a Google Cloud c4-standard-16 machine with 16 virtual CPUs and 60 GB of memory. Flat search was disabled, and throughput was interpolated at recall@10 of 0.90. An unreached result means no tested search-breadth setting, called ef, through 512 achieved that recall. The table below contains vendor-reported measurements, without independent reproduction or request latency distributions. Sources: Weaviate

PathSeer leads on the topical BEIR workload and both listed Wiki conjunction workloads. Sweeping leads the Wiki random-filter case, where ACORN misses the recall target within the tested range. In the negative-correlation case, ACORN delivers 1,880 queries per second against PathSeer's 216, approximately an 8.7-fold advantage. The announcement's prose describes a smaller margin than its table shows. Sources: Weaviate

A stricter recall requirement can change the selection criteria. At ef of 2,048, Weaviate reports PathSeer reaching 0.998 recall in the negative-correlation case, compared with ACORN's reported plateau of 0.984. That result does not show PathSeer running faster at the higher target. Measure request latency separately; throughput's reciprocal cannot establish it without concurrency and timing boundaries. Sources: Weaviate

The cutoff can hide the strategy being tested

Weaviate lists a default flat-search cutoff of 40,000, which takes precedence over the selected traversal strategy. Setting the cutoff to zero forces vector-index search. Switching from ACORN to PathSeer can therefore leave a query using the same flat-search path. Verify the execution path before interpreting unchanged performance. Sources: Weaviate

For a single-shard experiment, the documented cutoff equals 8% of 500,000 objects, 4% of one million and 0.4% of ten million. These are calculated thresholds, not measured performance crossover points. Test matching sets immediately below, at and above the cutoff. Verify the boundary comparison and shard behavior in the pinned build, because a percentage-only sweep can miss the routing transition. Sources: Weaviate

First disable flat search to isolate graph traversal, then repeat with the default cutoff to evaluate deployed behavior. The configuration reference marks filter strategy, flat-search cutoff and ef as mutable. The default ef of minus one enables dynamic sizing, while higher fixed values generally trade speed for recall. Begin with fixed search breadth, then evaluate dynamic sizing separately. Sources: Weaviate

Separate shipping behavior from earlier experiments

PathSeer's initial pull request described extended neighbor storage and reported build-time and memory comparisons. Its history recorded a revision requiring no index modification on August 9, 2026, before the merge on September 8, 2026. Those earlier overhead measurements describe a different design from the shipping approach. The pull request's early graph settings also should not be assigned to the announcement's later experiments. Sources: Weaviate, Weaviate on GitHub

The academic PathSeer repository uses Faiss and includes an overhead-profiling stage for adaptive configuration. It is a separate experimental implementation, so it does not directly reproduce Weaviate's results. Weaviate's benchmark repository provides a Go benchmarker and Docker Compose workflow, but its generic machine recommendation differs from the announcement's hardware. Pin the benchmark commit and actual machine configuration before comparing results. Sources: Weaviate, GitHub, Weaviate on GitHub

The announcement's positive-correlation BEIR case has conflicting selectivity labels: 5.5% and approximately 4.5%. Clarify the intended selectivity before reproducing that case. Treat dataset, filter and configuration labels as part of the benchmark specification. An algorithm name alone does not make experiments comparable. Sources: Weaviate

Compare at equal recall, then add production load

Use one pinned Weaviate 1.40 build and one existing HNSW graph for a controlled evaluation. Switch strategies sequentially, verify each applied configuration and randomize run order. Hold embeddings, distance metric, quantization, graph construction, shard count, query vectors, filters and returned fields constant. The table below proposes coverage for that experiment; it contains no measured results. Sources: Weaviate, Weaviate on GitHub

Generate exact filtered nearest-neighbor ground truth independently of the approximate index. Track queries with fewer eligible objects than requested results separately. Record latency percentiles, throughput, errors, timeouts and recall by query group, including poorly performing queries. Capture matching-object counts, execution paths, CPU use, memory, cache state and filter allow-list construction time. Supply vectors initially to exclude embedding-service latency, separate cold and warm runs, and report repeated-run variability.

Compare equal achieved recall as well as equal search breadth, and mark unattained targets without extrapolation. After establishing a static baseline, add representative concurrency, then concurrent writes and deletions. Check whether ACORN's reported negative-correlation advantage persists under load and whether PathSeer meets stricter recall requirements. Track how often queries use flat search. Before downgrading below Weaviate 1.40, change collections using PathSeer to ACORN or sweeping, as the documentation requires. Sources: Weaviate