Vector database and embedding costs explained

Rohit Athaide · 2026年11月4日 公開

Short answer: an embedding turns text into a list of numbers so that similar text sits close together. There are two costs: making embeddings, which is a small per-token charge, and keeping them searchable, which is a storage and memory cost. For a small collection, adding vectors to a database you already run is often the cheapest start.

Key points

• Embedding models bill per token, at a much lower rate than chat models.
• Changing the embedding model means re-embedding everything.
• A vector of 1,536 numbers needs about 6 KB.
• Search indexes are often held in memory, which sets the size you pay for.
• Start inside an existing database if the collection is small.

What does it cost to make embeddings?

Embedding models bill per token, like other models, at a much lower rate than chat models. You pay once per document chunk, and again if you re-embed after a change or switch models. See AI token pricing explained.

A rough sizing: tokens in your documents divided into chunks, then each chunk is one embedding. Re-embedding the whole library when you change the model is a cost to plan for.

How much storage do vectors need?

Size depends on vector length (dimensions) and count. A vector of 1,536 numbers stored as 32-bit floats takes 1,536 x 4 bytes = 6,144 bytes, about 6 KB. A million vectors take about 6 GB before indexes. Indexes for fast search add to that, often held in memory.

What does a worked example look like?

Made-up round numbers to show the method, not real prices. A library has 50,000 documents of 2,000 tokens each, cut into chunks of 500 tokens.

1. Chunks: 50,000 x 2,000 / 500 = 200,000 vectors.
2. Tokens to embed: 50,000 x 2,000 = 100 million tokens.
3. Embedding charge at 0.10 per million (made up): 100 x 0.10 = 10.00, once.
4. Vector storage: 200,000 x 6 KB = 1.2 GB.
5. Index in memory, with overhead of 1.5 times: 1.8 GB, so a machine with 4 GB of memory is enough.

The embedding bill is tiny compared with the store. The decision is about hosting, and at 1.2 GB the existing database wins. Change the library to 20 million vectors and the index no longer fits a small machine: 20,000,000 x 6 KB = 120 GB, and a dedicated service starts to make sense.

Which three ways are there to host them?

For a small collection, adding vectors to an existing database is often the cheapest start. Managed services earn their price at large scale and when search speed matters.

What makes the bill grow?

• Number of vectors and their dimensions.
• Memory needed to keep the index fast.
• Queries per second at peak, which sets the capacity you reserve.
• Replicas for availability.
• Metadata stored with each vector.

Which mistakes are common?

• Choosing 3,072 dimensions when 768 would do.
• Re-embedding everything after a minor text change.
• Paying for a managed cluster for 10,000 vectors.
• Not planning for a model change.

Decision checklist

• How many vectors, and how many dimensions?
• Does the index fit in the memory of the database I already have?
• How often do documents change?
• What queries per second at peak?

Next steps

Count chunks, choose dimensions, multiply for storage, then price a capacity that holds the index in memory. Add query embedding tokens per request. The full picture for a chatbot is in RAG chatbot monthly cost.