Vector database storage costs: when your vectors get smaller, does your bill?

Compression is having a moment in vector search. Over the past few months, new ways to make vectors smaller have been shipped and benchmarked across the industry. For anyone running AI search at scale, that's good news.

It also raises a question that rarely makes the release notes: when your vectors get smaller, does your bill?

This piece is for the people who have to answer that question: the platform and data leads who run the infrastructure, and the finance and technology executives who own the budget.

Where the bytes come from

An embedding is a list of numbers. Common text embedding models output anywhere from a few hundred to a few thousand dimensions, and the default way to store each dimension is a 32-bit float: four bytes.

The arithmetic is simple. A 1,536-dimension vector stored as float32 takes 6,144 bytes. One hundred million of them take about 614 GB, before anything else is added. (Illustrative arithmetic. Your dimensions and counts will differ.)

That "anything else" matters:

• Index structures. Approximate nearest-neighbour indexes add links or lists on top of the raw vectors.
• Copies. Primary, replicas, snapshots, staging environments, and the re-embedding run you did when you changed models. Each one multiplies the footprint.
• Metadata and source text. The chunks themselves, IDs, filters and access tags.
• Hot tiers. If an engine needs vectors in RAM to search them quickly, the most expensive tier of hardware sets the price.

So the vector payload is rarely the whole bill. But it's the part that grows with every document you add and every copy you keep, and that's why compression matters.

What "compression" can mean

Not all compression is the same. It's worth separating three things a provider might mean.

1. Compressed at rest, expanded to search. Vectors are stored small, then rehydrated to full precision when they're searched. That saves on storage, but the query path pays some of the saving back in RAM and compute.
2. Compressed for search. The engine searches compact codes directly, often re-checking a shortlist against higher-precision data. The saving can be larger, but search quality depends on the method and on your data.
3. Compressed from the first write. Compression is the default storage format, not a setting applied later to an existing index. Every copy downstream inherits the smaller size.

None of these is automatically right. The trade-off is usually between search quality on your data, your latency budget and how much you save. The reliable way to know where you land is to test on your own corpus.

The billing question

Here's the part that's easy to miss. Whether compression lowers your costs depends on how you run the system and how you're billed.

• If you run the infrastructure yourself, smaller vectors can mean fewer or smaller machines, cheaper storage tiers and faster backups.
• If you buy a managed service, it depends on the pricing unit. Some services bill on what's actually stored. Some bill on the dimensions or size of the vectors you send in. Some bill on compute or read units that compression may or may not move. Read the pricing page for the unit, not the headline.

Neither model is wrong in itself. But if the saving happens inside a provider's infrastructure while the price is set on the original size, the saving doesn't reach your invoice.

Three questions to ask any provider, us included

1. Am I billed on the compressed size or the original size? Ask for the pricing unit in writing. Then ask what happens to your price when the compression improves.

2. What does compression do to search quality on my data, and can I test it myself? Ask for a way to run your own queries against your own documents, with and without compression, and compare what comes back. A benchmark on someone else's dataset is a starting point, not an answer.

3. Is it on from the first write, or something I set up later? Compression applied after the fact often means a rebuild, a migration window and a period of running two copies of everything.

A fourth question for finance: how does the cost scale with copies? If you keep three copies of every vector, a per-vector saving is worth three times as much, as long as every copy is compressed.

Why this matters more as AI search scales

AI search budgets are increasingly visible to finance, not only to engineering. As assistants, copilots and agents move from pilots into daily use, both the number of documents indexed and the number of queries grow. Agents in particular can send many queries in quick succession. The cost of every stored vector compounds.

That makes storage format an architecture decision rather than an optimisation for later. It's far easier to choose a compact format at the start than to retrofit one across a large estate.

Common questions

Does compression always reduce search quality? Any compact format represents vectors with less information, so there's always a trade-off to measure. How much it matters depends on the method, whether the engine re-checks a shortlist at higher precision, and your data. Test it on your own queries.

Is the vector payload the biggest part of the bill? Not always. Compute, index overhead and copies can matter as much. But the vector payload is the part that grows with every document and every copy, so it's the part worth getting right early.

Where CEREBRAL fits

CEREBRAL is the vector + graph database for AI search. It was built from the codec up, so vectors are compressed from the first write, and it's built so the compression savings go to you.

CEREBRAL is self-hosted today, as a Docker image or as the crbrl-pg extension inside your existing Postgres, so it runs on infrastructure you control. Managed cloud is on the roadmap.

We'd rather you test that than take our word for it. If you're sizing an AI search estate, tell us your vector count, dimensions and how many copies you keep, and we'll model it with you.