Storing Vector Embeddings: pgvector or a Dedicated Vector Database

The direct answer: if your data is under a few million vectors and you already run PostgreSQL in your application, the pgvector extension is the smartest choice, because it adds vector similarity search to your existing database without a separate server, keeping your data and vectors in one place with one transaction and one backup. But if your data exceeds tens of millions of vectors, or you need very low search latency under heavy concurrency, or you want advanced vector search features out of the box, a dedicated engine like Qdrant or Milvus pulls ahead because it is built for this single purpose and tunes memory and indexing specifically for it.

An embedding is a numeric representation of the meaning of text or an image as a list of numbers, and models turn content that is similar in meaning into vectors that sit close together in space. Vector search means finding the nearest vectors to your query vector, and this is the core of semantic search applications and RAG systems that fetch the passages closest to a user's question before passing them to the model. The choice between pgvector and a dedicated database is not settled by fashion but by three numbers: your data size, the number of concurrent queries, and the required latency. Start with the simplest, and move to the specialist only when the numbers force it.

Why vectors need special storage

A traditional database is excellent at finding an exactly matching value, but vector search is different: you want the nearest, not the match. Computing the distance between the query vector and every stored vector is an expensive operation if it runs over millions of rows one by one, so vector databases use approximate indexes that speed up the search with a small trade-off in accuracy. Instead of scanning every vector, the approximate index jumps straight to the region near the query, returning excellent results in fractions of a second rather than seconds.

This is the fundamental difference: dedicated vector storage provides an index structure designed for the question of what is nearest, not what matches. pgvector brings this capability inside PostgreSQL itself, while dedicated databases build their entire structure around it, and that is where the difference shows at large scale.

Approximate indexes and the accuracy-speed trade-off

The two most common approximate index types are IVFFlat and HNSW, each with its trade-off. The IVFFlat index divides the space into regions and searches the ones nearest the query, so it is lighter on memory and faster to build, but its accuracy depends on tuning how many regions it probes. The HNSW index builds a multi-layer graph that the search navigates intelligently, giving higher accuracy and excellent search speed, but it consumes more memory and takes longer to build. The practical rule: HNSW when accuracy and search speed are the priority and you have enough memory, IVFFlat when you want to save memory and accept manual tuning for accuracy.

When pgvector is genuinely enough

Most real applications fall squarely within pgvector's range. A company knowledge base, a document archive, semantic search in a store or content site, all typically sit under a few million vectors, a size pgvector serves comfortably on a mid-range cloud server. The biggest advantage is that you keep your data and its vectors in one database, so you tie vector search to an ordinary SQL query, for example "the nearest documents to this question, provided they are from the finance department and published this year." This hybrid search between vector similarity and relational filtering is hard for a separate vector database and very easy for pgvector.

Add to that the operational simplicity: one backup, one transaction that guarantees the consistency of data and its vectors together, with no synchronization between two systems that may drift apart. If you are building a self-hosted RAG system of moderate size, pgvector on PostgreSQL on a single cloud server is enough and spares you complexity you do not need yet.

When to move to a dedicated database

The signs that you need to move are clear in numbers. When you exceed tens of millions of vectors, or concurrent queries rise to hundreds per second and you need a stable low latency, or you want features like advanced filtering inside vector search and horizontal sharding across several servers, that is where Qdrant and Milvus pull ahead. These databases are designed for vector storage alone, so they tune memory usage, data distribution, and indexing for this load specifically, and they absorb growth that a general database cannot.

But beware: moving too early is a common mistake. Running a separate vector database adds a component you manage, monitor, and synchronize with your original data, and that is complexity with no point if pgvector serves you. The rule: do not move preemptively to a scale you may never reach, but when you measure a real bottleneck on pgvector that index tuning or added resources cannot solve.

A practical point often overlooked: vector search rarely works alone. You usually mix it with filtering on metadata (date, department, access permission) and sometimes with traditional keyword search, in what is called hybrid search. Here the practical difference stands out: with pgvector you write all of that in a single SQL query that combines vector similarity, filtering, and ordering at once, while a separate database forces you to fetch the vector results then filter them in your application or synchronize the metadata in two places. For most real applications that need a condition alongside similarity, this integration alone is reason enough to stay on pgvector until you genuinely grow.

Server size and resources

Vector search consumes memory primarily, because high-performance approximate indexes like HNSW are loaded into RAM to deliver their speed. So RAM is the first constraint. Estimate the size of your vectors and index and provide RAM that holds them with headroom. For mid-size projects on pgvector, a plan with 4 vCPU and 8GB of RAM is a reasonable starting point, and you upgrade RAM instantly as the vector collection grows. Add enough disk to store the vectors themselves, since they are heavier than plain text.

The server activates automatically within seconds of payment, and you add RAM and SSD later with no rebuild, so you start at a size suited to today's data and scale as it grows. Check the pricing page to match RAM and disk to the size of your vectors, or start from a ready template through AI hosting.

Vector dimensions and the generating model affect cost

The storage decision is inseparable from the embedding model itself. Each model produces a vector with a fixed number of dimensions, so a model producing 384 dimensions stores far lighter vectors than one producing 1536. More dimensions may capture finer meaning, but they multiply storage size, memory use, and distance-computation time. The practical rule: choose the smallest generating model that gives sufficient retrieval quality for your application, since extra dimensions are an ongoing cost with no return if they do not actually improve your results.

Here the advantage of keeping the model and vectors inside your server shows: you generate vectors locally through an open model, so you pay nothing per call and send no text to an external party, and the vectors and their data stay in the same database. This combines data privacy with a fixed cost, and it makes trying different generating models cheap, so you measure which gives the best retrieval for your data without a bill that climbs with every experiment.

Measuring quality before choosing an index

The approximate index trades accuracy for speed, but how much accuracy do you actually lose? Do not guess, measure. Prepare a set of test questions whose correct answers you know, run the search with the approximate index, and compare its results to the exact full search, so you learn the correct-retrieval rate (recall). If the result is excellent, which it usually is with good tuning, you can trust the index speed. If it drops a lot, tune the index parameters or move from IVFFlat to HNSW. This measurement is minutes of work that spares you decisions built on guesses and makes index choice scientific rather than impressionistic.

The decision in steps

• Estimate your expected vector count over a year, since it is the first number that guides the decision.
• If it is under a few million and you have PostgreSQL, start with pgvector and use HNSW for accuracy or IVFFlat to save memory.
• Take advantage of hybrid search by tying vector similarity to SQL filtering, which is pgvector's biggest strength.
• Measure search latency and concurrency on your real data before any decision to move.
• Move to Qdrant or Milvus only when the numbers force it: massive size or high concurrency that chokes pgvector.

The bottom line is that the simpler option usually wins: pgvector serves most applications with one database and less complexity, and a dedicated engine is an investment you reserve for genuinely large scale. Measure first, commit after.