feat: Making feast vector store with open ai search api compatible

[patelchaitany]

What this PR does / why we need it:

This PR making the feast vector store api with open ai search api compatible so.

This are the changes are made.

1. New OpenAI-compatible endpoint

• Added POST /v1/vector_stores/{vector_store_id}/search that matches the OpenAI vector store search API
• vector_store_id just maps to a feature view name
• Takes a query string, embeds it via LiteLLM, calls retrieve_online_documents_v2, and returns results in OpenAI's vector_store.search_results.page format
• LiteLLM embedding config goes in feature_store.yaml under a new embedding_model section (model, api_key, api_base, api_version, dimensions

2. Metadata filtering

• New filter_models.py with two Pydantic models: ComparisonFilter (eq, ne, gt, gte, lt, lte, in, nin) and CompoundFilter (and/or, nestable)
• Threaded filters through the entire retrieval stack down to each online store
• Each store translates filters into its native query language:
  • Elasticsearch: Query DSL clauses (term, range, terms, bool)
  • Milvus: boolean expressions like field == 'value'
  • Postgres: parameterized SQL subqueries with entity_key IN (SELECT ...)
  • SQLite: same approach as Postgres, SQLite syntax

3. Numeric storage fix

• Without this change, all values are stored as text, so '9' > '100' is true in filters
• New enable_openai_compatible_store config flag on every store backend
• When enabled, adds a value_num column that stores int, float, double, and bool values natively alongside the existing `value_text

4. Bug fixes picked up along the way

• SQLite BM25 search was reading raw value instead of value_text
• SQLite's query param renamed to embedding since that's what it actually is
• Added input escaping for Milvus query strings

5. Tests

• 160 lines of unit tests for filter models (valid/invalid operators, value types, nested compounds)
• ~320 lines of integration tests covering filtered vector search, filtered text search, OpenAI response shape, and error cases (no embedding config, nonexistent feature view, empty results)

Which issue(s) this PR fixes:

#5615

Misc

---

[patelchaitany]

Hey @franciscojavierarceo, @ntkathole can you pls review this PR.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 42 additional findings in Devin Review.

[devin-ai-integration]

🔴 Postgres vector search applies metadata filters as post-filtering after top-k LIMIT, silently returning fewer results than requested

In retrieve_online_documents_v2, the vector_matches CTE computes the top-k closest entities by vector distance without considering metadata filters. Filters are only applied in the outer WHERE clause after the CTE's LIMIT. This means if a user requests top_k=10 with a filter, the CTE finds the 10 closest entities ignoring filters, then the outer query discards entities that don't match — potentially returning far fewer than 10 results even when many matching entities exist in the store.

In contrast, both the Elasticsearch backend (sdk/python/feast/infra/online_stores/elasticsearch_online_store/elasticsearch.py:591-599) and the Milvus backend (sdk/python/feast/infra/online_stores/milvus_online_store/milvus.py:798-805) correctly apply filters inside the vector search (before the top-k cutoff), so they return up to top-k results that satisfy the filter.

Postgres CTE that ignores filters

The CTE at lines 912-921 limits to top_k without any filter:

WITH vector_matches AS (
    SELECT entity_key,
        MIN(vector_value <-> %s::vector) as distance
    FROM {table_name}
    WHERE vector_value IS NOT NULL  -- no metadata filter here
    GROUP BY entity_key
    ORDER BY distance
    LIMIT {top_k}  -- limit applied before filter
)

The filter is only applied in the outer query at line 934.

(Refers to lines 912-946)

Prompt for agents

The metadata filter needs to be applied INSIDE the vector_matches CTE (before the LIMIT), not just in the outer WHERE clause. Currently the CTE at lines 912-921 computes the top-k closest entities without considering filters, then the outer WHERE at line 934 discards non-matching entities, returning fewer than top_k results.

To fix: translate the filter clause so it can be embedded inside the CTE WHERE clause. The filter subquery pattern (entity_key IN SELECT entity_key FROM table WHERE feature_name = ... AND value_text ...) should be added to the CTE WHERE alongside the vector_value IS NOT NULL condition. The same fix is needed for all three search cases (vector-only at line 912, hybrid at line 823, and text-only at line 957).

For example, the vector-only CTE should become:
  WITH vector_matches AS (
      SELECT entity_key,
          MIN(vector_value <distance_op> %s::vector) as distance
      FROM {table_name}
      WHERE vector_value IS NOT NULL
        AND <filter_clause_without_alias>
      GROUP BY entity_key
      ORDER BY distance
      LIMIT {top_k}
  )

Note: the filter clause generation currently uses alias='t1' which won't work inside the CTE. You'll need to generate a version of the filter clause without an alias (or with a different alias) for use inside the CTE.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[patelchaitany]

I know about this and why i chose this way because when we do meta data filtering first then we need to retrieve more than top K results then after we need to apply vector similarity search on that which is going to do filter of top K but the thing is that in that process we might loose the closest search according to the vector similarity.

and in the Elastic search and Milvus the metadata filtering happens during the vector search so it is combined step over there not like here which is step by step process and this is limitation of the SQL and POSTGRES.

[devin-ai-integration]

🔴 SQLite vector search applies metadata filters as post-filtering after top-k LIMIT, same issue as Postgres

Same issue as in Postgres. The vec_table match subquery at line 793 finds the top-k closest vectors without considering metadata filters. The filter clause is only applied in the outer WHERE at line 801, potentially returning fewer results than top_k even when many matching documents exist.

Elasticsearch and Milvus correctly pre-filter before the top-k cutoff, making this an inconsistency across backends.

SQLite query structure showing post-filtering

from (
    select rowid, vector_value, distance
    from vec_table
    where vector_value match ?  -- no metadata filter
    order by distance
    limit ?  -- top-k applied before filter
) f
left join {table} fv on f.rowid = fv.rowid
left join {table} fv2 on fv.entity_key = fv2.entity_key
where fv2.feature_name != ? AND <filter_clause>  -- filter applied after limit

(Refers to lines 777-803)

Prompt for agents

The metadata filter needs to be applied BEFORE the top-k limit in the vec_table subquery, not in the outer WHERE clause. Currently the vec_table match at line 793 limits to top_k without filters, and the filter is applied at line 801.

SQLite vec0 doesn't support arbitrary WHERE clauses inside the match query, so the fix requires a different approach: first filter the entity_keys that match the metadata filter, then build the vec_table from only those entity_keys' vectors, then run the match. Alternatively, increase the vec_table limit significantly and apply the filter afterward, but re-rank/re-limit. The simplest correct fix might be to skip the vec_table virtual table approach when filters are present and instead compute distances manually for the filtered entity set.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[patelchaitany]

Hi @HaoXuAI, @shuchu when you get a chance, could you take a look at this PR? Happy to address any feedback. Thanks!