Vector Database vs Regular Database
Vector databases and regular databases answer different questions. Here is when pgvector is enough and when you need a dedicated one.
A regular database answers "give me rows where this column equals that value." A vector database answers "give me the rows most similar in meaning to this one." They are not competing products, they are built for different questions, and most AI-powered apps end up needing both rather than replacing one with the other.
The core difference in one table
Regular database | Vector database | |
|---|---|---|
Query shape | Exact match, range, join: WHERE price < 50 | Nearest neighbor: "most similar to this" |
What it stores | Structured rows, columns, relationships | High-dimensional numeric vectors (embeddings), usually alongside metadata |
Good at | Precise lookups, transactions, joins, aggregates | Semantic similarity: search, recommendations, RAG retrieval |
Bad at | "Find something like this" with no exact match | Precise filtering on exact values without a supporting index |
Neither column in that table is the better technology in general. A vector database asked "how many orders did customer 4471 place last month" is the wrong tool exactly as thoroughly as a regular database asked "find support tickets similar in meaning to this one, even if they use different words" is the wrong tool.
Why similarity search needs a different structure
A regular database index, a B-tree, is built for values that sort cleanly: numbers, dates, exact strings. Embeddings are vectors of hundreds or thousands of dimensions with no natural sort order, so a B-tree cannot help you find the nearest ones. Vector databases instead use approximate nearest neighbor algorithms, commonly HNSW (Hierarchical Navigable Small World graphs), which trade a small amount of precision for search that stays fast even across millions of vectors. "Approximate" here means it may occasionally miss the single mathematically closest match in exchange for being dramatically faster, a trade nearly every real application is happy to make.
Do you need a separate vector database, or does your existing one already do this
This is the actual decision most teams face, and the honest answer for most app sizes is: you probably do not need a separate system. pgvector, a Postgres extension, adds a vector data type and similarity search directly to a database you likely already run, with HNSW indexing and support for cosine, L2, and inner product distance. For workloads up to roughly a few million vectors, it performs well and avoids the operational cost of running a second database system, keeping backups, replication, and access control, in sync across two stores instead of one.
Already on Postgres, moderate scale, want vector search alongside existing relational data? Add pgvector. This is the right default for most apps.
Tens of millions of vectors or more, or need vector search as the primary, highest-throughput workload? A dedicated vector database like Pinecone, Weaviate, or Qdrant is built specifically for that scale and offers tuning options a general-purpose database extension does not.
Need both precise filtering on structured fields and similarity search in the same query, like "similar products, in stock, under $50"? This is exactly what pgvector inside Postgres is good at, since you get a real SQL WHERE clause and vector similarity in one query, which is more awkward to express across two separate systems.
A concrete example: search that mixes both needs
A support ticket search feature needs both kinds of query at once: "tickets similar in meaning to this one" (vector) and "only from the last 30 days, only from this customer" (regular filter). Run both together in pgvector: a `WHERE` clause on date and customer, combined with an `ORDER BY embedding <=> query_embedding LIMIT 10` for similarity, in a single SQL query. Splitting this across a relational database and a separate vector database means either running two queries and merging results in application code, or duplicating the filterable metadata into the vector store, both real added complexity for a query that a single pgvector-enabled database handles natively. This is the same practical case covered in how to add search to an AI-built app, applied specifically to the database layer underneath it.
What actually goes into a vector
The vectors themselves come from an embedding model, which converts text, images, or other content into a list of numbers positioned so that similar meanings land near each other in that numeric space. See what is an embedding in AI for how that conversion works, since understanding it clarifies why similarity search works the way it does: you are not comparing text, you are comparing positions in a learned geometric space.
This decision sits one layer below the higher-level architecture question in RAG vs fine-tuning: a vector database is usually the retrieval component inside a RAG system, not an alternative to the RAG-versus-fine-tuning decision itself. For the rest of the underlying mechanics this connects to, see how AI models work.
Operational cost, not just query performance
The comparison people skip is what running the system actually costs in attention, not compute. A dedicated vector database is one more service to provision, monitor, back up, and keep credentials for, on top of whatever you already run. For a small team, that overhead is not trivial: it is another dashboard to check when something is slow, another bill, another set of access controls to get right. pgvector inside an existing Postgres instance inherits whatever backup, monitoring, and access control you already have set up, which is a real and often underweighted reason to default to it until you have a specific, measured reason not to.
pgvector in existing Postgres | Dedicated vector database | |
|---|---|---|
New infrastructure | None, it's an extension | A new service to run or a new managed subscription |
Combined filter + similarity queries | Native, one SQL query | Usually requires merging results from two systems |
Best fit | Most apps under a few million vectors | High-scale, vector-search-primary workloads |
FAQ
Can I just use a regular database and skip vectors entirely?
If your search needs are exact or keyword-based, yes, full-text search in a regular database handles that well without any vector infrastructure. Vectors earn their complexity specifically when meaning-based matching, not keyword matching, is the actual requirement.
Is pgvector as fast as a dedicated vector database?
For small to mid-size datasets, close enough that the difference rarely matters in practice. At very large scale or very high query throughput, dedicated vector databases with more specialized tuning options pull ahead.
Do vector databases replace the need for a regular database?
No. Almost every real application still needs structured data, users, orders, permissions, stored and queried the traditional way. Vector search is an addition for a specific kind of query, not a replacement for the rest of the database.
How much storage do embeddings actually take?
A common embedding size is 1,536 dimensions at 4 bytes each, around 6KB per vector before indexing overhead. For 100,000 items that is roughly 600MB, worth planning for but rarely a blocker at typical app scale.
How did this land?
About the author
Staff Engineer, Platform
Carlo works on the platform that turns prompts into running apps. He writes the engineering deep dives and the changelog notes worth reading.
