What Does It Cost to Add Semantic Search to a Retail Catalog?

Three numbers plus a one-off

Semantic search cost for a retail catalogue breaks into three parts — a one-time build, a per-search runtime cost, and the infrastructure to keep the index fresh — plus a single upfront bill to embed the whole catalogue the first time. Comparing an internal build to a vendor licence fairly means lining up all four, not just the headline.

The one-time build

• The indexing pipeline that turns each product into a clean composed field and embeds it.
• Vector store setup — a vector extension on the database you already run, or a separate dedicated database.
• The retrieve-then-re-rank service that answers queries.
• The merchandising console — boost, bury, and filter controls exposed as data the team edits without a redeploy. This is often the largest single line; it's a real internal application.
• An evaluation harness of real queries to tune against.
• The initial bulk embed: one embedding call per SKU across the catalogue. A one-off, and modest with a small embedding model.

The recurring per-search cost

Each search makes one query-embedding call and one re-ranking call. This scales with search volume and spikes when traffic does. The lever here is model choice: a small embedding model runs at roughly a fifth of the per-token cost of a large one, with only a few points of difference on retrieval benchmarks at catalogue scale. On our semantic search project the small model was the default for exactly that reason — the quality gap didn't justify the cost at continuous re-embedding volume.

The recurring infrastructure

• The vector store. Cheap if it's an extension on a database you already operate; a distinct line item if it's a dedicated service.
• The async re-embed worker, always on, processing the semantic changes from the supplier feed.
• Ongoing relevance tuning between seasons.

What pushes it up

• A dedicated vector database instead of an extension — needed only at multi-million vectors or query volume past a single database instance.
• A large or multilingual embedding model.
• Continuous re-embedding on a fast-churning feed.
• Per-shopper personalization layered on top — that's a different system, not an extension of this one.

What pulls it down

• Keeping vectors in your existing database, so there's no second system to run.
• A small embedding model.
• Filtering re-embeds to semantic-field changes, so price and stock ticks don't trigger work.
• A narrow scope: search plus rule-based merchandising, not personalization.

A worked structure (variables, not numbers)

• N = SKUs, Q = searches per month, Qp = searches in a peak month.
• Initial embed ≈ N × embed-cost-per-item (one-off).
• Monthly runtime ≈ Q × (embedding call + re-ranking call); budget Qp × … for peak months.
• Infrastructure ≈ vector store + one worker, roughly flat.
• Build cost amortised over about two years.

The swing variable is search volume. N you know, and the infrastructure you can bracket; how Q grows is the number that moves the total.

Comparing against a licence

Managed search-as-a-service replaces the build cost with a subscription, usually billed on some mix of search requests and catalogue records, with AI-relevance features often on a higher tier than plain search. The trade you're weighing: no build and no pipeline to run, against a fee that scales with catalogue size and query volume rather than flattening out once the system is built. For a smaller catalogue or a team that wants zero search infrastructure to own, the licence is frequently the right call. It stops being the cheaper option as catalogue size, query volume, and the need for control over relevance and cost-per-query all grow together.

Where it doesn't pay back

• Small, stable catalogue. Keyword search plus a short synonym list is already near the ceiling.
• Very low search usage. The per-query cost has nothing to earn against.
• Estimates age. Re-quote embedding and re-ranking pricing before committing — multi-call search is sensitive to per-token cost.

FAQ

Is the vector store the expensive part? Usually not, if it's an extension on a database you already run. The merchandising console and the per-query calls are the bigger numbers.

What's the cheapest way to start? A small embedding model, vectors in your existing database, and scope limited to search plus boost-and-bury merchandising.

Can I predict the run cost before building? Within a range. N and Q are known; the uncertain input is how search volume grows over the amortisation period.

ISTRALLEN scopes semantic search against real catalogue size and search volume, sizing build and run cost up front; see AI for Retail.