Vectorize bills on dimensions, not on vectors and not on queries. The definition of one of the two billed units is counter-intuitive enough that most estimates of a Vectorize bill are wrong by an order of magnitude in the same direction.
The two billed units
Cloudflare’s Vectorize pricing page defines two:
- Stored vector dimensions — the total dimensions of all vectors in an index. Cloudflare’s example: 1,000 vectors at 1,536 dimensions is 1.536 million stored vector dimensions.
- Queried vector dimensions — Cloudflare’s example: an index of 10,000 vectors at 384 dimensions, queried 100 times, sums to 3.878 million queried vector dimensions.
Stop at that second example, because it is the whole page. 100 queries at 384 dimensions is 38,400. The figure Cloudflare gives is 3,878,400 — a hundred times larger. The extra is the index itself: 10,000 × 384 = 3,840,000, plus the 38,400 for the queries.
The formula, checked against Cloudflare’s example
Cloudflare states the pricing formula as ((queried vectors + stored vectors) × dimensions × ($0.01 / 1,000,000)) + (stored vectors × dimensions × ($0.05 / 100,000,000)). So queried vector dimensions are (vectors in the index + number of queries) × dimensions, not queries × dimensions.
That is the fact worth carrying away. Your query line item scales with how big the index is, not just with how much you query it, because a query is conceptually compared against the whole index. An index that is queried once a month still accrues its own size in queried dimensions.
The published allowances at the time of writing: Workers Free includes 30 million queried vector dimensions per month and 5 million stored vector dimensions. Workers Paid includes the first 50 million queried vector dimensions per month, then $0.01 per million, and the first 10 million stored vector dimensions, then $0.05 per 100 million.
Every figure in this section is Cloudflare’s published value at the time of writing. Verify against Cloudflare’s Vectorize pricing page before putting any of it in a budget.
A worked monthly figure
Assumptions, stated so you can substitute your own: an index of 200,000 vectors at 768 dimensions (a documentation corpus chunked to roughly a paragraph, embedded with a 768-dimension model), 50,000 queries in the month, on Workers Paid. Nothing below is measured; it is arithmetic on the published rates.
queried vector dimensions
= (200,000 stored + 50,000 queries) x 768
= 192,000,000
stored vector dimensions
= 200,000 x 768
= 153,600,000
query charge
= (192,000,000 - 50,000,000 included) / 1,000,000 x $0.01
= 142 x $0.01
= $1.42
storage charge
= (153,600,000 - 10,000,000 included) / 100,000,000 x $0.05
= 1.436 x $0.05
= $0.07
total = $1.49 per month
Two things are visible in that derivation that a per-query mental model hides. The query charge is 95% of the bill even though storage is the bigger raw number, because the two rates differ by a factor of 20 per dimension. And of the 192 million queried dimensions, 96 million came from the index existing and 0.038 million came from the queries — the queries are a rounding error against the index size.
Run the same corpus against the Free plan’s 30 million queried dimensions per month and it does not fit: 192 million is more than six times the allowance. A 200,000-vector index is a paid workload regardless of traffic.
What actually fits in the free tier
The Free plan’s two allowances are 30 million queried vector dimensions per month and 5 million stored vector dimensions. Because both scale with the same dimension figure, you can turn them straight into a maximum corpus size — and the answer is not the one people expect, because the smaller-looking allowance binds first.
storage ceiling (the binding one)
5,000,000 / 384 = ~13,020 vectors at 384 dimensions
5,000,000 / 768 = ~6,510 vectors at 768 dimensions
5,000,000 / 1024 = ~4,880 vectors at 1024 dimensions
query ceiling, for an index already at the storage ceiling
30,000,000 / 768 = 39,062 total (stored + queries)
minus 6,510 stored = ~32,550 queries per month
= ~1,085 queries per day
So the Free plan at 768 dimensions is about 6,500 vectors — roughly a few hundred pages of documentation chunked to a paragraph — and, at that size, around a thousand queries a day. Halving the dimension to 384 doubles both numbers at once, which is the clearest possible illustration of why dimension is the dominant lever.
Note the second calculation depends on the first. Because queried dimensions include the index’s own size, a smaller index leaves more of the 30 million allowance for actual queries. An index of 1,000 vectors at 768 dimensions consumes 0.768 million of the allowance before a single query, and can then absorb about 38,000 queries; an index at the storage ceiling consumes 5 million and can absorb about 32,500. The two allowances are coupled, and treating them as independent budgets will overstate what you can do.
The 1,536-dimension ceiling
Cloudflare documents a maximum of 1,536 dimensions per vector at 32-bit precision. This is a hard constraint on model choice, not a billing matter, and it is the second thing people discover late.
Embedding models that emit more than 1,536 values cannot be stored directly. Where a provider supports requesting a shorter output — some models are trained so that a truncated prefix of the vector remains usable — that is the supported route. Where it does not, arbitrary truncation of a model not designed for it degrades retrieval in ways that are hard to notice and harder to attribute.
Cloudflare’s own embedding models sit comfortably inside the ceiling at 384, 768 and 1024, so this only becomes a live question when you bring a third-party model.
What actually moves the number
Given the formula, there are exactly three levers, and they are not equally useful:
- Dimension. It multiplies both terms. Dropping from 768 to 384 halves the entire bill for identical data and identical traffic. This is the largest single lever and it is available only before you create the index, because the dimension is immutable.
- Vector count. Also multiplies both terms. Chunking strategy is a cost decision as much as a retrieval one: 400-token chunks instead of 200-token chunks halves the vector count for the same corpus.
- Query volume. Barely matters until it approaches the index size. In the worked example, tripling query volume from 50,000 to 150,000 adds 76.8 million to a 192-million figure — real, but second-order next to either of the above.
The counter-intuitive conclusion is that caching queries saves very little on Vectorize, while pruning stale vectors from the index saves on every query for the rest of the month. Deleting 50,000 vectors from the example index removes 38.4 million queried dimensions and 38.4 million stored dimensions, cutting the bill by about a quarter. For how this composes with the inference bill next to it, see Workers AI pricing and neuron limits.
Top comments (0)