pgvector vs a managed vector database: the real cost comparison

Quick answer

pgvector runs inside Postgres you already pay for, so the marginal cost is the extra memory and CPU the index needs. An HNSW index over 5 million 768-dimension vectors needs roughly 18 to 22 GB of RAM to stay resident, which typically means moving from a db.r6g.xlarge at about $0.48 per hour to a db.r6g.2xlarge at about $0.96 per hour, an increase of about $350 a month. A managed vector service such as OpenSearch Serverless bills per OCU-hour at about $0.24 with a 4 OCU minimum, roughly $700 a month before any real load. Below about 10 million vectors, pgvector is usually cheaper; above that, or when you need independent scaling, managed wins.

Every RAG project reaches the same fork: put the vectors in the Postgres database you already run, or stand up a purpose-built vector store. The cost arguments on both sides are usually made badly. pgvector is not free, because the index has to live in memory to be fast, and memory is the expensive part of a database instance. Managed services are not extortionate, because they include operations you would otherwise pay engineers to do. Here is the arithmetic.

What a vector index actually needs

Vectors	Dimensions	Raw float32 size	HNSW index RAM (approx)
1,000,000	768	about 2.9 GB	about 4 GB
5,000,000	768	about 14.3 GB	about 18 to 22 GB
10,000,000	1536	about 57 GB	about 70 to 80 GB
50,000,000	768	about 143 GB	about 180 to 200 GB

Raw size is dimensions times 4 bytes times row count. HNSW graph links add roughly 25 to 40 percent on top. If that total does not fit in RAM alongside your normal working set, queries hit disk and latency goes from single-digit milliseconds to hundreds. So the real question for pgvector is: what instance size does that force?

pgvector cost on RDS

Instance	vCPU / RAM	Per hour (approx)	Per month
db.r6g.large	2 / 16 GB	about $0.24	about $175
db.r6g.xlarge	4 / 32 GB	about $0.48	about $350
db.r6g.2xlarge	8 / 64 GB	about $0.96	about $701
db.r6g.4xlarge	16 / 128 GB	about $1.92	about $1,402

Single-AZ, US region, PostgreSQL engine, before storage. Add gp3 storage at $0.115 per GB-month on RDS and double the compute if you run Multi-AZ, which most production setups do, as explained in RDS Multi-AZ cost. So 5 million vectors at 768 dimensions realistically means a db.r6g.2xlarge, and with Multi-AZ that is about $1,402 a month of database compute, of which perhaps $700 is attributable to the vectors.

Managed vector service cost

OpenSearch Serverless bills about $0.24 per OCU-hour with a minimum of 2 indexing and 2 search OCUs for a production collection, so the floor is roughly 4 OCUs times $0.24 times 730 hours, about $700 a month, before storage at $0.024 per GB-month. Vertex AI Vector Search bills the serving nodes you deploy, so cost scales with the machine type and replica count you choose. Third-party managed vector platforms commonly land between $70 a month for a small serverless index and several thousand for a dedicated multi-million vector deployment with replicas. Broader comparison lives in vector database cost.

Side by side at three scales

Scale	pgvector on RDS	Managed service	Typical winner
500K vectors	no instance change, about $0	about $700 floor	pgvector, decisively
5M vectors	about $350 to $700 extra	about $700 to $1,200	pgvector, modestly
50M vectors	about $2,800 to $5,600	about $2,000 to $4,000	Managed, usually
Spiky query load	must size for peak	scales with usage	Managed

The hidden costs on each side

pgvector's hidden cost is contention. The vector index competes for the same buffer cache as your transactional workload, so a heavy similarity query load can degrade ordinary application queries, and the fix is a bigger instance for both. Index builds are also CPU-heavy and can take hours on tens of millions of rows. Managed services hide cost in ingestion charges, replica minimums, and the data transfer to get embeddings in and results out, which is why the data transfer line deserves a look.

Read and write patterns matter too

A vector store is not only storage, it is query load. pgvector query cost is absorbed into the database instance you already sized, so 500 searches per second either fits in your headroom or forces a larger instance, with nothing in between. Managed services usually meter query units, so cost rises smoothly with traffic, which is better for unpredictable workloads and worse for steady high volume where a fixed instance is cheaper per query. Ingestion is the mirror image: bulk-loading 10 million embeddings into pgvector is a one-off index build costing only the instance hours it occupies, perhaps $10 to $40, while some managed platforms charge per ingested vector or per write unit, which makes large re-embedding runs after a model change surprisingly expensive.

Cheap wins that change the answer

Dimensionality reduction is the biggest. Cutting from 1536 to 768 dimensions halves index memory and therefore roughly halves the instance you need, often with minimal recall loss. Quantizing vectors to int8 cuts another 4x. Between them, a 50 million vector index that needed 200 GB of RAM can fit in 25 to 50 GB, which moves you back two instance sizes and saves over $1,000 a month. Do that arithmetic before choosing a platform, then model the database and any managed collection in Terraform and price it against the resource catalog so the index sizing shows up as a number in review.

FAQ

Is pgvector cheaper than a managed vector database?

Usually below about 10 million vectors, yes. pgvector adds no new service, only the memory and CPU the index needs, so at 500,000 vectors it can be effectively free on an instance you already run. Managed services such as OpenSearch Serverless have a floor around $700 a month at about $0.24 per OCU-hour with a 4 OCU minimum. Above tens of millions of vectors, managed platforms often win on both cost and operations.

How much RAM does a pgvector HNSW index need?

Roughly the raw vector size plus 25 to 40 percent for graph links. Raw size is dimensions times 4 bytes times row count, so 5 million 768-dimension vectors are about 14.3 GB raw and need roughly 18 to 22 GB resident. If the index does not fit in RAM alongside your working set, queries fall to disk and latency jumps from single-digit milliseconds to hundreds.

What instance size do I need for pgvector?

Size it so the index plus your normal working set fits in memory. Five million 768-dimension vectors typically push you to a db.r6g.2xlarge with 64 GB at about $0.96 per hour, roughly $701 a month single-AZ and about $1,402 with Multi-AZ. One million vectors often fit on a db.r6g.xlarge with 32 GB at about $0.48 per hour, around $350 a month.

How can I reduce vector database cost?

Reduce dimensions and quantize. Moving from 1536 to 768 dimensions halves index memory with often minimal recall loss, and int8 quantization cuts another 4x. Together they can take a 200 GB index down to 25 to 50 GB, which moves you two instance sizes down and saves over $1,000 a month. Also prune stale vectors and avoid storing full document text alongside embeddings.

What are the hidden costs of pgvector?

Contention is the main one: the vector index competes for the same buffer cache as transactional queries, so heavy similarity search can degrade normal application performance and force a larger instance for both workloads. Index builds are CPU-intensive and can run for hours on tens of millions of rows, and Multi-AZ doubles the compute charge for the whole database, not just the vector portion.

How does C3X help with vector database cost?

C3X prices the RDS instance class, storage, and Multi-AZ setting declared in your Terraform against a live catalog, so resizing a database to hold a vector index shows its monthly cost in the pull request. The same applies to managed search collections and their capacity units, making the pgvector versus managed comparison a concrete number before either option is deployed.

What to do next

Size your vector index before it sizes your bill. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.