For most teams building their first retrieval-augmented feature, pgvector — a vector extension on a Postgres database you likely already run — is the pragmatic starting point rather than a dedicated vector database. It avoids adding a new system to operate, keeps vector search alongside your existing relational data so queries can combine both naturally, and is genuinely adequate for embedding volumes many teams never actually exceed.
The point at which it stops being adequate is usually a specific, measurable moment rather than a vague sense of scale — query latency degrading noticeably as the embedding count grows into the millions, or a need for approximate nearest neighbour search algorithms more sophisticated than what a general-purpose database extension implements well. That's the signal to evaluate a dedicated vector database, not a fixed number of embeddings decided in advance.
Dedicated vector databases differ meaningfully in what they optimise for, and the choice among them should follow your actual access pattern rather than a general reputation. Some prioritise raw query speed at high volume, some prioritise ease of filtering vector search results by metadata alongside the similarity search, some prioritise multi-tenancy for applications serving many separate customers' data from one deployment. Evaluate against your own query pattern rather than a benchmark comparing raw throughput in isolation.
Migrating from pgvector to a dedicated vector database later is real work — re-embedding is sometimes needed if the migration coincides with a model change, and the query interface differs enough that application code touching vector search needs updating — but it's a bounded, well-understood migration rather than a full rebuild. That bounded cost is the argument for starting simple: the operational simplicity of not running a separate database earns its keep for as long as pgvector remains adequate, and switching later, once the need is concrete rather than speculative, is a reasonable and common path.
