Data
Vector Databases
The retrieval layer behind semantic search and RAG — built on the database you already run until scale says otherwise.
Overview
A vector database stores and searches embeddings: numerical representations of text, images or other data as points in a high-dimensional space, produced by a model so that things which mean similar things sit close together. A sentence about a refund policy and a customer’s question about getting their money back end up near each other even though they share no keywords, because the embedding captures meaning rather than surface wording. Search, then, is no longer string matching — it is finding the nearest points to a query vector, and returning the source records they came from. That single shift, from lexical to semantic, is what makes this category worth understanding.
Searching a few thousand vectors is trivial; searching millions with low latency is not, because comparing a query against every stored vector is too slow. Vector databases earn their name through approximate nearest neighbour (ANN) indexes — structures such as HNSW (a navigable graph you walk toward the closest match) and IVF (which partitions vectors into clusters and only searches the promising ones). These trade a little accuracy for a large gain in speed, controlled by parameters that set how hard the index looks before it answers. Similarity itself is measured with a metric — usually cosine similarity or dot product — and the good systems let you combine vector search with ordinary metadata filters and with keyword search, so you can ask for semantically similar documents that are also in the right language, from the right customer, and mention a specific term.
This matters now because embeddings are the retrieval layer for the current wave of AI. Retrieval-augmented generation (RAG) works by finding the passages relevant to a question and handing them to a language model as context, so the model answers from your data rather than its training. The same mechanism powers semantic search, recommendations, deduplication and anomaly detection. Our position on the tooling is deliberately unfashionable and we will state it plainly: most teams do not need a separate vector database. The pgvector extension, running inside the PostgreSQL you already operate, handles a large share of real workloads — and keeping vectors next to your source data removes an entire class of synchronisation problems that a dedicated store creates.
Best for — Teams building semantic search or RAG over their own data who want the retrieval layer done honestly — usually pgvector first, a dedicated store only when scale forces the move.
Why teams choose Vector Databases
Search by meaning, not wording
Embeddings match on intent, so a query finds relevant content even when it shares no words with it. This is the capability keyword search cannot offer and the reason the category exists — it turns a corpus users could not find their way around into one they can actually ask questions of.
The retrieval layer that grounds AI
RAG is only as good as what it retrieves. A well-built vector index feeds a language model the right passages, so answers come from your data with citations you can check — the difference between a useful assistant and a confident fabricator.
One system when pgvector fits
Keeping vectors in PostgreSQL alongside their source records means one database to run, back up, secure and reason about. You avoid a second store, a sync pipeline, and the drift between them — a saving that compounds over the life of the system.
Why businesses choose Vector Databases
- You want semantic search or RAG built on an honest assessment of whether you need a dedicated database at all — most teams do not, and we will tell you so.
- You already run PostgreSQL and would rather add pgvector than adopt and operate a second data store before the workload justifies it.
- You want retrieval quality treated as an engineering problem — chunking, metadata, hybrid search and evaluation — not just a database you point at your documents and hope.
- You expect a clear, costed path from pgvector to a dedicated store, so you know the signals that should trigger the move and are not surprised by them later.
What we build with Vector Databases
The capabilities this technology is genuinely strong at — and what we most often build with it.
Embedding pipeline
We build the pipeline that turns your content into vectors — chunking documents sensibly, choosing an embedding model that fits your data and budget, and handling re-embedding when the model or content changes. Retrieval quality is decided here far more than in the choice of database.
ANN index selection and tuning
HNSW for low-latency, high-recall search where memory allows; IVF and its variants where collections are very large. We set and measure the parameters that govern the recall-versus-latency trade-off rather than accepting defaults that were never chosen for your workload.
Hybrid and metadata-filtered search
Real queries are not purely semantic. We combine vector similarity with keyword search and hard metadata filters — language, tenant, permissions, date — so results are both relevant in meaning and correct in constraints.
Similarity metrics done deliberately
Cosine similarity or dot product, matched to how the embedding model was trained and how your vectors are normalised. Getting this wrong quietly degrades every result; we treat it as a decision, not a default.
RAG retrieval that a model can trust
Retrieval tuned for generation: the right number of passages, re-ranking where it earns its place, and citations carried through so answers can be traced back to source. We evaluate retrieval on its own before blaming or crediting the language model.
Sync and freshness handling
Where a dedicated store is warranted, we build the pipeline that keeps it current with the source of truth — incremental updates, deletes that actually delete, and a reconciliation path for when the two inevitably drift.
Use cases
Semantic search over a knowledge base
Documentation, policies, support tickets or contracts made searchable by meaning, so staff and customers find the right answer even when they phrase the question nothing like the source.
Retrieval-augmented generation
An assistant that answers from your data with citations — grounding a language model in retrieved passages so it responds from your corpus rather than its training, and can be checked.
Recommendations and related content
Surfacing similar products, articles or records by embedding similarity, giving genuinely relevant suggestions without hand-built rules or a separate recommendation engine.
Deduplication and anomaly detection
Finding near-duplicate records that differ in wording, or flagging entries that sit far from everything else in vector space — clustering and outlier detection that lexical comparison cannot do.
When Vector Databases is the right choice
- Right when you need semantic search or RAG over your own content — documentation, support history, contracts, product catalogues — and keyword search alone keeps missing results that are worded differently from the query.
- Right when you are already running PostgreSQL: pgvector adds vector columns and ANN indexes to the database that holds your source of truth, so retrieval and records stay in one system with one backup, one set of permissions and no sync job to break.
- Right when scale genuinely demands it — tens or hundreds of millions of vectors, very high query volume, or specialised indexing needs — at which point a dedicated store such as Pinecone, Weaviate, Milvus or Qdrant is the correct graduation, not the correct starting point.
- Wrong when a plain keyword or full-text search already answers your users’ questions well. Embeddings add real cost and moving parts; if lexical search is good enough, adding a vector layer is complexity you will maintain for no benefit.
- Wrong as a system of record. A vector database holds a derived, lossy representation for retrieval — it is not where your authoritative data lives, and treating it as such invites drift between what users see and what is true.
Vector Databases: pros and cons
Strengths
- Semantic retrieval that lexical search cannot match — the foundation for RAG, recommendations, deduplication and anomaly detection alike.
- pgvector brings vector search into PostgreSQL, so many teams get the capability with no new infrastructure and no data kept in two places.
- ANN indexes such as HNSW and IVF make low-latency search over large collections practical, with tunable dials to trade recall against speed as your needs change.
- Hybrid search and metadata filtering let you combine semantic similarity with keyword matches and hard constraints, which is what real queries actually need.
Trade-offs
- A dedicated vector store is an extra system to operate and, worse, to keep in sync with your source of truth — every write now has two homes and a chance to diverge.
- Embeddings are tied to the model that produced them: change the model and every stored vector must be regenerated and re-indexed, which is a genuine migration, not a config change.
- ANN search is approximate by design. You can miss relevant results, and pushing recall up costs latency — there is no setting that gives you both perfect accuracy and speed.
- Cost is real and often underestimated: generating embeddings, storing high-dimensional vectors in memory-hungry indexes, and paying per query or per node on a managed store all add up.
Architecture
The load-bearing decision is where vectors live. Our default is pgvector inside your existing PostgreSQL: vectors sit in a column beside the source record, ANN indexes (HNSW or IVF) accelerate search, and there is exactly one system to operate, back up and secure. Retrieval joins naturally to your relational data, so metadata filtering is just a WHERE clause, and there is no second store to keep in step. For a very large share of workloads this is not a compromise — it is the right architecture.
A dedicated vector store enters the design when specific signals appear: vector counts that strain PostgreSQL’s memory and index build times, query volume beyond what one database should carry alongside its transactional load, or indexing needs that pgvector does not serve well. At that point we introduce Pinecone, Weaviate, Milvus or Qdrant deliberately, and we design the synchronisation from the source of truth up front — because the moment vectors live apart from their records, keeping the two consistent becomes the central engineering problem, not an afterthought.
Performance
Vector search performance is governed by the ANN index and its parameters. HNSW trades memory for excellent recall at low latency; IVF trades some recall for a smaller footprint on very large collections. Every dial — how many candidates the index inspects, how the graph or clusters are built — sets a point on the recall-versus-latency curve. We measure where you sit on that curve against real queries rather than accepting whatever the defaults happen to give, because the right point depends entirely on your accuracy tolerance and latency budget.
The two costs teams underestimate are memory and embedding generation. High-dimensional vectors and their indexes are memory-hungry, and index build time grows with collection size. Generating embeddings — often an API call per chunk — has its own latency and price at ingestion and, painfully, again on any full re-embed. We plan for both: batching embedding calls, caching where content is stable, and sizing memory for the index rather than discovering the ceiling in production under load.
Security
Embeddings are derived from your content and can leak information about it, so they are not a form of anonymisation and must be protected like the source data. When vectors live in pgvector, they inherit PostgreSQL’s access controls, row-level security and encryption — one of the quieter advantages of keeping them there. With a separate store you own that protection yourself, and multi-tenant isolation becomes a metadata-filtering problem you must get exactly right, because a filter mistake here returns another tenant’s documents.
Where retrieval feeds a language model, the security boundary extends into the prompt. Retrieved passages carry whatever permissions their source records had, so we enforce access control at retrieval time — filtering by the requesting user’s rights before anything reaches the model — rather than hoping the model declines to reveal what it was handed. Embedding APIs are also a data-egress path: we are deliberate about what content leaves your environment to be embedded, and by whom.
Scalability
Scale is precisely the axis on which the pgvector-versus-dedicated decision turns, so we treat it as a planned progression rather than a guess made on day one. pgvector comfortably serves collections into the millions for many workloads; as vectors and query volume grow, PostgreSQL’s memory and its transactional duties become the constraint. We watch index build times, query latency at the tail, and the load vector search adds to the rest of the database — the honest signals that you are approaching the limit of the pragmatic option.
When those signals arrive, a dedicated store scales along dimensions PostgreSQL was not built for: horizontal sharding of the index, replication tuned for read-heavy search, and indexing strategies for hundreds of millions of vectors. The migration is real work, dominated by the synchronisation pipeline and a re-embed if the model changes too, which is exactly why we design the pgvector stage so the move is a graduation with a known trigger rather than an emergency rebuild.
Vector Databases integrations & ecosystem
The technologies we most often pair with it — each links to how we work with it.
How we work
We start by questioning whether you need vector search at all, and if you do, whether you need a dedicated database or whether pgvector in your existing PostgreSQL will do. That order matters: adopting a new data store is the expensive, sticky decision, and most teams reach for it too early. We would rather spend the first conversation talking you out of infrastructure you do not need than sell you a store you will spend the next two years synchronising.
From there we treat retrieval quality as the real engineering problem — chunking, embedding model choice, metadata design, hybrid search and honest evaluation on your own queries — because the database is the easy part and the quality lives everywhere else. The engineers who design the retrieval layer are the ones who run it, so we favour a system your team can operate: one store where possible, a clearly costed path to a second when scale demands it, and no cleverness we would not want to be paged about.
The service behind it
Delivered throughData EngineeringWhat we build with Vector Databases
The disciplines this technology most often shows up in — from a first build to taking over and stabilising an existing one.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves — including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Industries we use Vector Databases in
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
Also in Data
Related terms
Why teams choose us for Vector Databases
We will talk you out of a database you do not need
Our default answer is pgvector in the PostgreSQL you already run, because most workloads do not justify a separate vector store. We only recommend one when your scale genuinely forces it — and we will show you the signals that say so.
Retrieval quality, not just a store
The hard part is chunking, embeddings, metadata and evaluation, not the database. We build and measure the whole retrieval layer, so your search or RAG system actually returns the right things rather than merely running.
We operate what we build
We run the retrieval systems we ship, including the unglamorous parts — re-embedding when a model changes, keeping a dedicated store in sync, watching cost and latency. We design for that reality from the start.
Typical timeline
- 01
Discovery and approach
One to two weeks understanding the data and queries, deciding whether pgvector or a dedicated store fits, and choosing an embedding model and chunking strategy against your actual content.
- 02
Retrieval prototype
Two to three weeks building an end-to-end retrieval slice on real data and evaluating it on real queries, so quality is proven before the surrounding product is built.
- 03
Integration and tuning
Wiring retrieval into the application — hybrid search, metadata filtering, RAG or ranking as needed — and tuning the recall-versus-latency trade-off to your budget.
- 04
Hardening and handover
Freshness and sync where a dedicated store is used, access controls at retrieval time, cost and latency checks under load, and documentation so your team can run it.
How pricing works
- Fixed-scope builds for a defined retrieval feature — semantic search or a RAG pipeline over a known corpus — quoted once we understand the data, volume and quality bar.
- Monthly senior engagement where retrieval is part of a larger AI product and scope evolves, giving you continuity across embedding, retrieval and the application around it.
- Focused reviews of an existing vector setup — retrieval quality, cost, or a premature move to a dedicated store — priced by the assessment and delivered as concrete recommendations.
Hire Vector Databases engineers
Need Vector Databases capacity on your own team? We embed named senior engineers into your existing team — reporting to your leads, working in your rituals — so you add capacity without a hiring cycle.
Hire Vector Databases engineersCommon questions
Do we actually need a vector database?
Often not a dedicated one. If you already run PostgreSQL, the pgvector extension adds vector columns and ANN indexes to the database that holds your source data, and it handles a large share of real workloads. A separate store such as Pinecone or Qdrant is justified at large scale, very high query volume, or for specialised indexing — not as a starting point. Our default is pgvector, and we move only when your numbers demand it.
What is an embedding, in plain terms?
An embedding is a piece of content — a sentence, a document, an image — turned by a model into a list of numbers that represents its meaning as a point in a high-dimensional space. Content that means similar things ends up near each other, so you can search by similarity rather than by matching words. The vector database’s job is to store those points and find the nearest ones to a query quickly.
What does approximate nearest neighbour search trade away?
Speed for accuracy. Comparing a query against every stored vector is exact but too slow at scale, so ANN indexes like HNSW and IVF find the nearest matches approximately, inspecting only part of the collection. That means you can occasionally miss a relevant result, and pushing recall higher costs latency. We tune where you sit on that curve against your real queries rather than accepting defaults.
What happens when we change the embedding model?
You have to regenerate every vector. Embeddings are only comparable to others made by the same model, so switching models means re-embedding your entire corpus and rebuilding the index — a genuine migration with a real cost in time and API charges, not a configuration change. It is one reason we choose the embedding model carefully up front and plan for the day it changes.
What is hybrid search and why does it matter?
Hybrid search combines semantic vector similarity with traditional keyword search, and adds metadata filters on top. It matters because real queries need both: semantic search finds content that means the right thing, keyword search catches exact terms and names that embeddings can blur, and filters enforce hard constraints like tenant, language or permissions. Used together they return results that are relevant in meaning and correct in fact.
Building on Vector Databases?
A technical conversation with the engineers who would do the work. If we are not the right fit, we will say so on the call.