Self-Hosted or Managed Vector Search — What Actually Wins in Production

The vector database market matured in 2026 and something interesting happened. The performance gap between pgvector and dedicated vector stores closed for most workloads. The real difference now isn't recall or latency — it's operational load. Whether you self-host or use a managed service is less about "which is faster" and more about "what does your team actually want to run."

This is the version of the conversation we have on scoping calls when a client asks which vector store to pick.

Where the market stands

Three real options for most SaaS in 2027.

pgvector inside your existing Postgres

The default choice for most projects. Ships as a Postgres extension, supported by every major managed Postgres provider. HNSW indexing arrived in pgvector 0.5 and made it competitive with dedicated stores on recall and latency for datasets up to 10-50 million vectors.

Dedicated open source (Qdrant, Weaviate, Milvus)

Standalone vector databases you run yourself. More features than pgvector — payload filtering, hybrid search, quantization — and better tooling for scale. Also more operational surface area.

Managed vector services (Pinecone, Turbopuffer, Vespa Cloud)

Vendor-hosted, no infrastructure to manage. Pinecone remains the incumbent. Turbopuffer's cost model is significantly cheaper for large corpora. Vespa Cloud is a serious enterprise option for hybrid search.

The honest use case for each

pgvector fits when the vectors are part of your product data

You're already storing users, documents, or messages in Postgres. Adding vectors alongside means one database, one backup strategy, one query language for joins. If a query needs to combine vector similarity with a WHERE on tenant_id, pgvector handles it in one statement. That composability is underrated.

Limits show up around 20-50 million vectors depending on hardware. Above that, index rebuild times and memory usage start to hurt.

Qdrant / Weaviate fit when the vectors are the workload

If your product is a search engine, a recommendation system, or a RAG platform where vectors are the primary object, a dedicated store earns its keep. Features like payload filtering, sparse-dense hybrid search, and quantization are first-class. Scale profile is 100M+ vectors comfortably.

Cost is your infrastructure plus the ops time to run it. That "plus ops time" is the number founders skip.

Pinecone / Turbopuffer fit when ops is scarce

Small team, no dedicated infra hire, and vector work is central enough that database ops would be a real time sink. Pay the managed premium, keep the team focused. Turbopuffer's price point in particular has narrowed the "managed premium" significantly.

The performance question, decisively

For datasets under 10 million vectors and typical RAG workloads, all three categories are within a factor of two on latency. pgvector with HNSW is typically 15-40ms for a top-10 query. Qdrant is typically 5-20ms. Pinecone is typically 30-80ms including network. All are well below the "user notices" threshold for chat and search UX.

The differences show up in the tails. Under load, dedicated stores hold latency better than pgvector, which shares resources with your app's OLTP queries. If you're serving vectors at 100+ QPS on a database that's also handling transactions, isolation starts to matter.

The cost picture

Rough numbers for a 5-million-vector corpus, 1M queries per month:

• pgvector on managed Postgres — usually $50-300/month on top of what you're already paying for the database. The vectors and index add memory pressure but not much else.
• Self-hosted Qdrant — $150-500/month for the infrastructure, plus your engineering time to run it. If you're already running services, this is small. If you're not, this is real ops overhead.
• Pinecone serverless — $50-400/month depending on usage patterns, no infrastructure to run.
• Turbopuffer — often $10-100/month for the same corpus, because storage sits in S3 and reads are much cheaper.

At 50-100M vectors, the math shifts. Managed prices scale up. Self-hosted infrastructure costs climb. pgvector starts hitting memory ceilings. Every provider's economics get interesting at scale.

Operational load — the honest comparison

What you actually have to do to run each in production.

pgvector

Your Postgres provider handles backups, replication, and upgrades. You handle index tuning, memory sizing, and occasional REINDEX. If pgvector ships a new version with better recall, upgrading is a Postgres extension update. Low ongoing load if you already run Postgres.

Self-hosted Qdrant / Weaviate

You handle everything. Deployment, backups, replication, upgrades, capacity planning, failover. Modern deployments on Kubernetes are manageable but not free. Budget 5-15% of one engineer's time indefinitely for a mid-sized deployment.

Managed services

You handle almost nothing infrastructure-wise. You still handle schema decisions (what to index, how to chunk), monitoring, and cost management, but not the database itself. This is the whole point of the premium.

Common mistakes

Choosing based on benchmarks alone. Public benchmarks are usually clean and single-tenant. Your workload is multi-tenant with filtering, mixed load, and cold cache. Prototype on your data before committing.

Underestimating filter cost. A vector search that also has to filter by tenant_id and status is a different query. Some stores handle this efficiently, others don't. pgvector with a good composite index is usually fine; managed services vary.

Ignoring hybrid search. Pure vector search misses exact matches on keywords. Real production RAG almost always ends up needing a keyword component. Not every store has good hybrid support.

Assuming embeddings are stable. When you upgrade the embedding model, all your vectors need to be regenerated. This is a data migration on the scale of your entire corpus. Plan for it.

Not planning for reranking. Vector search alone is rarely enough for production quality. A reranking pass with a cross-encoder or LLM after retrieval usually improves results significantly. Budget for it in latency and cost.

Trade-offs

Every choice ties you to a specific operational model. pgvector ties you to Postgres — fine if Postgres is your default. Dedicated stores tie you to whatever ops model you use for them. Managed services tie you to the provider's roadmap, pricing, and API.

Portability matters more than founders expect. The embedding format is portable (a list of floats), but the metadata, filtering syntax, and index configuration usually aren't. Moving 50M vectors between systems is a project.

Our post on choosing a vector database covers the initial-decision side of this in more detail.

What we usually recommend

For a new RAG feature on an existing SaaS with Postgres: pgvector. Reuses your database, adds one extension, no new operational surface.

For a product where vector search is the core surface (search engines, recommendation systems, RAG platforms) and the team doesn't want to run infrastructure: managed. Pinecone if you need enterprise features and pricing isn't a concern; Turbopuffer if cost matters and the corpus is large.

For a product where vector search is the core surface and the team already runs infrastructure at scale: Qdrant self-hosted. The features are worth it and the ops burden fits an existing team.

We rarely recommend a dedicated store to a small team that doesn't already run infrastructure. The ops load usually outweighs the feature benefits at that scale.

Common misconceptions

"Postgres can't handle vectors at scale." pgvector with HNSW handles low-tens-of-millions comfortably on modern hardware. Above that, it starts to struggle. Most SaaS never get there.

"Managed services are always more expensive." Not since Turbopuffer's pricing model became public. For cold-heavy workloads, S3-backed managed vector search is often the cheapest option.

"We should self-host to avoid vendor lock-in." Self-hosting introduces its own lock-in — to a specific store's operational model, index format, and version compatibility. Portability doesn't come free from either side.

Frequently asked questions

Final take

The vector database question in 2027 is mostly an operational one. Pick pgvector if you already run Postgres and vectors are one workload among many. Pick a managed service if ops is scarce and vectors are core to the product. Pick self-hosted only if you already run infrastructure well and want the feature depth of dedicated stores. All three deliver good enough recall and latency for most SaaS use cases.

If you're weighing options for a new AI feature and want a review of the architecture, book a call. We've shipped RAG systems on all three and the tradeoffs are stable.