Vector Databases in the Cloud

The search problem that keyword indexes cannot solve

Traditional search matches words. Ask for "how do I cancel" and a keyword index finds documents containing those words, and misses the page titled "ending your subscription" entirely.

Vector search attacks the problem differently. An embedding model converts text, images or audio into a list of numbers positioned so that similar meaning lands in a similar place. Finding relevant content then becomes a geometry question: which stored points are nearest to the point representing this query.

A vector database is the system that stores those points and answers that question quickly. It has become standard infrastructure because retrieval augmented generation depends on it, but the technique long predates the current interest and serves recommendation, deduplication and image search just as well.

What the system actually has to do

Strip away the branding and every vector store performs the same four jobs.

1. Store vectors of a fixed width alongside the metadata and source text you will need when a match is returned.
2. Build an index that makes nearest neighbor lookups fast enough for a request path.
3. Answer queries against a distance measure, usually cosine similarity, inner product or Euclidean distance.
4. Filter by metadata, so a query can be restricted to one tenant, one language or one date range.

The fourth job is where implementations diverge most. Filtering after the nearest neighbor search can return fewer results than requested when the filter is selective. Filtering during the search preserves result counts but complicates the index. Ask which approach a candidate uses, because it determines whether multi tenant filtering behaves sanely.

One more constraint runs through all of it: the embedding model and the index are a matched pair. Change the model and every stored vector becomes meaningless, so re-embedding the entire corpus is part of that upgrade rather than an optional extra.

Index families and the trade they make

Exact nearest neighbor search compares the query against every stored vector. It is perfectly accurate and scales badly, which is why production systems use approximate methods that accept a small chance of missing a true match in exchange for far faster answers. That accepted loss is called recall, and it is a tuning dial rather than a defect.

Graph based indexes are the common default because they answer queries well without much thought. Their cost is memory, since the graph and the vectors generally need to be resident, and rebuild time when the collection changes substantially.

Where to put it on a cloud platform

You rarely need to introduce a new database. Most teams already run something that can do this job adequately.

Your existing relational database. The pgvector extension adds vector types and index support to PostgreSQL, and it is available on the managed PostgreSQL offerings of all the major platforms. One database, one backup regime, one set of credentials, and joins against your existing tables.

Your existing search engine. OpenSearch and Elasticsearch both support vector fields and nearest neighbor queries, which suits teams who already run one and want hybrid keyword and semantic search in a single query.

Your existing cache or document store. Redis offers vector similarity search in its query engine, and MongoDB Atlas provides vector search over collections. Both appeal for the same reason: one fewer system to operate.

A platform native managed service. Google Cloud offers Vector Search within Vertex AI, and Azure AI Search includes vector retrieval alongside its keyword capabilities. These integrate tightly with each platform's model APIs.

A purpose built vector engine. Milvus, Qdrant, Weaviate and Chroma are dedicated systems available as open source you host yourself or as managed offerings, with richer vector specific features than a general database provides.

Why Postgres is usually the right first move

Unless you have a reason to do otherwise, start with pgvector on a managed PostgreSQL instance. The argument is operational rather than technical.

You get transactions, so a document and its embedding are written or not written together. You get joins, so filtering by tenant, permission or date uses ordinary SQL with real indexes behind it. You get the backup, restore and point in time recovery you already trust, as described in database backups and point in time recovery. And you add no new service to monitor, patch or explain to a colleague.

The limits are real and they arrive later than most people expect. Very large collections, extremely high query rates, or a need for vector specific features that a general database does not offer are all legitimate reasons to migrate. Migrating is also easier than the reverse, since you will have learned what your query patterns actually are. The managed versus self hosted question is covered in managed databases versus self hosted.

Sizing, recall and the things that bite

Three practical issues account for most of the trouble teams run into.

Memory is the binding constraint. Graph indexes want vectors and structure in memory, and the footprint scales with collection size and vector width. Choosing an embedding model with a smaller output width, or enabling quantization, moves that number more than any other decision.

Recall must be measured, not assumed. Build a small labeled set of queries with known correct answers and check what fraction the index returns. Without that, index parameters are being tuned blind, and a configuration change that silently reduced quality will surface as vague complaints months later.

Ingest and query compete. Building or updating an index is expensive, and doing it while serving queries degrades both. Plan bulk loading as a distinct operation, and decide deliberately whether new documents appear immediately or on a schedule.

Key takeaways

• A vector database stores embeddings and answers nearest neighbor queries with metadata filtering; the filtering behavior differs most between products.
• Approximate indexes trade a measurable amount of recall for speed, and graph based indexes are the usual default at the cost of memory.
• pgvector on managed PostgreSQL is the sensible starting point for most teams, and migration later is easier than starting complicated.
• Embeddings and index are a matched pair; changing the embedding model means re-embedding everything.
• Measure recall against a labeled query set before tuning index parameters.
• Retrieval built this way feeds directly into the patterns in the Amazon Bedrock overview and the Vertex AI overview.

Any of these options need a cloud account underneath them. Managed PostgreSQL with the extension is available on the large platforms, starting from a Google Cloud account or an AWS account, and the AWS and Azure comparison covers how their managed database and search services line up. The official references are the Vertex AI Vector Search documentation and the pgvector project repository.