Skip to main content

Vector Store

Chunks sitting in a store aren't searchable yet. Making them searchable means turning each one into a vector and putting it in a vector store — the step Flowera calls upserting.

Embeddings and vector stores​

An embedding model converts text into a list of numbers that captures its meaning. Passages about refunds land near each other; passages about shipping land somewhere else. A vector store holds those numbers and answers the question "which chunks are nearest to this one?"

At run time the customer's question goes through the same embedding model, and the nearest chunks come back. That's the whole trick — and it's why retrieval finds a passage that says "money back within 30 days" when the customer asked about "getting a refund". No shared keywords, similar meaning.

Configuring the store​

Open a document store and configure three things:

SettingWhat it does
EmbeddingsThe model that turns text into vectors
Vector StoreWhere those vectors are kept
Record ManagerOptional. Tracks what's already indexed so re-upserting updates instead of duplicating

Choosing an embedding model​

OpenAI, Google, Cohere, Mistral, Voyage, Azure, Bedrock, Ollama, and others are available. For most workspaces one of the standard OpenAI or Google embedding models is the right answer.

Two rules matter more than the choice itself:

  • Multilingual content needs a multilingual model. If your documents are Turkish and your customers ask in Turkish, verify the model handles it — some are heavily English-weighted.
  • Never change the model on a populated store without re-upserting everything. Vectors from two different models aren't comparable, and the resulting store returns nonsense with complete confidence. This includes switching between OpenAI and Azure: the models have the same names, but you still need to re-upsert if the model itself changes.

Azure OpenAI Embeddings has a Model Name dropdown like the other providers. On Azure the selected model also determines which deployment the request goes to, so leaving it unset means falling back to whatever deployment is stored on the credential — pick a model explicitly.

Choosing a vector store​

Flowera PostgreSQL VectorDB is the built-in option and needs no setup — start there. Pinecone, Qdrant, Chroma, Milvus, Weaviate, Supabase, Redis, MongoDB Atlas, Elasticsearch and more are available when you have an existing deployment or specific scale requirements. Each external one needs its own credential.

Record Manager​

Without a record manager, upserting an already-indexed store can add a second copy of every chunk — and duplicate chunks crowd out other results. With one, Flowera knows what's already there and updates rather than duplicating.

Add it if you re-upsert regularly, for example on a nightly sync. Not every vector store supports one; the option is greyed out where it doesn't apply.

Upserting a store​

Upsert All Chunks embeds every chunk and writes it to the vector store. The store shows Upserting while it works and Upserted when it's done. Until a store reaches Upserted, a Retriever pointed at it finds nothing.

Upsert after every change: a new loader, an edited chunk, a deleted one. The badge won't tell you — it stays Upserted from the previous run while the index serves the old content.

Upserting costs money. Each chunk goes through the embedding model once, so a large document set is a real (if small) charge — and a reason not to re-upsert the whole store when only one loader changed.

Upsert history​

The history icon inside the Upsert All Chunks screen lists every upsert with its timestamp and how many vectors were added.

It's the fastest way to answer "did this actually index?" — and to spot the classic failure where a store reports Upserted but the last upsert added zero vectors because the loader produced no chunks.