What is a semantic product database?

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 plain definition

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.

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:

Here is an abridged record from the simlir contract. Every field shown is part of the published response format:

{
  "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.

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.

Market boundary. The simlir beta catalogue is live for the United Kingdom (gb) only. The United States is planned next. The API contract recognises further technical country codes, but database-backed ingestion coverage is the source of truth for what can be returned today. See what is live.

"meta": {
  "count": 5,
  "market": "gb",
  "response_time_ms": 340,
  "credits_used": 2
}

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

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