Layer 4 · self-hosting reality check
What it actually takes to self-host pgvector
The docs say Whatever Postgres already uses. In practice you want 8 GB — the HNSW index wants to be resident. Here is the honest version — real requirements, real monthly cost, what you will be maintaining, and the one thing that catches people out.
Usually reached from Pinecone alternatives, where pgvector is one of the picks.
Wondering whether you need to at all? Is Pinecone free? — what the free tier actually allows, and where the wall is.
| RAM — documented minimum | Whatever Postgres already uses |
|---|---|
| RAM — what it really needs | 8 GB — the HNSW index wants to be resident |
| CPU | 4 vCPU |
| Disk | Index is roughly 1.5× the raw vector size |
| Monthly cost | $0 additional if you already run Postgres. That is the entire argument. |
| Setup time | 20 minutes — `CREATE EXTENSION vector;` |
| How you install it | a Postgres extension. No new service, no new backup story, no new thing to monitor. |
| Ongoing maintenance | None beyond the Postgres you already maintain. |
| Where it stops scaling | Millions of vectors comfortably. The killer feature is joining embeddings to relational data in one query, which no dedicated vector database can do. |
The thing that catches people out
Building an HNSW index on a large table locks writes and can take hours, and the default `maintenance_work_mem` makes it far slower than necessary. Raise it substantially for the build (2 GB+), use CONCURRENTLY where you can, and do it in a maintenance window. People start an index build on a live table at 2pm and regret it.
When not to self-host pgvector
You are past roughly 10 million vectors with heavy filtering. Dedicated engines pull ahead there, and that is the honest crossover point.
Every guide here carries this section. A site that only ever tells you to self-host is selling something — the useful answer is sometimes no.
Other Layer 4 self-hosting guides
- Self-hosting Ollama8 GB VRAM for a 7B model at usable speed; 24 GB for 30B-class
- Self-hosting vLLM24 GB VRAM minimum for useful production serving
- Self-hosting QdrantVectors × dimensions × 4 bytes, in RAM, plus overhead — 1M × 768d is roughly 3 GB
- Self-hosting LlamaIndex4 GB for the app; your vector store is the real cost
- Self-hosting faster-whisper5 GB VRAM for large-v3 in float16; 2 GB with int8
- Self-hosting Langfuse4 GB
Common questions
- How much RAM does pgvector actually need?
- 8 GB — the HNSW index wants to be resident in practice. The documented minimum is Whatever Postgres already uses, which is the figure at which the process starts rather than the figure at which it works under real use. 4 vCPU alongside it.
- What does self-hosting pgvector cost per month?
- $0 additional if you already run Postgres. That is the entire argument. This is commodity VPS pricing and excludes your time, which is the larger cost for most people — budget for none beyond the Postgres you already maintain.
- How long does it take to set up pgvector?
- 20 minutes — `CREATE EXTENSION vector;`, via a Postgres extension. No new service, no new backup story, no new thing to monitor..
- When should I NOT self-host pgvector?
- You are past roughly 10 million vectors with heavy filtering. Dedicated engines pull ahead there, and that is the honest crossover point.
- What is the most common mistake when self-hosting pgvector?
- Building an HNSW index on a large table locks writes and can take hours, and the default `maintenance_work_mem` makes it far slower than necessary. Raise it substantially for the build (2 GB+), use CONCURRENTLY where you can, and do it in a maintenance window. People start an index build on a live table at 2pm and regret it.