Vector stores help you find text by meaning, not just by matching keywords. You add your content once, and later you can search it using natural questions to get the most relevant results—even if the words don’t exactly match.

how vector stores fit into indexing and query workflows, how to configure clients, and common use cases with full cfscript samples. It covers the core operations; add, addAll, search, delete, deleteAll, and deleteCollection, using simple, reproducible examples.

Vector stores follow a two-phase pattern. Indexing: you turn content into embeddings and store those vectors (with optional text and metadata). Query: you turn a question into an embedding (or pass a vector directly) and retrieve the nearest neighbors by similarity score.

That split matters for design: write path (chunk, embed, store) can run offline or in a job; read path (embed query, search, return text for the app or an LLM) usually runs on each request.

The examples below use in-memory clients, where you can run them without external services.

For local tests and prototypes, call VectorStore() with no arguments. That initializes an in-memory vector store with the default local embedding model (all_minilm, 384 dimensions). You can pass documents with text only; you do not need to pass an embedding unless you want to override the model output (if you pass an embedding, it takes precedence over the configured embedding model).

The same add‑and‑search pattern also works with external vector databases and retrieval‑augmented generation (RAG) workflows. ColdFusion provides a provider‑agnostic API, so you can start in memory and later move to hosted stores such as Milvus, Pinecone, Qdrant, or Chroma without changing your core application logic.

Once the client exists, you can index content. Indexing here means: pass text (and optional metadata), and let the client embed and store it. You can add one document with add or several with addAll.

Each struct you pass is one logical document. text is required for the usual path. metadata is optional but worth using early (for example a category key) because it unlocks filtered search later. id is optional; if you skip it, the server can assign ids for you. You do not need to pass a raw embedding while the default embedding model is active—ColdFusion derives embeddings from text.

The sample first adds a single document, then builds a small array and passes it to addAll. writeDump shows the returned id(s) so you can confirm the round trip.

Search is where you ask for semantically similar rows. The client turns your query text into a vector the same way it embedded your documents, then compares it to stored vectors and returns the best matches.

You control how many results you want with topK and how strict the match must be with minScore. Thresholds depend on your model and data; start with a modest minScore and adjust after you inspect score on each hit. Returned rows usually include score, text, and metadata (see your function reference for the exact struct shape).

The script below is self-contained: it creates a fresh in-memory client, indexes two short documents, then runs one search. You can paste it into a test page as a single block.

Use provider: "inmemory" when you want the same process-local store but a specific embeddingModel (for example OpenAI).

Note: Pull third-party models in Ollama before you point modelName at them.

Pass a struct that includes `provider` and your connection details. The example below uses Milvus. Other providers follow the same pattern with different required fields.

Set connection options (timeouts, retries, keep-alive) and collection options (dimension (mandatory), metric, index type, field names) on the struct. If a collection is missing, it is created for you so you can focus on data operations.

Vector store definitions are usually registered with the Vector Store Admin API (after administrator login).

For example:

Scenario: You store short FAQ and help article snippets. When a user asks a question, you search for the closest chunks and pass the returned text to your AI service as context (your app is responsible for calling the LLM with that context).

Scenario: Shoppers view a product page; you show semantically related products in the same category, excluding the current SKU.

Scenario: Readers search a corpus where each item has locale and publishedYear. Filters keep results in the right language and recency band.