The best vector database hosting platforms in 2026

The vector database market grew up in eighteen months around a single assumption: that similarity search needs its own system. Then Postgres got a competent extension, every general-purpose database bolted on a vector type, and the assumption stopped being obviously true.

It is still true for some workloads. The problem is that the workloads where it is true are a minority, and the marketing is aimed at everyone. So this is a hosting comparison that starts by asking whether you should be shopping in this category at all.

I build PandaStack, which offers managed Postgres with pgvector, so I have a horse in the pgvector half of this race. I have tried to make the case for the dedicated stores fairly, because at the scale where they win, they really do win.

The question that decides everything

There is one fork in this decision and the rest is detail: do your vectors live next to relational data you need to filter and join on, or are they a standalone index?

• Next to relational data. Your embeddings describe rows you already have — documents, products, support tickets — and your queries combine similarity with ordinary predicates: this customer, published after that date, in these categories, not archived. Keeping them in the same database means one query, one transaction, one backup, and no synchronisation problem. This is most applications.
• Standalone index. Hundreds of millions of vectors, high write throughput on the vectors themselves, latency budgets in single-digit milliseconds, or specialist retrieval features like multi-vector reranking and hybrid sparse-dense scoring. Here the dedicated systems are dedicated for good reasons.

Option 1: Postgres with pgvector

pgvector adds a vector column type, distance operators, and two index types. For a very large share of RAG applications that is the whole requirement, and every managed Postgres provider now supports it in some form.

• Neon — Postgres with branching and idle suspension. Good for RAG applications where the index is rebuilt per branch or per experiment, and where the database is idle between demos.
• Supabase — pgvector plus the surrounding platform, and good documentation aimed specifically at RAG. The default choice if you want the whole application stack in one place.
• Amazon RDS and Aurora — pgvector is supported on current versions; you get the operational depth and the AWS-shaped bill. Correct in an enterprise setting where the database was never going to be a startup.
• Crunchy Bridge — serious Postgres people, strong extension support, sensible defaults for the memory settings that actually determine index performance.
• PandaStack — Postgres 16 in its own Firecracker microVM with pgvector enabled at provisioning, RAM tiers you choose per database, and idle suspension so an experiment database costs nothing between sessions. The RAM tier matters more than usual for vector work, because index performance is decided largely by whether the index fits in memory.

-- The entire setup, on any Postgres with the extension available.
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id          bigserial PRIMARY KEY,
  tenant_id   bigint NOT NULL,
  published_at timestamptz NOT NULL DEFAULT now(),
  title       text NOT NULL,
  body        text NOT NULL,
  embedding   vector(1536)
);

-- Build the index for the distance operator you will actually query with.
-- Cosine here; use vector_l2_ops for <-> and vector_ip_ops for <#>.
CREATE INDEX ON documents
  USING hnsw (embedding vector_cosine_ops);

-- And this is the query a separate vector store makes awkward:
-- similarity AND ordinary predicates, in one place, transactionally consistent.
SELECT id, title, embedding <=> $1 AS distance
FROM documents
WHERE tenant_id = $2
  AND published_at > now() - interval '90 days'
ORDER BY embedding <=> $1
LIMIT 10;

Option 2: a dedicated vector database

• Pinecone — fully managed, no index tuning, serverless pricing. You give up control over the index internals and buy back the time you would have spent tuning them. The most straightforward option if you want the problem to go away and are prepared to pay per read and write.
• Qdrant — open source with a managed cloud, strong filtering support, and quantization options that meaningfully change the memory arithmetic at scale. A good balance of control and convenience, and self-hostable if the cloud pricing stops working.
• Weaviate — open source with managed hosting, built-in hybrid search combining keyword and vector scoring, and modules that handle embedding generation. Choose it when hybrid retrieval quality is the priority rather than raw throughput.
• Milvus and Zilliz Cloud — built for very large collections, with a distributed architecture and the operational surface to match. This is where you go at billions of vectors; it is heavy machinery for a million.
• Chroma — developer-friendly and excellent for prototyping, with a hosted offering. Many teams start here and then have to decide whether to grow with it or move.
• OpenSearch or Elasticsearch — if you already run one for keyword search, its vector support may be enough, and hybrid search is native. Not the best pure vector engine; frequently the best answer available inside an existing stack.

Sizing: the number that decides your bill

Vector search is a memory problem before it is anything else. Work out your index size before you shop, because it determines both the platform and the tier.

Rough raw size of the vectors alone, at 4 bytes per dimension:

  1,000,000 vectors x 1536 dims x 4 bytes  =  ~6.1 GB
  1,000,000 vectors x  768 dims x 4 bytes  =  ~3.1 GB
     100,000 vectors x 1536 dims x 4 bytes  =  ~0.6 GB

An HNSW graph adds meaningfully on top of that — budget a healthy
multiple of the raw figure, not a rounding error. Then note the rule
that governs everything: if the index does not fit in RAM, every query
touches disk and your p99 falls off a cliff.

Two consequences worth internalising:
  - Halving your dimensions roughly halves your memory. A 768-dim
    model that is nearly as good as a 1536-dim one is often the single
    highest-leverage cost decision available.
  - Quantization trades a little recall for a large memory saving, and
    at scale that trade is usually correct. Measure recall on your own
    evaluation set rather than trusting a benchmark.

Pick by situation

• Under a few million vectors, with filters on ordinary columns → Postgres with pgvector. One system, one backup, no sync code.
• You already run Postgres → start with pgvector regardless. Moving out later is far easier than moving in.
• Hundreds of millions of vectors, latency-critical → a dedicated store. Milvus or Qdrant, sized properly, with quantization.
• Hybrid keyword plus vector retrieval is the quality bottleneck → Weaviate, or the search engine you already run.
• You want it to be someone else's problem entirely → Pinecone, and budget for read and write volume rather than storage.
• Prototyping, unclear requirements → Chroma locally or pgvector in a branch database. Do not choose infrastructure before you know your recall requirements.
• Per-tenant isolation of embeddings is a requirement → a database per tenant, which is far easier with Postgres than with most dedicated stores.

The short version

Start in Postgres. Not because pgvector wins every benchmark — it does not — but because the second system is the expensive part, and you should only pay for it once you have evidence that the first one cannot cope.

That evidence looks like a specific number: a p99 you cannot meet, a memory footprint that will not fit, or a retrieval quality requirement that needs features Postgres does not have. When you have one of those, the dedicated stores are excellent and you should move. Until then, every hour spent keeping two systems consistent is an hour not spent on the retrieval quality that actually determines whether your application works.