Semantic retrieval helps products be found by meaning while structured records keep the result inspectable. Credit: Generated for Simlir
The short answer
A semantic product database lets a system retrieve products by meaning and intent rather than by matching keywords, and returns each match as a structured record — identifiers, comparable specifications, images, review context, a dated price snapshot and a retailer link — that an application can inspect, compare and explain. It sits between a shopper’s question and a set of retailer catalogues. Keyword search finds strings. A retailer catalogue describes one merchant’s stock. A semantic product database is built so that a request like “a quiet dishwasher for an open-plan flat” can resolve into candidates a program can rank, filter and justify.
A seven-stage architecture for shopping assistant search: intent, retrieval, structured records, provenance, comparison, MCP or REST access, and failure testing.
A semantic product database is a product store where retrieval is driven by the meaning of a request rather than by literal term matching, and where every result is returned in a predictable structured shape.
Two halves matter equally, and most systems only get one of them right:
Semantic retrieval. The request is interpreted as intent and constraints, not as a bag of words. “Something like this but cheaper” and “quiet enough for an open-plan flat” are meaningful inputs, not noise to be stripped out.
Structured output. What comes back is not a ranked list of web pages or a block of prose. It is a record with named fields: a stable identifier, a brand, a category, comparable specifications, images, a review score, a price snapshot with a date, and a link back to the retailer page the evidence came from.
Without the first half, a shopper has to translate their need into the vocabulary of a filter system. Without the second half, an application can generate fluent copy but cannot sort by price, compare two specifications, show its working, or send anyone to a product page.
How it differs from keyword search and a retailer catalogue
The three things are often conflated. They solve different problems.
Keyword search
Retailer catalogue
Semantic product database
Input
Terms and filters
Category paths and facets
Plain-language intent, an image, or an exact identifier
Scope
Whatever is indexed
One merchant’s stock
Products structured from public retailer pages, scoped to a market
Output
Ranked documents or SKUs
Product pages and feeds
Structured records with fields an application can read
Handles “quiet, fits a small kitchen”
Poorly — unless someone wrote those exact words
Only if a facet exists for it
Yes, as intent plus comparable specifications
Good for
Known-item lookup
Merchandising and checkout
Cross-retailer comparison, assistants, product discovery features
A retailer catalogue is authoritative about one shop and says nothing about the rest of the market. Keyword search is precise when a shopper already knows the product name and unhelpful when they do not. A semantic product database is the layer you reach for when the request is expressed as a need rather than a name, and when the answer has to be comparable across more than one retailer.
What a useful product record contains
The value of a semantic product database is decided by the fields it preserves. A title and a URL is a bookmark. A record an application can reason about needs, at minimum:
Identity
A stable internal id, plus the identifiers the rest of the industry uses: gtin, model_number and retailer_sku. Identity is what lets you join, deduplicate and re-fetch later.
Comparable specifications
A spec object with named attributes, so two candidates can be compared on the same axis instead of on two different marketing paragraphs.
Visual and descriptive context
A durable hero image_url, a gallery, a short product_description, and key_selling_points that summarise why the product exists.
Evidence and destination
A review_score with its review_count, a dated price snapshot, the market the record applies to, and a links.retailer destination.
Here is an abridged record from the simlir contract. Every field shown is part of the published response format:
product object (abridged)
{
"id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"brand": "Optimum Nutrition",
"category": "protein powder",
"gtin": "5060245603478",
"title": "Optimum Nutrition Gold Standard Whey Protein Powder",
"product_description": "Premium whey protein powder with 24g protein per serving...",
"key_selling_points": ["24g protein per serving", "5.5g BCAAs", "Informed Sport certified"],
"spec": {
"protein_per_serving": "24g",
"servings": "29",
"calories_per_serving": 120,
"flavour": "Double Rich Chocolate"
},
"image_url": "https://images.optimumnutrition.co.uk/whey-front.jpg",
"model_number": "GS100W-2270G-DRC",
"retailer_sku": "ON-2270G-GB",
"review_score": 4.8,
"review_count": 20,
"price": {
"amount": 29.99,
"currency": "GBP",
"retailer": "Holland & Barrett",
"as_of": "2026-04-07"
},
"links": {
"retailer": "https://www.hollandandbarrett.com/shop/product/..."
},
"market": "gb",
"relevance_score": 0.923
}
Notice what the price field does. It is not a bare number. It carries currency, the retailer it was observed at, and as_of — the date the value was last seen. That is the difference between a price your application can explain and a price it can only assert.
Natural language and image queries
Shoppers arrive with three different kinds of certainty, and a semantic product database should accept all three.
The shopper has…
Query type
What comes back
A need in their own words
Semantic search
Ranked candidates with a relevance_score (cosine similarity, 0–1)
A photo or a screenshot
Image search
Visually similar candidates with a visual_similarity_score
A GTIN, MPN or retailer SKU
Exact lookup
Matching products, no semantic ranking involved
Two details are worth internalising early because they shape your interface design. First, the two scores are not interchangeable: relevance_score is a text-similarity measure and visual_similarity_score is a visual-match measure, and comparing one against the other is meaningless. Second, on search endpoints limit is a ceiling, not a promise — a post-search sanity filter can return fewer items, or zero, when the candidate page is clearly the wrong product type. An interface that assumes it will always receive ten results will eventually show an empty grid with no explanation.
Why market scope, source and checked time matter
Product data has three properties that a generic document index does not have to worry about: it is local, it is sourced, and it expires.
Local. A price, a retailer and an availability status only mean something inside a market. simlir requires the shopper country on every search (gl on REST, market on image search and the MCP tools) and echoes it back in the response. Country is never inferred server-side. If the requested country and the returned market disagree, treat that as an integration bug.
Sourced. Records are structured from public retailer pages, and the retailer link stays attached to the record. That is what lets a team investigate a surprising result instead of accepting it.
Expiring. A price is a snapshot from a moment in time, carried with the date it was seen. Retailer pages change afterwards. Any product surface that presents a stored price as a live quote is making a promise it cannot keep.
The meta block is the other half of the contract. It tells you how many results you actually received, which market answered, how long the request took, and what it cost in credits. Surfacing those numbers internally is the cheapest observability you will ever add.
MCP and REST as access routes
A semantic product database is a service, and there are two sensible ways to reach one.
REST is the right choice when your own code decides when to search — a backend service, a comparison page, a scheduled job, a catalogue join.
MCP (the Model Context Protocol) is the right choice when a model inside an agent workflow decides when to search. The simlir hosted endpoint exposes simlir_search_products, simlir_search_products_by_image and simlir_lookup_products_by_identifier, which a compatible client discovers automatically through tools/list.
The important point is that these are two doors into the same room. Authentication, credits, market scope, response shape and limits are identical either way, so choosing one does not commit you to a different data model. We compare the two in detail in MCP or REST for product data in a shopping assistant.
When a team should use one — and when not to
Reach for one when
Shoppers express needs in their own words, or with a photo. Your answer has to span more than one retailer. You need to compare candidates on specifications, not on marketing copy. You would otherwise be building and maintaining retailer-by-retailer retrieval. You need to show where a number came from and when it was seen.
You probably do not need one when
You are searching your own catalogue and already control every field. Requests are always exact identifiers — a lookup endpoint is cheaper and simpler. You need real-time inventory or a binding price at checkout. Snapshots are evidence for a decision, not a quote. Your market is not covered yet.
The honest framing is that a semantic product database removes a retrieval and normalisation problem from your roadmap. It does not remove the need to think about ranking, presentation, freshness expectations, or what your product tells a shopper when the evidence is thin.
Frequently asked questions
Is a semantic product database the same as a vector database?+−
No. A vector database is a storage and retrieval component — it holds embeddings and answers nearest-neighbour queries. A semantic product database is a complete product service: it decides what a product record contains, keeps identifiers and provenance attached, scopes results to a market, and returns a stable response shape. Semantic retrieval is one part of it, not the whole thing.
Does it replace a product feed?+−
It solves a different problem. A merchant feed is authoritative for one retailer and is usually built for advertising, so it is shallow on specifications. A semantic product database is built for retrieval and comparison across retailers. Many teams use both: the feed for their own commercial relationship, the database for discovery and comparison. If you already hold GTINs from a feed, exact lookup is the natural join point.
Are the prices live?+−
No, and no product data service should claim otherwise. simlir returns a price snapshot: the amount observed when the product was last rediscovered, with its currency, the retailer it was seen at, and an as_of date. Retailer pages change after we see them. When a shopper is ready to act, send them to links.retailer.
Which markets does simlir cover?+−
The beta catalogue is live for the United Kingdom (gb). The United States is planned next. The API contract recognises additional technical country codes, but database-backed ingestion coverage is what determines whether results can be returned. The data quality page states the current position.
Can search return fewer results than I asked for?+−
Yes, and you should design for it. On /v1/search, /v1/search/image and the MCP search tools, limit is a ceiling rather than a guarantee. A post-search sanity filter removes obvious product-type mismatches, so a page can come back short or empty. Read meta.count and give your interface a genuine empty state.
A price without its currency, retailer and checked time cannot be explained. How to model price snapshots honestly, and what to do with stale or missing values.
