The vector database market has crowded fast, and most comparison articles devolve into feature tables that go stale within months. A more durable way to choose is to understand the categories of tooling, the criteria that genuinely differentiate them, and the trade-offs you are really deciding between. Specific products come and go; the decision axes endure.
This survey groups the landscape into a few archetypes, names the criteria worth weighting, and offers a practical path to a choice you will not regret in six months. We will mention representative tools by category rather than ranking them, because the right pick depends entirely on your workload, scale, and team.
The aim is to leave you able to evaluate any new entrant against the same criteria, not to memorize today's leaderboard.
The Categories of Tooling
Database Extensions
The simplest option is a vector extension to a database you already run. PostgreSQL with pgvector is the common example: it stores and queries vectors alongside your existing relational data, no new infrastructure required. For modest scale, this is often the right answer, and it keeps everything in one place for joins and transactions.
Dedicated Vector Databases
Purpose-built systems, both self-hosted and managed services, are designed from the ground up for high-volume similarity search. They tend to handle large scale, advanced indexing, and operational concerns more gracefully than extensions. Managed offerings remove the burden of running the infrastructure, at a price and with less low-level control.
Within this category there is real variety. Some emphasize developer ergonomics and a simple API; others expose deep index tuning for teams that need to manage the recall-versus-speed trade-off precisely. Some are cloud-only managed services; others ship as software you run yourself or as both. The right one depends less on which has the longest feature list and more on which matches how your team works and how much control you actually need over the internals.
Libraries and Embedded Stores
At the smallest end, indexing libraries and embedded stores run inside your application process with no separate server. They are excellent for prototypes, single-machine workloads, and learning, the kind of first experiment described in What Embeddings Are and Why Databases Store Them. They become limiting once you need distribution or persistence at scale.
The value of starting here is speed of learning, not speed of queries. With no server to provision, you can have similarity search running in minutes and build intuition about chunking and model choice cheaply. Many teams underestimate how far an embedded library carries them; a single machine with ample memory handles surprisingly large workloads. Treat outgrowing it as a good problem, a signal of real adoption, rather than a reason to over-provision a distributed system before you have proven the idea works at all.
The Criteria That Matter
Scale and Latency
How many vectors will you store, and how fast must queries return? Tens of thousands fit anywhere; millions push you toward dedicated systems with tuned indexes. Be honest about projected scale, since migrating between categories later is real work.
Operational Burden
Who runs this, and how much time can they spend? A managed service trades money for freedom from indexing, scaling, and uptime work. Self-hosting trades engineering time for control and lower per-vector cost. For a small team, the managed option often pays for itself.
Filtering and Hybrid Search
Can the tool combine similarity with metadata filters and keyword search? These capabilities, central to the practices in Opinionated Rules for Running Embeddings in Production, vary widely across tools. If your queries mix exact terms and concepts, weight hybrid support heavily.
Index Flexibility
Does the tool let you choose and tune index types, or hide them behind defaults? More control helps when you need to manage the recall-versus-speed trade-off explicitly, a decision unpacked in Flat, Graph, or Inverted: Choosing How Vectors Get Searched. Less control simplifies life when defaults suffice.
Trade-Offs You Are Really Deciding
Simplicity Versus Scale
Extensions and embedded libraries are simple but cap out; dedicated databases scale but add a system to operate. The honest question is not "which is best" but "what scale am I actually at, and where am I headed." Over-engineering a small project wastes as much as under-provisioning a large one.
Money Versus Time
Managed services convert engineering time into a subscription. Self-hosting converts a subscription into engineering time. Neither is universally cheaper; it depends on your team's size, skill, and how much that team's time is worth elsewhere.
A Practical Path to Choosing
Start Where You Already Are
If you run PostgreSQL and your scale is modest, start with pgvector. It removes a decision and a system, and you can migrate later if you outgrow it. Most projects never do. The migration concern is often theoretical.
Watch for the Lock-In Traps
Before committing, check how hard it would be to leave. The vectors themselves are portable, but proprietary index formats, bespoke query APIs, and tightly coupled features can make migration painful. Favor tools that store data in ways you can export and query through interfaces that resemble what others offer. You may never migrate, but designing for the possibility keeps a vendor's roadmap, pricing changes, or acquisition from becoming your emergency. The cost of portability is usually small; the cost of being stranded is not.
Graduate Deliberately
Move to a dedicated database when a concrete limit forces you, scale, latency, or operational pain, not because a benchmark looked impressive. When you do, evaluate candidates against the criteria above rather than feature counts. The patterns in Inside Five Products Powered by Nearest-Neighbor Lookup show which limits typically trigger the move.
When you run that evaluation, test on your own data, not the vendor's demo dataset. Benchmarks published by tools are run on workloads chosen to flatter them, and your content, query mix, and scale may behave entirely differently. A short proof of concept that loads a slice of your real corpus and replays real queries tells you more than any marketing comparison. Measure recall, latency, and cost on that slice, and let the numbers from your own workload settle the decision.
Frequently Asked Questions
Should I start with pgvector or a dedicated database?
If you already run PostgreSQL and your scale is modest, pgvector is usually the right start: no new infrastructure, easy joins with relational data, and a simple path. Move to a dedicated database when scale, latency, or operations force the issue, which for many projects never happens.
When is a managed service worth the cost?
When your team is small or your time is better spent elsewhere. Managed services remove indexing, scaling, and uptime work in exchange for a subscription and less control. For teams without dedicated infrastructure staff, that trade usually pays off.
Do I need a vector database that supports hybrid search?
If your queries mix exact terms with conceptual questions, yes, weight it heavily, because hybrid search consistently outperforms pure vector search on mixed traffic. If users only ever ask paraphrase-style questions, pure semantic search may suffice and hybrid support matters less.
How much does the choice of database affect result quality?
Less than you might expect. Result quality is driven mostly by the embedding model, chunking, and tuning, not the database. The database affects scale, latency, operational ease, and features like filtering, but it rarely makes irrelevant results relevant.
Is migrating between vector databases hard?
It is real work but rarely catastrophic, since the vectors themselves are portable and the metadata is structured data. The friction is in re-indexing, re-wiring the query path, and re-validating recall. Plan it as a project, but do not let migration fear drive you to over-build early.
How do I evaluate a brand-new tool I have never heard of?
Score it against the durable criteria: scale and latency, operational burden, filtering and hybrid support, and index flexibility. Ignore the marketing leaderboard. A tool that fits your workload on these axes will serve you better than whichever one tops a benchmark this quarter.
Key Takeaways
- The landscape splits into database extensions, dedicated databases, and embedded libraries, each fitting a different scale and burden.
- Choose by durable criteria, scale and latency, operational burden, filtering and hybrid support, index flexibility, not feature tables.
- The core trade-offs are simplicity versus scale and money versus time; neither answer is universal.
- Result quality depends mostly on the embedding model and tuning, not the database itself.
- Start where you already are, often pgvector, and graduate to a dedicated system only when a concrete limit forces it.
- Evaluate any new entrant against the same criteria rather than chasing the current benchmark leader.