Vector DB & embedding API pricing

A retrieval pipeline has two recurring costs that are billed by different vendors: the embedding model that turns your text into vectors, and the vector database that stores and searches them. They're usually compared separately, and they should be.

Embeddings: a per-token cost, like an LLM

Embedding APIs are priced per million input tokens, the same unit as an LLM's input side, and the rates are low — a fraction of a cent per thousand documents for most models. The cost only becomes noticeable at two moments: the initial bulk embedding of a large corpus, and any time you change embedding models and have to re-embed everything. Model choice here is mostly about retrieval quality and vector dimensions (which affect storage cost downstream), not about the per-token price, because the differences are pennies.

Vector databases: three pricing shapes

Serverless / usage-based. You pay for storage (per GB-month or per million vectors) plus reads and writes (per million operations). This is the cheapest option for spiky or small workloads and the one to model carefully if your query volume is high — reads add up.

Provisioned pods or instances. You pay an hourly rate for a fixed amount of capacity whether you use it or not. Predictable, and cheaper than serverless once your workload is steady and large, but you're paying for headroom.

Managed-Postgres with pgvector. If you already run Postgres, adding vector search can be nearly free at small scale — you're paying for the database you already have. It stops being the cheapest option once the index no longer fits comfortably in memory.

What actually drives the bill

Storage scales with the number of vectors times their dimension count times the bytes per dimension — so a model that outputs 3,072-dimension vectors costs roughly twice as much to store as one outputting 1,536, for the same document count. Query cost scales with how often you search and how many results you ask for. A read-heavy app with a large index is priced very differently from a write-once, search-rarely archive.

Comparing providers

Estimate your vector count and dimension, and your monthly read and write volume. Price that against a serverless option and a provisioned one from two providers, and check whether pgvector on your existing database covers it. The comparisons here run those numbers for the common matchups; the full rate dataset is on the [data page](/data).