Is PostgreSQL a Vector Database? Pinecone, Weaviate, Chroma

The question shows up in certification quizzes and interview screens in a very specific form: "Which of the following is not a vector database: Pinecone, Weaviate, Chroma, PostgreSQL?" The expected answer is PostgreSQL. And that answer is right, as long as you accept the phrase the question is quietly leaning on. Is PostgreSQL a vector database in traditional mode? No. It is a relational database with B-tree, GIN, GiST and BRIN indexes, built to answer questions about rows, not about the distance between two points in 1,536-dimensional space.

The word "traditional" is doing all the work there, and it is why the quiz answer stops being useful the moment you leave the quiz. Install the pgvector extension and the same PostgreSQL instance gains a native vector type, distance operators, and approximate nearest neighbour indexes. At that point it does the thing that defines the category, on the Postgres the team was already running for everything else.

So the honest answer has two halves. Out of the box, PostgreSQL is not a vector database and Pinecone, Weaviate and Chroma are. With pgvector, PostgreSQL becomes one, with real strengths and real ceilings worth understanding before you spin up a second data store you will have to operate forever.

The short answer: is PostgreSQL a vector database in traditional mode?

Vendor-neutral study material groups vector database options into a tidy list: Pinecone, Weaviate, Chroma, Qdrant, Milvus. PostgreSQL, MySQL and SQL Server land in the relational bucket. The taxonomy is fine as a teaching device, maps to how the products were originally designed, and explains why "which is not a vector database" has a defensible answer at all.

What the taxonomy misses is that vector search stopped being a product category and became a feature. Postgres has pgvector, SQLite has sqlite-vec, MongoDB Atlas has Vector Search, Elasticsearch and OpenSearch have dense vector fields with kNN, and Redis, ClickHouse, DuckDB and Snowflake have all shipped some version of similarity search. The interesting question is no longer which systems can store embeddings, because most of them can. It is which system gives you acceptable recall at your latency budget, at your data volume, without adding an operational surface you cannot staff.

If you are taking the quiz, answer PostgreSQL. If you are designing a system, the quiz framing will lead you to buy something you may not need.

What makes a vector database, mechanically

Strip away the marketing and a vector database does four things a traditional database does not.

It stores dense vectors as a first class type. An embedding is an array of floats, typically 384, 768, 1,024 or 1,536 dimensions depending on the model. You can shove that into a Postgres float8[] column with no extension at all. Storage is not the hard part.

It computes distance with a defined metric. Cosine similarity, squared Euclidean (L2), and inner product are the common three, and cosine is the default for most text embeddings because it ignores magnitude and compares direction. This is where plain PostgreSQL falls over: no operator, no function, nothing that understands what those floats mean.

It indexes for approximate nearest neighbour search. This is the defining capability. Exact k-nearest-neighbour search means scanning every vector and computing every distance, which is linear in your row count and dies somewhere in the low millions. ANN indexes trade a small amount of recall for an enormous amount of speed. The two structures you will meet most often are HNSW, a layered proximity graph with excellent recall at low latency but real memory and build-time costs, and IVF, which clusters vectors into lists and searches only the nearest few. Quantization compresses vectors so more of the index fits in RAM, at further cost to recall.

It filters on metadata alongside the vector search. Real queries are almost never "find similar text." They are "find similar text from documents this user is allowed to see, created in the last ninety days, in the marketing workspace." Filter after the ANN search and you may get back three results when you asked for twenty. Filter before it and you have thrown away the index. How a system handles filtered vector search is the single best technical question to ask any vendor, and it is where implementations differ most.

Everything else, namespaces, hybrid search, reranking, multi-tenancy, is built on those four.

Is PostgreSQL a vector database with pgvector installed?

