Most visual-search budgets are one number wide: a vendor’s per-query price, multiplied by forecast query volume, plus a monthly index fee. That model will survive the pilot and break in the first seasonal refresh, because it prices the storefront surface and ignores the machine behind it. A defensible cost model for visual search has six lines, not two, and the line that decides whether the deployment is affordable is usually the one nobody costed: re-embedding driven by catalogue churn.
This is a costing method, not a price list. Every figure below is one your own catalogue and your own hardware produce; what we are supplying is the shape of the model and the order in which to fill it in.
What the cost lines in a visual-search pipeline actually are
Start by refusing to treat visual search as a single service with a single price. It is a loop, and each stage of the loop bills differently — some per image, some per query, some per month regardless of activity.
| Cost line | Unit it scales with | Billing shape | Where the number comes from |
|---|---|---|---|
| Initial catalogue embedding | Images in catalogue | One-off burst | Embedding throughput (images/sec) × GPU hourly cost |
| Re-embedding | Churned images per period | Recurring, churn-driven | Churn rate × same throughput figure |
| Index build / upsert | Vectors written | Per rebuild or per upsert batch | Full-rebuild time vs incremental write cost |
| Vector-store residency | Vectors resident × dimension × precision | Fixed monthly | Memory or managed-service tier |
| Query-time inference + retrieval | Image queries | Per 1,000 queries | Query embedding cost + top-k retrieval cost |
| Fallback handling | Failed or low-confidence matches | Per incident, often human | Fallback rate × handling cost per incident |
Two of those lines are commonly missing from vendor quotes. Re-embedding is missing because it depends on the buyer’s catalogue behaviour, not the vendor’s platform. Fallback handling is missing because it lands in a different team’s budget — merchandising, support, or content ops absorb it as work rather than as spend.
The cost of a visual-search deployment is dominated by catalogue churn, not query volume, for any retailer whose imagery turns over faster than its traffic grows. That is the single most useful sentence to take into a budget conversation, and it is also the one most quotes are constructed to avoid.
Turning churn into a recurring line, step by step
Churn is a measurement, not an assumption. The method has four steps and none of them require the system to exist yet.
1. Measure the churn rate on the images, not the SKUs. Count, over a representative period — one full season is the minimum honest window — the number of catalogue images that were added, replaced, re-shot, or retired. Variant edits and price-driven catalogue restructures count if they change the image set. A retailer can have flat SKU counts and heavy image churn; costing on SKU counts alone understates the load.
2. Convert churn into embedding work. Churned images per period × cost per embedded image. That second factor comes from measured throughput on the hardware you intend to use, at the batch size and precision you intend to use. This is where an audit of embedding throughput earns its keep: an assumed images-per-second figure carried into a twelve-month model compounds every error in it twelve times over.
3. Decide rebuild versus upsert, and cost both. Incremental upsert is cheaper per image but degrades index quality in some approximate-nearest-neighbour structures as the proportion of inserted-since-build vectors rises. Full rebuild restores quality and costs the whole catalogue again. The model needs a rebuild cadence — quarterly, per season, on a drift threshold — and the annual cost of that cadence stated separately from the upsert cost.
4. Compare year-one recurring to year-one build. Sum twelve months of re-embedding plus rebuilds, and put it beside the initial embedding cost. On catalogues with meaningful seasonal turnover, the recurring total can exceed the initial build inside the first year — which is precisely the outcome a one-off build model cannot represent. If your churn measurement puts you anywhere near that crossover, the budget conversation is about run-rate, not project cost.
Sibling reading if this step is where your problem actually lives: we develop the freshness side of this in what it costs to keep a product-image index fresh, and the pilot-design consequences in why visual search pilots fail when catalogue churn is high.
Deriving your two unit costs
Everything above collapses into two numbers a product or merchandising lead can carry into an approval meeting.
Cost per indexed image, per period:
(embedding cost for churned images
+ amortised rebuild/upsert cost
+ monthly vector-store residency)
÷ images resident in the index
Cost per 1,000 image queries:
(query-side embedding cost
+ retrieval cost
+ fallback rate × cost per fallback incident)
× 1000 ÷ queries in period
Keep the fallback term inside the query cost. A pipeline that returns nothing usable for one query in ten is not cheap; it has moved cost to a human and out of the ledger. When we price discovery pipelines with retail teams, the fallback term is where the arguments happen — and it is usually the term that decides whether “cheap” retrieval was actually cheap.
Report the monthly run-rate split into two halves: fixed index residency, and churn-driven re-index. The split matters because the two halves respond to different levers. Residency responds to vector dimension, quantisation, and how much of the catalogue needs to be searchable at all. Re-index responds to churn cadence and to how much staleness the storefront can tolerate. Freshness latency becomes a spend decision at that point rather than an engineering preference — you can say what a one-week staleness window costs versus a same-day one.
When does a managed vector service beat self-hosted indexing?
The flip point is not a catalogue-size constant, and any vendor who gives you one is selling. It is a comparison of two curves:
- Managed — near-zero fixed engineering cost, per-vector-per-month pricing that scales linearly and does not stop scaling. Wins while the catalogue is small enough that platform pricing is less than an engineer’s attention.
- Self-hosted — real fixed cost in setup, on-call and rebuild tooling, then marginal cost that tracks hardware rather than a price sheet. Wins once residency volume is large enough to amortise that fixed cost.
Practical rule for the model: compute total annual cost both ways at your measured vector count, then recompute at 2× and 4× that count. If the managed line crosses the self-hosted line inside your two-year horizon, you are building for the crossover, not for today. Also cost the burst asymmetry — embedding jobs run in concentrated bursts, so provisioning permanent GPU capacity for a job that runs a few hours a week is an avoidable line, and elastic or scheduled capacity for the embedding stage is often the largest single saving available in the whole model.
Setting the lift threshold before you build
A cost model is only decision-grade when it produces a number the business has to beat. Take the modelled monthly run-rate, divide by expected image-search sessions, and you have the cost per exposed session. Put that against average order value and current conversion rate on the discovery surface, and the model tells you the incremental image-search-to-purchase rate the deployment must produce to break even. Pre-register that threshold. A team that agrees the threshold before the build cannot later be talked into declaring a marginal result a success — and measuring against it cleanly is its own discipline, covered in measuring visual search conversion lift against noise.
Two notes on scope. This model prices the product-discovery pipeline — image in, catalogue match out — and nothing about shopper behaviour or profiling; the broader framing of that surface sits in how AI visual search changes product discovery for retailers. And the throughput assumptions underneath every per-image figure come from ordinary computer-vision pipeline practice: batching, precision choice, preprocessing cost, and I/O. If you want the engineering side of those assumptions, our computer vision practice covers the pipeline mechanics, and the retail work covers where these deployments sit commercially.
Which assumptions break first
Rank your model’s assumptions by fragility and re-measure the top ones quarterly. In our experience the order is fairly stable: churn rate drifts first (it is seasonal and nobody owns it), then embedding throughput (model swaps, resolution changes, precision changes), then fallback rate (it rises as the long tail of shopper queries widens), then residency cost (usually the most predictable line in the model). Vector dimension changes are rare but catastrophic to the model — a model upgrade that changes embedding dimension re-prices residency and forces a full re-embed of the catalogue at once.
The uncomfortable question to sit with: if your churn measurement turns out to be twice what you assumed, does the deployment still clear its lift threshold — or did the business case depend on the catalogue standing still?
Frequently Asked Questions
What does modelling the cost of visual search at catalogue scale mean in practice? Model Cost Visual Search works like this. It means costing the whole loop rather than the storefront call. Six lines — initial embedding, churn-driven re-embedding, index build or upsert, vector-store residency, query-time inference and retrieval, and fallback handling — each with its own scaling unit and billing shape. The output is a monthly run-rate split into fixed residency and churn-driven re-index, plus two unit costs.
How do you turn catalogue churn rate into a recurring re-index cost rather than a one-off build cost? Measure added, replaced, re-shot and retired images over a full season, multiply by your measured cost per embedded image, add the amortised cost of your rebuild cadence, and state the twelve-month total beside the initial build cost. On catalogues with meaningful seasonal turnover the recurring total can exceed the initial build within the first year.
How do you calculate cost per indexed image and cost per 1,000 image queries? Cost per indexed image is periodic embedding plus amortised rebuild plus residency, divided by resident images. Cost per 1,000 queries is query-side embedding plus retrieval plus the fallback rate multiplied by cost per fallback incident, normalised to a thousand queries. Both depend on throughput measured on your own hardware at your intended batch size and precision.
When does a managed vector service beat self-hosted indexing on total cost? There is no universal catalogue size where this flips. Managed pricing scales roughly linearly with resident vectors; self-hosted carries real fixed cost then cheaper marginal cost. Compute both at your current vector count, then at 2× and 4×, and build for whichever side of the crossover falls inside your planning horizon.
Which cost assumptions break first as the catalogue grows? Churn rate drifts first, then embedding throughput as models, resolution or precision change, then fallback rate as the query long tail widens; residency is usually the most stable line. A change in embedding dimension is the rare assumption break that re-prices residency and forces a full catalogue re-embed simultaneously.
Catalogue-scale visual search: infrastructure reality check
Running visual search across ten thousand products costs pennies; running it across ten million forces hard conversations about index architecture and refresh cadence. If Model Cost Visual Search is on your roadmap, the next step is to map it onto your own constraints rather than copy a reference architecture.
