> [!FOUNDER]
> "Teams pick a vector database the way they pick a logo: by what they saw on a launch page. Then the bill, the filter bug, or the migration lands, and the choice turns out to have been a deployment model, not a product. Qdrant, Pinecone, and pgvector are not three flavours of the same thing. One is a dedicated engine you operate, one is a managed service you rent by the query, and one is an extension inside the database you already back up. Pick the deployment model first, because that is the part you cannot refactor away in a weekend."
> — Enow A. Jovial, Founder & Chief Executive Officer
Three products, three deployment models
A vector database stores embeddings — numerical representations of text, images, or other content — and returns the nearest neighbours of a query vector. That shared job hides the real differences. Qdrant is an open-source vector search engine, written in Rust, that you deploy yourself or run as a managed cloud, with collections of points made of vectors plus JSON payload metadata. Pinecone is a fully managed, closed-source service: for new indexes its architecture is serverless, built on object storage with compute decoupled from storage, and the legacy pod model — provisioned pods billed per hour whether busy or idle — is closed to new customers. pgvector is not a database at all: it is a PostgreSQL extension that adds a vector column type and similarity search to the Postgres you already run, back up, and replicate.
That distinction decides almost everything else: who pages at 3 a.m., how filtering behaves, how multi-tenancy is isolated, and whether the bill is a fixed rent, a metered charge, or a line inside an existing database budget.
> [!KEY TAKEAWAY]
> If you already run Postgres and your vector workload is modest, pgvector is the default until proven otherwise, because it adds zero new systems. If you need dedicated vector performance with full control, Qdrant is the engine. If you want no infrastructure at all and your traffic is spiky, Pinecone serverless is the rental. Choose by operating model, then by feature.
The decision table
| Attribute | Qdrant | Pinecone serverless | pgvector |
| :--- | :--- | :--- | :--- |
| What it is | Dedicated open-source vector engine (Rust), self-hosted or managed cloud | Fully managed closed-source service, serverless for new indexes | PostgreSQL extension, vector search inside Postgres |
| Index | HNSW graph, with filterable HNSW extensions for payload-aware edges | Managed ANN over object storage; no graph parameters to tune | HNSW or IVFFlat, chosen per index |
| Filtering | Payload indexes per field; query planner picks strategy by filter cardinality | Metadata filters with roaring bitmap indexes; serverless chooses pre- or mid-filtering by selectivity | SQL WHERE clauses joined to vector search; planner needs ORDER BY distance plus LIMIT to consider the index |
| Multi-tenancy | Collections, payload tenant fields, and tenant-aware payload indexes | Namespaces: one namespace per query, hard isolation by partition | Row-level tenant columns, Postgres RLS, schemas, or separate databases |
| Cost shape | Node and storage cost you size, plus your operations time | Storage plus read units and write units; zero queries means minimal cost | Inside your existing Postgres bill; no per-query vector charge |
| Operations burden | You own upgrades, backups, scaling, and monitoring (less on managed cloud) | Vendor owns infrastructure; you own index design and query patterns | You already own Postgres; vector work is one more index type |
| Exit cost | Open source and portable data model; migration is engineering, not re-licensing | Managed API and serverless billing; export and re-index elsewhere is a project | Data already in Postgres; leaving means moving the vector column, not the whole store |
| Regulatory / Operational Authority | Qdrant documentation: Indexing; Filterable HNSW course | Pinecone: Pods vs Serverless migration guide | pgvector README (GitHub): index types, operator classes, limits |
Filtering is where vector databases actually differ
Similarity search without filtering is a demo. Production retrieval almost always adds a business rule: only this tenant, only published documents, only this language, only prices below a threshold. Each system answers that rule differently, and the wrong answer silently returns the wrong neighbours.
Qdrant's answer is explicit payload indexing. Its documentation states the key point plainly: a vector index speeds up vector search, and payload indexes speed up filtering, and the two together are what make filtered search work. Payload indexes are built per field and type — keyword, integer, float, bool, geo, datetime, text, uuid — and they also let the query planner estimate filter cardinality and choose a strategy. The filterable-HNSW extension goes further: because a filter can break HNSW graph connectivity by removing the points a traversal would pass through, Qdrant builds additional edges to keep the graph connected under filtering, constructing subgraphs per payload value and merging them back into the full graph.
The operational catch is ordering. Qdrant's documentation recommends creating payload indexes before ingesting data, because the filter-aware HNSW edges are only built after the payload indexes exist. Add a payload index after HNSW is built and searches run less efficiently until the index is rebuilt — a compute-heavy operation on a large collection. That is a deployment-order rule, not a tuning tip: index design belongs in the ingestion pipeline's first run, not in a post-launch fix.
Pinecone's answer is namespaces plus metadata filters, and the two are not interchangeable. A namespace is a partition inside one index: every upsert and query targets exactly one namespace, and a query never sees vectors outside the one it names, which makes namespaces the hard-isolation primitive for multi-tenancy. Metadata filters are predicates on the JSON metadata attached to each vector, and Pinecone's serverless architecture applies them with roaring bitmap indexes, dynamically choosing pre-filtering or mid-scan filtering based on selectivity. The cost consequence follows from the same distinction: a namespace query is scoped to one partition before search begins, while a metadata filter still operates across the namespace it is applied to, so Pinecone's own guidance recommends namespaces over metadata filtering for multi-tenancy. Tenants that must never mix belong in namespaces; attributes that cut across one tenant's data belong in metadata filters. Confusing the two is a billing bug and, for tenant isolation, a security bug.
pgvector's answer is SQL. A filtered vector query is an ordinary Postgres query: a WHERE clause for tenant, status, or date, an ORDER BY on a distance operator, and a LIMIT. The planner only considers a vector index when the query has an ORDER BY directly on a distance operator, ascending, with a LIMIT — a query that sorts in application code or wraps the distance in an expression will scan instead of using the index. That constraint is also pgvector's strength: filtering, joins, transactions, and row-level security are Postgres features, not a second system's approximations of them, and a retrieval query can join vector results against the orders, documents, or permissions tables that already live in the same database.
The exposed math: storage, quantization, and the break-even
Vector cost is computable before any vendor invoice arrives. Raw vector storage is:
$
\text{Raw Vector Bytes} = \text{Vector Count} \times \text{Dimensions} \times \text{Bytes per Value}
$
For float32 values, bytes per value is 4. Worked example: 10,000,000 vectors at 768 dimensions in float32 occupy 10,000,000 x 768 x 4 = 30,720,000,000 bytes, about 30.7 GB before any index, payload, or replication overhead. The same corpus quantized to int8, at 1 byte per value, occupies 10,000,000 x 768 x 1 = 7,680,000,000 bytes, about 7.7 GB — a 4x reduction that trades recall for storage and memory. Quantization is therefore a cost lever with a quality price, and it must be evaluated on recall against a representative query set, not adopted because the byte count looks better.
The managed-versus-self-hosted break-even is a second formula:
$
\text{Managed Monthly Cost} = \text{Storage Cost} + (\text{Read Units} \times \text{Read Price}) + (\text{Write Units} \times \text{Write Price})
$
$
\text{Self-Hosted Monthly Cost} = \text{Node Cost} + \text{Storage Cost} + \text{Operations Time} \times \text{Engineer Rate}
$
A spiky workload with long idle nights favours the metered side, because zero queries means minimal cost on Pinecone serverless and full pod cost on any provisioned model. A flat, high-volume workload favours the fixed side, because the metered bill grows with every query while the node cost does not. Pinecone's own migration guidance makes the same point from the vendor side: pods charge per hour regardless of utilisation, serverless charges per read unit consumed, and sustained high-throughput workloads are the case for dedicated read nodes at a flat fee. The break-even is found by plugging your measured queries per month into the first formula and your node plus operations cost into the second — not by comparing marketing pages.
pgvector's sizing math comes from its documented limits: the vector type can be indexed up to 2,000 dimensions and stored up to 16,000 dimensions, HNSW can be created on an empty table because it has no training step, and IVFFlat must be built after the table holds representative data, with lists starting at rows divided by 1,000 up to 1 million rows and the square root of rows above that. Its query knobs are equally explicit: hnsw.ef_search defaults to 40 and ivfflat.probes defaults to 1, so a pgvector deployment that never tunes either knob is running both index types at their defaults and should not be surprised by either recall or latency.
Who should not pick each one
> [!WARNING]
> The most dangerous vector-database bug is silent, not slow: a filter that returns plausible but wrong neighbours. Post-filtering that discards most of the top-K results, a metadata filter across tenants instead of a namespace partition, or a pgvector query the planner never indexed all produce answers that look ranked and confident. Validate retrieval with a labelled query set that includes filtered cases before any of these systems reaches production.
Migration and operations checklist
> [!TIP]
> Start pgvector migrations from the database you already operate, and start Qdrant or Pinecone migrations from a read-only replica of the corpus, never from the live index. A migration that can be rolled back by pointing the application at the old index is a migration; one that overwrites the only copy is a gamble.
Related reading on this site: the self-hosting LLMs and vector databases cost guide for the bare-metal numbers behind the self-hosted side of the break-even, the RAG evaluation metrics guide for measuring recall on filtered queries instead of trusting it, and the CDN caching architecture guide for the other half of fast retrieval — serving results without serving stale ones. To model the monthly break-even with your own query volume, run the numbers through the ROI calculator before signing a managed plan or provisioning a node.