Vector Databases
Intermediate 14 min read Vector Databases

Choosing a Vector Store

Picking the storage that fits the workload

pgvector, dedicated vector DBs, managed search services, or 'just do it in the app' — the right store follows your scale, ops surface and query mix. A decision matrix beats brand loyalty.

vector storepgvectormanagedscaledecisionops
Prerequisites: pgvector in Postgres
Before we start

What you will learn

  • Compare store categories by capability
  • Estimate scale-to-store fit
  • Structure a selection test, not a brochure
Introduction

What is this?

Vector storage options span extensions (pgvector), dedicated vector databases (Qdrant, Weaviate, Milvus), managed services, and even simple hand-rolled ANN in memory. Selection is about your vector count, update cadence, metadata query complexity, and the operational surface you're willing to own — not a marketing table.

Motivation

Why do you need it?

  • Choosing wrong costs months of migration, not a weekend.
  • Hybrid/metadata needs quickly override pure ANN speed.
  • Self-hosted dedicated stores mean real ops — backups, upgrades, HA.
  • The 'best' store is the one your team can actually run and operate.
Think about it

Mental model

Imagine

Choosing a workshop space

Think of

Vector store selection

A home garage (pgvector) suits small jobs but lacks the lift for a fleet; renting a proper plant (dedicated DB) costs rent and safety rules but scales. Choosing the plant 'because it's a plant' without checking whether you repair cars rarely is buying room you'll never fill.

Mechanics

How it works

  • List hard requirements: scale, vector count, filters, hybrid, tenant isolation, latency SLO, ops budget.
  • Estimate dimension × N and index memory model for each candidate.
  • Prototype with YOUR queries + data on candidates (not tutorials).
  • Score candidates on eval metrics + ops maturity + cost.
  • Revisit annually or on scale jumps; lock the decision in config.

Selection drives.

Scale
Queries
Ops
Prototype
Lock
Real world

In production

  • A small product FAQ store uses pgvector in the existing Postgres.
  • A search-heavy catalog at 100M vectors picks a managed dedicated store.
  • Air-gapped analytics on 2B vectors self-hosts Milvus-class storage with GPU ANN.
Guidelines

Best practices

  • Start simplest (pgvector/app-side) and migrate when measurements force it.
  • Prototype identical queries against two candidates before deciding.
  • Include hybrid/metadata queries in your prototype, not just pure k-NN.
  • Estimate total cost of ownership, not sticker price (managed vs self-host labor).
Watch out

Common mistakes

  • Choosing by blog fame instead of your query mix.
  • Ignoring RAM: naive vector storage estimates are wrong by an order of magnitude.
  • Forgetting multi-tenancy isolation requirements until leaks matter.
  • Believing 'scale matters now' when the corpus is 100k rows.
Root cause analysis

Common issues

Error
Vector store chosen for 'scale' but team can't operate it
Root cause

Ops surface underestimated

Fix

Re-evaluate managed tiers or simplify to pgvector for the actual scale.

Error
P50 good, p99 bad
Root cause

Filter/memory unpredictability from planner

Fix

Tune index params or partition per tenant; check ANN behavior under filters.

When things break

Debugging tips

  • Latency on p99 spikes bent by metadata filters → candidate can't pre-filter well; re-test.
  • Migration pain later → didn't prototype filters/hybrid; backfill eval now.
  • Ops toil tracking high → your self-hosting ambitions exceed headcount.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

The deciding factor between pgvector and a dedicated store is…

2

Managed vector services eliminate operational cost.

Go deeper

Official documentation

Vector database comparison (market survey)
docs
Qdrant product docs
docs