Building a Vector Search Pipeline in Oracle Database - Part III

In Part I, we built a semantic-search pipeline inside Oracle Database: loaded text from Object Storage, generated embeddings with OCI Generative AI, stored those vectors in the NEWS_DATA table, and queried them with native vector search. 

In Part II, we exposed that search through a custom ORDS module. The application sent a text phrase, and the handler generated the embedding and returned the nearest matches. 

ORDS 26.1 introduces another option: native vector search for AutoREST-enabled tables and views that contain VECTOR columns. Once the table is REST-enabled, ORDS automatically exposes a POST vectorSearch endpoint. There is no need to define an ORDS module, template, or custom SQL handler. 

REST-enabling the vector table 

The NEWS_DATA table created in Part I contains the source text in INFO and the embedding in VEC. Enable AutoREST for the table as follows:
 
rajesh@ADBS26ai> declare
  2    pragma autonomous_transaction;
  3  begin
  4      ords.enable_object(p_enabled => TRUE,
  5                         p_schema => 'RAJESH',
  6                         p_object => 'NEWS_DATA',
  7                         p_object_type => 'TABLE',
  8                         p_object_alias => 'news_data',
  9                         p_auto_rest_auth => FALSE);
 10      commit;
 11  end;
 12  /
 
PL/SQL procedure successfully completed.
 
The object alias becomes part of the REST path. With the settings above, ORDS creates the native vector-search endpoint at:
 
POST https://<your-ords-host>/ords/rajesh/news_data/vectorSearch
 
For this demonstration, authentication is disabled. In a production environment, protect the endpoint with the authentication and authorization controls appropriate for your ORDS deployment.
 
Exploring the generated OpenAPI definition
 
ORDS also generates an OpenAPI document for the AutoREST-enabled object. You can retrieve it using:
 
GET https://<your-ords-host>/ords/rajesh/open-api-catalog/news_data/
 

 
Import the returned OpenAPI JSON into Swagger Editor to explore the available operations.
 

 
In addition to the normal AutoREST operations, the definition includes:
 
POST /vectorSearch
 
The generated API documentation describes the request body fields, including:

• vector — the query embedding
• columns — the columns to return
• distanceMetric — the similarity metric
• limit — the maximum number of matches
• includeVectors — whether the response should include stored vectors

 
Generating the query vector
 
The native endpoint expects a vector rather than plain text. For this example, use the same embedding configuration from Part I to generate a vector for the phrase little red corvette.
One way to get the query vector as input for the above endpoint is the call the
 

 
The query returns the embedding as an array of numeric values. Copy that array into the request body for the vectorSearch call.
 

 
For production applications, generate query embeddings in a trusted service layer or approved inference flow. Do not expose OCI credentials to client-side applications.
 
Calling the native vector-search endpoint
 
Send the generated vector to the AutoREST endpoint in a JSON payload:
 
{
  "columns": ["ID", "INFO"],
  "distanceMetric": "EUCLIDEAN",
  "includeVectors": false,
  "limit": 5,
  "vector": [
    -0.026794434,
    -0.00776764,
    -0.0042381287
  ]
}
 
The vector array above is abbreviated for readability. In the actual request, provide the complete embedding returned by DBMS_VECTOR.UTL_TO_EMBEDDING.
 
POST https://<your-ords-host>/ords/rajesh/news_data/vectorSearch
Content-Type: application/json
 
ORDS returns the nearest records from NEWS_DATA, together with the vector-search distance:
 
{
  "items": [
    {
      "id": 39,
      "info": "The Toyota Camry, the nation's most popular car has now been rated as its best new model.",
      "vectorsearchdistance": 0.6485679418223137
    },
    {
      "id": 45,
      "info": "The Carolina Panthers entered the season thrilled about their depth at running back.",
      "vectorsearchdistance": 0.6679124700084889
    }
  ]
}
 
The results are consistent with the semantic search performed in Part I. The returned text does not need to contain the exact phrase little red corvette; the search ranks records by similarity between the query vector and the vectors stored in the VEC column.
 
Why use the native endpoint?
 
The native vectorSearch endpoint is useful when the table itself is the API surface.

•  No custom ORDS module or SQL handler is required.
  
• The OpenAPI definition is generated automatically.
• Clients can choose returned columns, result limits, and distance metrics through the request body.
• The response includes a distance value for each returned record.
• The same AutoREST object can support ordinary REST operations as well as vector search.

 
Part II remains useful when the API should accept a natural-language phrase directly, apply custom logic, or expose a carefully tailored response. The native endpoint is a simpler alternative when an application can provide the query vector and you want ORDS to expose vector search with minimal configuration.
 
With this final step, the semantic-search pipeline built in Part I is available through both custom ORDS handlers and the new native AutoREST vector-search endpoint in ORDS 26.1.