Service Vector search implementation · pgvector + Pinecone + Qdrant · UK

Vector search implementation that returns the right. answer, not the nearest one.

Most semantic search ships as a notebook that returns plausible-looking results, then drifts the moment real queries arrive. We build it as a product: pgvector, Qdrant or Pinecone, hybrid retrieval with BM25 and a reranker, multi-tenant scope, an eval suite, and observability.

24hreply, from a senior
100+projects shipped since 2019
Senioronly, on the spine
(Why data teams sign)

You need vector search implementation. Eleven shipped since 2023. Zero production incidents.

Semantic search is a retrieval product, not a notebook. We build the eval set first, then the index, then the reranker, so quality stops being a guess and starts being a number you both watch.

0

5day

0

The founder this page is for“rip + replace” · 25% diligence haircut · signed at ask

The demo searched well. Real queries didn’t. That’s when they called us.

01

A UK SaaS scale-up signed us for vector search implementation after six months of in-house effort. Two engineers part-time, no observability, no audit log, and a Confluence page for a runbook. The acquirer’s CTO walked the codebase pre-LOI and said: “rip and replace, or a 25% diligence haircut”.

02

The product wasn’t the problem. The retrieval was. They’d shipped a single embedding model, no reranker, no hybrid fallback, and no way to tell a good answer from a near one. We rebuilt it over 10 to 14 weeks. Senior engineers paired daily, ADRs the same day, the eval pipeline wired on day one.

03

The acquirer’s CTO came back to the diligence call, walked the same surface, and signed retention. Full team kept. Deal closed at ask. This page is for the founder or data-lead whose semantic search is returning the wrong answers and who wants it shipped without taking the business down.

Data is the moat, retrieval is the proof
Vector search implementation · the non-negotiables

Retrieval as a product.
Eight things every system we ship has.

The shape your users expect, because good search feels obvious only when it works. Open any row.

100 to 300 real queries with known-good answers. Recall@k and MRR measured on every change. Quality is a number, not a vibe.

Dense vectors find meaning, BM25 finds exact terms. Fused with reciprocal rank fusion so product names and codes don’t vanish.

A cross-encoder re-scores the top 50 so the right answer lands at position one, not position seven. Latency budgeted.

Semantic chunking with overlap, tuned against your eval set. Metadata kept on every chunk so filters work alongside similarity.

Tenant filters pushed into the index, not bolted on after. One customer never sees another’s documents. Tested in CI.

Idempotent embedding and upsert. Re-index without duplicates. Backfill a new model without taking search down.

P95 latency, recall drift, and cost per query tracked live. Replay any production query. No silent regression after a model swap.

Embedding model behind an interface. Swap OpenAI for a self-hosted model, re-score the gold set, ship only if recall holds.

The eight retrieval pains we hear in every audit call

The pain. The day-1 retrieval architecture.

Each one is the difference between search your users trust and search they route around.

  1. 01
    The wrong-answer problemDay-1 architecture

    “The result looks plausible, but it’s not the document the user wanted.”

    Hybrid retrieval plus a reranker, scored on evals. Dense vectors plus BM25, fused, then a cross-encoder re-scores the top 50. Recall@5 measured on your real queries before it ships.

  2. 02
    The exact-match missDay-1 architecture

    “Searching a product code or SKU returns everything except the product code.”

    BM25 keeps lexical matches in the candidate set. Pure vector search loses exact terms. We keep a keyword index alongside it so codes, names, and acronyms always surface.

  3. 03
    The “feels right” trapDay-1 architecture

    “We changed the chunking and nobody can tell if search got better or worse.”

    An eval gold set with CI gating. 100 to 300 queries with known answers. Recall and MRR run on every change. A regression over the threshold blocks the deploy.

  4. 04
    Embedding lock-inDay-1 architecture

    “Our embedding provider raised prices and we’re tied to one model.”

    Embedding behind an interface, swap in config. Swap OpenAI for Cohere or a self-hosted model, re-embed in the background, verify against the gold set, then cut over. Done without downtime.

  5. 05
    Per-tenant cost blindnessDay-1 architecture

    “Two customers are most of our embedding bill and we’ve no idea which.”

    Per-tenant query and embedding cost log. Every query and upsert logged with tenant, token count, and GBP cost. Live dashboard. Pricing decisions become data, not guesses.

  6. 06
    The stale-index problemDay-1 architecture

    “A document was updated last week and search still returns the old version.”

    Idempotent ingestion with freshness windows. Change-data-capture on the source. Re-embed only what changed. Re-index without duplicates. Stale results stop happening.

  7. 07
    Tenant data leakage fearDay-1 architecture

    “How do we know one customer can’t retrieve another customer’s documents?”

    Tenant filters pushed into the query, tested in CI. Scope enforced at retrieval time, not in application code. A cross-tenant test runs on every PR and fails the build if isolation breaks.

  8. 08
    The demo that won’t scaleDay-1 architecture

    “The notebook was lovely. At ten million vectors the latency fell apart.”

    Production-shape index from week one. HNSW tuning, sharding, and a latency budget set on day one. The demo is the production system, just with fewer vectors. No rebuild-for-launch sprint.

Vector search tech stack · pgvector + Pinecone + Qdrant + Python

