Couchbase · Vector database
Vector database: how it powers RAG and semantic search, and when you need a separate one
A vector database stores numerical fingerprints of text, images or other content, called vectors, and finds the items whose meaning is closest to a question. It is the part of an AI assistant that fetches the right passages from your own documents before a language model answers. This guide explains what it does, when a separate vector store is worth running and when vector search inside your operational database is enough, what Couchbase offers, and how data residency shapes Saudi AI projects.
Published 10 min read
Orientation
At a glance
The guide in one table, before the detail.
- What a vector database does
- Stores vectors and finds the nearest ones to a query: search by meaning rather than exact words
- Why AI projects need one
- Retrieval-augmented generation (RAG): the assistant answers from passages it retrieves from your documents
- Separate store or built-in
- Built-in vector search keeps vectors next to the data they describe; a separate store adds a system to sync and secure
- What Couchbase offers
- Three vector index types, in Couchbase Server and in Capella, alongside SQL++ and full-text search
- What it does not do
- Create the vectors: an embedding model you choose does that
- The Saudi question
- Where the documents, the vectors, the embedding calls and the model calls are processed
In short, for executives
- What it is: a vector database finds content by meaning, so an AI assistant can locate the right paragraph among thousands of policies.
- Why it matters: a language model alone does not know your organisation; retrieval gives it your current documents, with their source.
- The design choice: a separate vector store is one more system to synchronise and secure; vector search inside the database that holds the data is often enough.
- The Saudi question: vectors are derived from your data. They follow the same residency rule as the documents they come from.
What a vector database does, in plain terms
A classic search matches words. Ask for "annual leave for contractors" and a policy that says "vacation entitlement for non-permanent staff" may be missed, although the meaning is the same.
A vector database works differently. Each piece of content is first passed through an embedding model, which turns it into a vector: a long list of numbers that places the content in a space where similar meanings sit close together. The question is turned into a vector the same way. The database then finds the stored vectors nearest to the question's vector, using a similarity measure such as cosine similarity or Euclidean distance. That is vector search, also called semantic search.
Read more
Three points are easy to miss:
- The database does not understand the text. It compares numbers. The quality of the match depends heavily on the embedding model, including how well it handles Arabic, English and mixed text.
- "Nearest" is not "correct". Vector search always returns the closest items, even when none of them answers the question. The application has to decide when a result is too weak to use.
- Large indexes are approximate. At scale, most vector indexes trade a little accuracy for speed, so the trade is tested.
Vector search, RAG and hybrid search: how an AI assistant finds its answer
Most enterprise AI assistants follow one pattern, retrieval-augmented generation (RAG). Documents are split into passages, each passage is embedded and stored with its vector, and at question time the system retrieves the closest passages and hands them to the language model with the question. The model answers from those passages and cites them. The database behind this is what people mean by a RAG database.
Read more
RAG is popular because documents can change daily without retraining a model, access rules apply before passages reach the model, and every answer can point to its source.
Pure vector search is rarely enough in practice. A user asking about "circular 45" wants that exact document number, which a word match finds better than a meaning match. A user in the Jeddah branch should not receive passages from a policy that applies only elsewhere. That is why most production designs use hybrid search: vector similarity combined with keyword matching and filters on ordinary fields such as department, language, document date or classification.
RAG quality is usually decided less by the database than by the work around it: how documents are split, which embedding model is used, which filters apply, and how answers are tested on real questions in both languages. Our enterprise AI page covers that wider programme, and our LLM observability page covers how to watch retrieval quality once the assistant is live.
Relatedenterprise AI page
A separate vector store, or vector search inside your operational database
This is the first architecture decision of most AI projects. Neither option is right everywhere; the table shows what each one costs you.
| Question | Separate vector store | Vector search inside the operational database |
|---|---|---|
| Where the vectors live | In a second system, copied from the source data | In the same records as the data they describe |
| Keeping them current | A sync pipeline must update or delete vectors when the source changes | Updated with the record, in the same write path |
| Filters and access rules | Metadata must be copied and kept consistent in both systems | Applied to the same fields the application already uses |
| Security and residency review | Two systems to secure, back up and keep in the Kingdom | One system, already reviewed |
| Operations | Another platform to size, patch and monitor | Uses the cluster and skills you already run |
| When it is usually the better choice | Very large vector collections on their own, served apart from any operational data | Vectors tied to operational data: catalogues, cases, customers, documents the application already stores |
Ask any supplier: when a source record changes or is deleted, how fast does its vector change, and who owns that pipeline? A design without an answer returns stale content.
Couchbase vector search: what the platform offers
Couchbase is a distributed NoSQL database that stores JSON documents and key-value data, queried with SQL++. Interkey is a Couchbase technology partner and sells Couchbase Capella. According to Couchbase's documentation, vector search runs inside the same platform, with vectors stored as an attribute of the document they describe. Couchbase lists three vector index types:
- Hyperscale Vector Index (first available in Couchbase Server 8.0): for pure vector search such as content discovery and recommendations, which Couchbase describes for collections of tens of millions to billions of documents.
- Composite Vector Index (8.0): a secondary index with one vector column alongside ordinary fields. Couchbase notes that it applies the field filters first and runs the vector search on the results, which suits searches narrowed by department, region or status.
- Search Vector Index (first available in 7.6): in the Search service, combining vector search with full-text and geospatial search in one index. This is Couchbase's route to hybrid search.
Read more
Couchbase's documentation lists dot product, cosine similarity and Euclidean distance as similarity measures, with Euclidean available on the Hyperscale and Composite indexes. It also states that Couchbase Server implements no embedding model: vectors come from a model you choose and are stored in your documents. Couchbase describes Capella options that integrate embedding models; regional availability is checked at design time.
Capella, Couchbase's managed service, lists vector search indexes among its features, next to SQL++, full-text search and eventing. For the wider platform, see our NoSQL database page.
Where it does not fit. If your documents live in a file share with no operational database behind them, and nothing else will use Couchbase, adopting a database cluster only for search is a large step. The assessment says so when that is the case.
Vector database in Saudi Arabia: data residency for AI projects
In the Kingdom, the residency question in an AI project is wider than the database. Four flows each need a written answer:
- The source documents and the passages cut from them.
- The vectors. They are derived from the text and stored next to it. Treat them as the same class of data as the passages they come from.
- The embedding calls. Every passage, and every question, is sent to the embedding model. If that model is a service abroad, the text leaves the Kingdom each time.
- The language-model calls, and the logs that record prompts and answers.
Read more
Which data must stay is decided by your classification and the rules that apply to you: the National Cybersecurity Authority's controls (nca.gov.sa) and the Personal Data Protection Law overseen by SDAIA (sdaia.gov.sa). Our data residency guide explains how to write that map.
For the database, Couchbase gives two options. Self-managed Couchbase Server runs on infrastructure you control in the Kingdom. Couchbase Capella runs on AWS, Google Cloud or Microsoft Azure, and as of 2 November 2026 its published regions include Google Cloud's Dammam region (me-central2). See Capella or self-managed for the comparison.
For the model side, the Kong AI Gateway gives one control point for LLM and agent traffic, with token budgets, PII redaction before a prompt leaves and usage records. The database decides what the model may see; the gateway decides what leaves, and to which model.
Support comes from Riyadh, from Interkey engineers who work in Arabic and English, through design and operation.
How Interkey delivers the data layer of an AI assistant
-
Use case and residency review.
Which questions the assistant must answer, from which sources, for which users, and where each data flow may be processed.
-
Data preparation.
Sources cleaned, split into passages with their metadata, and access rules mapped to fields that filters can use.
-
Embedding model choice.
Tested on your own Arabic and English questions, in a location your residency rule allows.
-
Index design.
The vector index type, similarity measure and filters chosen against measured queries, with hybrid search where exact terms matter.
-
Evaluation set.
A list of real questions with their expected sources, run before go-live and after every change.
-
Operate or hand over.
Re-embedding when the model changes, index tuning and monitoring under a written managed-services scope, or a documented handover to your team.
What drives the cost of a vector database project
We do not publish a price or a duration; both depend on the scope. The Couchbase licence follows the operating model: Capella is billed per node per hour, and self-managed Couchbase Server is a subscription priced by the number of production nodes. The engineering cost is driven by:
- the number and state of the sources, which usually matters more than their size;
- how often content changes, which sets the work of keeping vectors current;
- the access rules the search must respect;
- where the embedding and language models may run;
- the size of the evaluation set.
The review is a fixed piece of work; the build is priced by scope, with vendor licensing shown separately.
Questions buyers ask about vector databases
Do we need a separate vector database for a RAG project?
Not always. If the content already lives in an operational database that offers vector search, keeping vectors there avoids a second system to sync and secure. A separate store makes sense mainly for very large vector collections with no operational data behind them.
Can a vector database search Arabic documents well?
The database compares vectors; Arabic quality comes from the embedding model. Test candidate models on your own Arabic, English and mixed questions before choosing, and use hybrid search so exact names and numbers still match.
Can our vectors and AI search data stay inside Saudi Arabia?
Yes for the database: Couchbase Server can run in your own data centre in the Kingdom, and as of 2 November 2026 Capella's published regions include Google Cloud's Dammam region. The embedding and language-model calls need the same check, because each sends text to the model.
Does Couchbase create the embeddings for us?
Couchbase's documentation states that Couchbase Server implements no embedding model: you generate vectors with a model you choose and store them in your documents. Couchbase describes Capella options that integrate embedding models; regional availability is checked during design.
How is Couchbase vector search licensed in KSA?
Vector search is part of the platform, so it follows the platform's licence. Capella is billed per node per hour and Interkey sells it; self-managed Couchbase Server is a subscription by production node, quoted alongside our work.
How long does it take to put an AI assistant on our own documents?
It depends on how many sources there are, how clean they are, the access rules and how many test questions the business wants answered before go-live. We estimate the duration from the review, not before it.
Next
Related pages
Next step
Plan the data layer for your AI assistant
Tell us which documents or records the assistant must answer from, which database holds them today, who may see what, and where the data must be hosted. We will reply with the design that fits and the first step.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia