Vector Stores Quick Start

A Vector Store is a named, persistent knowledge base. You put text in (typed, uploaded, or pushed by a flow), HostWebhook splits it into chunks, turns each chunk into an embedding with your API key, and stores it. From then on you can ask it questions in plain language and get back the passages that actually answer them — from the dashboard, from the Vector Store node in a flow, or as a tool an AI Node can call on its own.

The five-minute path

What each field on the store actually does

Choosing a backend

Both bring-your-own backends show a Test connection button as soon as every required field is filled, and the result is actionable rather than a bare pass/fail:

• MongoDB — reports the server version, whether the cluster supports vector search, and whether your named index exists. When it does not, it prints the exact JSON to paste into Atlas (Search → Create Search Index → JSON).
• Postgres — reports the Postgres and pgvector versions. If the extension or the table is missing you get the SQL and a one-click Auto-setup button that runs it idempotently, then re-tests.

The same Re-test connection button lives in the Backend section of an existing store, which is the fastest way to find out that someone dropped the index or rotated the password. Full walkthroughs: Bring your own MongoDB and Bring your own PostgreSQL. For a cluster that is not reachable from the public internet, pair the credential with a reverse tunnel.

Chunking — the part that decides whether retrieval works

Embeddings are computed per chunk, and a query returns chunks. Chunk size is therefore not a storage detail: it is the size of the answer you get back.

Content type changes how text is split

Pasted text and extracted files are sniffed, and each detected type gets a strategy that respects its structure instead of cutting blindly:

• JSON — descends the structure: one array element or one object key per chunk, and plain text is cut only as a last resort.
• CSV — grouped by rows, repeating the header on every chunk so each one is readable on its own.
• Markdown — split on ## headings first.
• Code — detected from language keywords, split with code-friendly separators.
• Prose — the fallback, and what everything ambiguous becomes.

Putting content in by hand

The Ingest tab of a store takes a file, a block of text, or both at once.

• Files — PDF, CSV, JSON, and anything text/*. Images and other binaries are rejected. DOCX and XLSX need converting first — do it with a File Transform node in a flow.
• Text — pasted CSV or JSON is auto-detected and chunked accordingly. The counter under the box estimates how many chunks you are about to create.
• Source doc name — a human label, and the filter you will use in the Content tab and in query results.
• Source doc id — the logical identity of the document: a URL, a hash, a page id. This is what delete-by-document and the node's upsert toggle key on later.

The other tabs

• Content — every chunk, paginated 50 at a time, filterable by source document name or by a substring of the chunk text. Click a row to read the full chunk; delete a chunk from its row. This is where you check what the chunker actually produced.
• Query — a playground. Type a question, set Top K, and read the scores. Scores are cosine similarity: above 0.8 is a strong match, 0.6 to 0.8 is plausible, below that is usually noise.
• Audit — the last 100 accesses (create, update, insert_chunks, query, delete, delete_chunks) with timestamp and source IP.

Pause, flush, delete

Quotas and what they measure

Security

• Prompt-injection sanitising is always on. Every chunk is stripped of ChatML / Llama / FIM control tokens before it is embedded. There is no switch, because a poisoned chunk retrieved into an agent's context is indistinguishable from an instruction the user wrote.
• Strict scan mode (on by default, per store) blocks file ingest until the malware scanner returns a clean verdict. Turning it off falls back to the platform-wide gate, which lets a file through while its scan is still pending. Leave it on for any store an AI agent can read.
• Credentials are encrypted at rest and decrypted only for the duration of one call. Marking a credential sensitive hides host and database from API responses while keeping it functional.
• Metadata filters are data, never query structure. A filter must render to a flat object of scalar values. Objects, arrays, and keys starting with $ are rejected, and a filter that fails to render aborts the operation instead of falling back to no filter — a filter nobody understands must never quietly widen into “everything”.

Using a store from a flow or an agent

The Vector Store node

Drop a Vector Store node on the canvas to insert, query, or delete chunks as part of a pipeline: scrape a page and index it, answer an incoming question with retrieved context, drop a document when the source system deletes it. Full reference: Vector Store node.

As a tool on an AI Node

On an AI Node, Tools → add a Vector Store turns each selected store into a callable tool named after it — a store called “Company Docs” becomes query_company_docs, described with the store's own description plus how many chunks it holds. The model decides when to search and with what phrasing; you keep control of the envelope:

• Default Top K — how many passages come back. The model may raise it up to 20.
• Min score — a floor the model cannot change. Matches below it never reach the context window.
• Name and description — editable, and worth editing: they are the only thing the model reads when deciding whether this store is relevant.

The store binding itself is fixed once added — remove the tool and re-pick to point it somewhere else.

Troubleshooting

Queries return nothing, or nothing relevant

Work through it in this order. Open the Content tab and read a few chunks: if they end mid-sentence, your chunks are too small — raise Size (remember: characters), flush, and re-ingest. If the content looks right, run the same question in the Query tab with no min score and look at the raw scores; if the best is around 0.5 the store simply does not contain the answer. If a node returns nothing but the playground works, the difference is almost always a metadata filter or a min score set on the node.

Changing chunk size does not change the number of chunks

Your content is JSON, and the JSON path uses its own limit. Set Max chars/chunk under JSON in the Vector Store node's Advanced tab, or feed the store plain text instead.

A metadata filter errors on the managed backend

Atlas requires every field used in a vector-search filter to be declared in the index, and the managed index declares only the tenancy field. Filtering by chapter therefore fails — it does not return an empty result, which makes it look like a data problem. Options: use a bring-your-own Postgres store, where any metadata key filters with no setup; use your own Atlas cluster and declare the paths in your index; or split the distinction into separate stores.

“At the cap” — the New store button is disabled

Plan limit on the number of stores. Delete an unused store or upgrade. The chunk counter next to it is a separate limit: hitting that one blocks ingest, not creation.

A model shows “Coming soon” and cannot be picked

Its vector index has not been provisioned on the managed cluster. Pick another model, or use a bring-your-own backend where you create the index yourself.

Ingest fails with a scan status message

Strict scan mode is on and the file has not been cleared yet. Wait a few seconds and retry — a verdict of infected or scan_failed is blocked in every mode.

[x] sourceDocId set on every document you may want to remove later
[x] chunk Size in characters, sized to the shape of your content
[x] .md uploaded as .md, not .txt
[x] Query tab returns > 0.8 for a question you know the answer to
[x] min score set on the node or tool, not left to chance
[x] BYO backend re-tested after any cluster change