The stack we ship every vector search implementation on.

pgvector when your data already lives in Postgres, Qdrant or Pinecone when scale or filtering demands it. Python for embeddings and evals, the product surface in MERN.

T1

What we build every retrieval system on

eval-first
PostgreSQL + pgvectorQdrantPineconePythonFastAPIOpenAI embeddingsCohere RerankBM25 / OpenSearchReact + Next.jsNode.jsTypeScriptMixpanel
T2

When your brief calls for it

reach when needed
WeaviateMilvusSelf-hosted embeddingsHuggingFaceLangChain / LangGraphMongoDB Atlas Vector
T3

The infrastructure for scale

AWS-default
AWSAWS BedrockAWS LambdaKubernetes (EKS)DockerRedisApache KafkaTerraformDatadog + SentryLangSmithGitHub ActionsOpenTelemetry
Vector search implementation · what we work on

What we work on

Retrieval built as a product: hybrid search, a reranker, an eval gold set, and per-tenant scope, scored before it ships.

6194%

Recall@5 on the eval set, after the rebuild

250%

Acquirer diligence haircut, then full retention

“The demo searched well. Real queries didn’t. They rebuilt the retrieval, wired the eval pipeline on day one, and the acquirer’s CTO signed retention at ask.”

Data lead, UK SaaS scale-up

After a 25% diligence haircut became full retention

001

An eval gold set, built before the index

100 to 300 real queries with known-good answers. Recall@k and MRR measured on every change. Quality is a number, not a vibe.

002

Hybrid retrieval: vectors plus BM25

Dense vectors find meaning, BM25 finds exact terms. Fused with reciprocal rank fusion so product names and codes don’t vanish.

003

A reranker on the top candidates

A cross-encoder re-scores the top 50 so the right answer lands at position one, not position seven. Latency budgeted.

004

Multi-tenant scope, enforced at query time

Tenant filters pushed into the index, not bolted on after. One customer never sees another’s documents. Tested in CI.

005

Observability and a model-swap path

P95 latency, recall drift, and cost per query tracked live. The embedding model sits behind an interface, so a swap re-scores the gold set and ships only if recall holds.

Proof

The search that holds up

Real lines from the rebuild: the demo that searched well, the diligence call, and the recall number the acquirer read.

100% would refer us
Data lead, UK SaaS scale-up Six months of in-house effort, no eval set
The demo searched well. Real queries didn’t. That’s when we called them.
01 / 06
Vector search implementation · honest answers

What CTOs actually ask before signing

Pain-first, soft-second.

It depends on where your data lives and how you filter. pgvector is our default when your records already sit in Postgres and you want one database to operate. Qdrant when you need rich metadata filtering and self-hosting. Pinecone when you want a managed index and don’t want to run the infrastructure. We decide it at the audit, against your data and your latency budget, not from a slide.

The audit is £8K fixed for five days. The sprint is typically £35K to £85K fixed-price, scoped at the end of the audit so the number is honest before you commit. No day-rate, no scope creep. If the work is smaller than that, we’ll tell you in the audit and quote it down.

The eval gold set. We build 100 to 300 real queries with known-good answers with your team in week one. Recall@k and MRR run on every change, and CI blocks a deploy that regresses past the threshold. You launch when the number says it’s ready, not when the team feels brave. The number ships with the runbook.

Both. If you want a pgvector developer for hire to pair with your team, we’ll embed one senior engineer who reviews PRs and unblocks the build. If you want the whole vector search implementation delivered, we ship it fixed-scope. Either way the same senior engineers do the work, and your team keeps everything on handover.

Index and embeddings stay in the region you choose. For regulated data we self-host the embedding model on your VPC so nothing leaves your boundary. Signed DPA, SCCs for cross-border, and a sub-processor list before week one. Every audit we’ve faced has passed.

30-day walk-away both ways. Milestone billing 25/25/25/25. UK VAT registered, listed on Companies House, shipping since 2019. You’re never more than four weeks at risk of paying for nothing.

Every vector search implementation has two senior engineers paired, not one. Every decision goes into an ADR the same day. Mohit reviews every PR. In seven years, two engineers have left mid-project. Both handovers were inside 48 hours.

Yes, with 14 days’ notice. Engineers move to other projects. Spend pauses. Resume with 14 days’ notice. No cancellation fee. Done six times in 2025.

Vector search implementation — product screenshot / UI
In context

See it in context.

A look at the kind of vector search implementation surface we hand over — real screens, real data, documented and yours from day one.

Build the search that returns the right answer

One paragraph. That’s it.

Tell us what people search for, where the data lives, and where the wrong answers show up now. Mohit replies inside 24 hours: a clear yes, a clear no, or the one question that decides it.

Write to mohit@empyrealinfotech.com Replies in 24hEval-first retrievalpgvector + Qdrant + Pinecone
What happens after the email lands
  1. < 24h

    A personal reply.

    Yes, no, or the deciding question. Straight to your inbox.

  2. Week 1

    The eval set drafted.

    Real queries, known answers, the index choice argued on paper. Signed scope.

  3. Wk 12

    Search that holds up.

    Hybrid retrieval, a reranker, observability, the recall number your acquirer reads.