pgvector is a PostgreSQL extension that adds a vector column type, three distance operators (<-> for L2, <=> for cosine, <#> for negative inner product), and two index types: IVFFlat and HNSW. Recent versions added half-precision, sparse and binary vectors, which matter more than they sound like they should, because halving the storage per dimension roughly halves the memory the index needs.

With the extension installed, a complete vector search is this: create a table with a vector(1536) column, build an HNSW index on it with the cosine operator class, and run ORDER BY embedding <=> $1 LIMIT 10. That is it. The same transaction that inserts your document row inserts its embedding. The same backup covers both. The same role and row level security policy that governs the document governs its vector. For a team already running Postgres, that collapses an entire class of consistency problems a separate store reintroduces.

The ceilings are real too, and worth naming plainly:

• Index build cost. HNSW builds are memory hungry. If the graph does not fit in maintenance_work_mem, the build spills to disk and slows dramatically. Sizing this on a production instance during business hours is a mistake people make once.
• Dimension limits. Indexed vectors are capped at 2,000 dimensions for the standard type, which covers almost every popular embedding model but not all of them. Half-precision vectors raise that ceiling.
• Filtered query planning. The planner chooses between the vector index and a B-tree on your filter column. Get it wrong and you either lose the ANN index or get back fewer rows than you asked for. Newer pgvector releases added iterative index scans to fix the under-fetching case, but tuning is still on you.
• Write amplification. Frequently updated embeddings create index churn and bloat. Autovacuum settings that were fine for your orders table may not survive constant upserts of 6KB vectors.
• It competes with your OLTP workload. A heavy retrieval query eats the same buffer pool as your checkout flow. Read replicas help. Ignoring it does not.

None of these are disqualifying. They are the price of the tradeoff, and for most teams under roughly ten million vectors the tradeoff is clearly worth it.

Pinecone, Weaviate, Chroma and PostgreSQL compared

These four are the ones the quiz names, so here is an honest side by side. "Ops burden" assumes self-hosting where self-hosting is possible.

Three notes the table cannot carry.

Pinecone is the easiest to reason about because there is nothing to run. You get an endpoint, namespaces for tenancy, metadata filtering, and someone else's pager. The cost is lock-in and per-query economics that only make sense once your traffic justifies them. The pgvector vs Pinecone comparison is rarely about recall at small scale, where both are fine. It is about whether you want a second vendor and a second copy of your data.

Weaviate is the most complete open source option of the three for search specifically. Hybrid search with BM25 and vector fusion is built in rather than assembled, and its multi-tenancy model suits SaaS applications where every customer needs an isolated shard. It is a real system to operate, with real memory requirements.

Chroma is deliberately the simplest. It runs in-process for local development, which makes it the fastest way to get a prototype working on a laptop, and scales up to client-server when you need it. Teams routinely start on Chroma, prove retrieval quality, then decide whether to stay or move.

The pattern across all of them: the store is rarely what makes a retrieval system good or bad. Chunking strategy, embedding model choice, metadata design and reranking move quality far more than swapping HNSW implementations does.

When you actually need a dedicated vector store

Be suspicious of anyone who answers this without asking about your numbers.

Choose an extension on the database you already run when: your corpus is in the millions of vectors rather than the hundreds of millions; your queries filter heavily on relational metadata you already store; you need the embedding and the source row to be consistent with each other; a second stateful system is a genuine cost for a team your size; and your latency budget is a few hundred milliseconds rather than single-digit ones.

Choose a dedicated vector database when: you are past roughly fifty to a hundred million vectors and growing; you need to scale retrieval independently of your transactional database; you need quantization to keep index memory affordable; filtered ANN at high QPS is your core product surface; or you want a managed service precisely so nobody has to become an HNSW expert.

Choose both, sometimes. Plenty of mature systems keep canonical documents and permissions in Postgres and mirror embeddings into a dedicated index. It works, and it also means you own a synchronisation pipeline with all the failure modes that implies. Our guide to what is a data pipeline covers how these break, because a stale embedding index is exactly the silent failure that surfaces as "the AI is wrong" three weeks later.

That sync job looks the same regardless of which store you land on:

Embedding refresh pipeline

Source document changes

Webhook or change feed from the system of record

Chunk and clean

Split by structure, keep headings and IDs as metadata

Generate embeddings

Same model and version as the existing index

Upsert to the index

Delete stale chunks for the document first

Verify recall

Query a known answer set, alert on drift

The last step is the one teams skip, and the one that catches a re-embedding job that silently switched models.

The costs nobody puts in the comparison table

Vector database options are usually compared on queries per second and recall at a given latency. Those matter, and they are not where most of the money goes.

Embedding generation. Every chunk you index goes through a model, and changing models means re-indexing the entire corpus. That recurring line item has nothing to do with which store you chose.

Storage that does not compress. A 1,536-dimension float32 vector is about 6KB. A million of them is 6GB before indexes, and an HNSW graph adds substantial overhead. Vectors are dense random floats, so general purpose compression does very little, which is why half-precision and quantized formats exist.

Re-indexing windows. Changing the embedding model, chunk size or distance metric means rebuilding: a maintenance operation on a live database with pgvector, usually a parallel index and a cutover on a managed service. Plan for it, because you will do it at least twice.

The second system tax. A separate vector store needs its own access control, backups, monitoring, upgrade path and its own answer when someone asks where a piece of customer data lives. Our guide to data governance tools covers what small teams realistically need, and the short version is that fewer stores is meaningfully easier to govern. If your index will hold regulated or customer-identifying content, the controls question deserves a look before launch, which is the ground covered in AI compliance software.

Moving the data in the first place. Documents live in Notion, Google Drive, Slack, a CRM and a support desk. Getting them into any index means extraction and sync per source, an integration problem long before it is a vector problem, with tradeoffs laid out in our data integration tools buyer's guide. If most of your knowledge already lives in one workspace tool, the narrower guide to Notion integrations is a more direct route, and if you are weighing whether you need a full extraction layer at all, ETL tools compared is a useful reality check on overbuying.

Where Skopx fits, and where it does not

Here is the part where most articles on this topic pivot to selling you a vector database. This one cannot, because Skopx is not one.

Skopx is an AI workspace that connects nearly 1,000 tools a company already uses, including Gmail, Slack, Stripe, HubSpot, QuickBooks and Google Analytics. You ask a question in chat and get an answer with citations back to the source records. There is a morning brief, an insights engine that surfaces risks and anomalies, and workflows you build by describing them in chat rather than wiring nodes. Bring your own AI key for any major model, with zero markup. Solo is $5 per month and Team is $16 per seat per month, listed on the pricing page.

What that means here: Skopx does retrieval over your connected tools so you can ask "what did we agree with this account about the renewal date" without standing up a vector store, choosing an index type, or owning an embedding refresh job. No HNSW parameters, no distance metric to pick, nothing for you to operate.

Where Skopx does not fit, stated plainly:

• If you are building your own product feature that needs vector search, you need a vector store, and Skopx is not it. Use pgvector, Pinecone, Weaviate, Chroma, Qdrant or whatever fits your latency and scale. Skopx is a workspace for your team, not an embeddings API for your application.
• If you need to control chunking strategy, embedding model per corpus, or reranking behaviour, you want infrastructure you own. That is a legitimate requirement and it points away from any packaged workspace.
• If your corpus sits in a warehouse, a lake or a proprietary system rather than connected SaaS tools, connectors are the wrong shape for the problem.
• Skopx is not a data warehouse, not an ETL tool, not a BI dashboard builder, and not a CRM. If you need a governed semantic layer or a scheduled dashboard, look at those categories instead. For reporting, marketing report examples covers what belongs in each one, and for finance operations, accounts receivable automation software is a better starting point than any retrieval architecture.

Most teams asking "is PostgreSQL a vector database" are two steps removed from their actual goal. They want to ask questions of their own information and get trustworthy answers. Sometimes that requires building retrieval infrastructure. Often it does not.

Answering "is PostgreSQL a vector database" for your own stack

Before choosing anything, get numeric answers to these:

1. How many vectors will you have in twelve months, not today?
2. What is your p95 latency budget for a retrieval call, in milliseconds?
3. What percentage of queries carry a metadata filter, and how selective is it?
4. How often does the underlying content change, and how stale can the index be?
5. Do you already run PostgreSQL in production with someone who understands its maintenance?
6. Who carries the pager for a second stateful system?

If the answers are "a few million," "300ms is fine," "most queries filter by tenant," "hourly is fine," "yes," and "nobody," then pgvector is almost certainly your answer and a dedicated store is premature. If they trend toward hundreds of millions of vectors, tight latency, and a platform team that already runs stateful services, a dedicated vector database earns its place.

If you cannot answer question one, that is the real finding. Build the smallest retrieval system that works on the database you already run, measure it, and migrate when the numbers say so. Migrating from pgvector to a dedicated store later is a well-worn path. Operating two stores from day one to avoid a migration you may never need is not.

Frequently asked questions

Is PostgreSQL a vector database or not?

In traditional mode, no. Stock PostgreSQL has no vector type, no distance operators and no approximate nearest neighbour index, which is why quiz questions asking which is not a vector database expect PostgreSQL alongside Pinecone, Weaviate and Chroma. With pgvector installed it does everything the category requires and is used in production for exactly that. Both statements are true, and the difference is one extension.

Which is not a vector database: Pinecone, Weaviate, Chroma or PostgreSQL?

PostgreSQL, as the question intends it. Pinecone, Weaviate and Chroma were built specifically for storing embeddings and running similarity search. PostgreSQL was built as a relational database and gains vector capability through an extension rather than by design.

Is pgvector good enough for production?

For a very large share of applications, yes. It supports HNSW and IVFFlat indexes, cosine, L2 and inner product distance, and keeps embeddings transactionally consistent with the rows they describe. The practical limits show up around index build memory, dimension caps, filtered query planning, and contention with your transactional workload. Teams under roughly ten million vectors rarely hit a wall they cannot tune around.

What is the difference between pgvector and Pinecone in practice?

pgvector runs inside a database you already operate, costs nothing new in vendors, backups or access control, and can join vectors to relational data in one query. Pinecone is a managed service with no infrastructure to run, built for scale and high throughput, at the cost of a second copy of your data and a second bill. The pgvector vs Pinecone decision is mostly about scale and operational appetite, not retrieval quality at modest volumes.

Do I need a vector database to use AI on my company data?

Not necessarily. If you are building a product feature, yes. If you want your team to ask questions of information sitting in the tools you already use, a workspace that handles retrieval for you removes the question entirely. Skopx takes that second approach: retrieval over connected tools, with no store to run, no index to choose and no embeddings to manage.

Can I use full text search instead of vectors?

Often, and more teams should try it first. PostgreSQL's built-in full text search with tsvector and a GIN index handles keyword queries well, and for exact terms, product codes and names it frequently beats semantic search. The strongest systems combine both, using keyword search for precision and vector search for meaning, then fusing the results. Starting with the search you already have is a cheap way to learn what semantic search actually needs to add.