Semantic search: what it can do, what it costs, how you build it in

Semantic search means: the search finds results by meaning, not by character string. If someone types «something to stop a squeaky door», it returns the silicone spray — even though not a single word of the query appears in the product text. A classic keyword search finds: nothing.

Technically, this works through embeddings: an AI model translates text into number vectors that capture meaning. Similar meaning produces similar vectors. The search compares the vector of your query with the vectors of your documents and ranks by proximity. How embeddings work inside a real application stack is something I cover in Supabase as an AI backend — here it's enough to know: meaning becomes measurable.

For context: not every search problem is a meaning problem. «gaskt ring» is a typo: typo tolerance solves that, not AI. «How do I seal a pipe?» is a meaning question: semantic search solves that. This distinction runs through the entire article, because in the end it decides whether you have to pay at all.

The term has a backstory, by the way: semantic search used to mean ontologies and knowledge graphs, hand-curated networks of concepts. The German Wikipedia article on the topic still describes almost nothing but this old world (de.wikipedia.org, retrieved September 4, 2026). If you ask about semantic search in 2026, you almost certainly mean the embedding variant — and that is what this article is about.

The rest of this article is practice: where keyword search loses, which stack fits which problem, what building it costs — and when you can skip the whole thing.

Keyword search compares character strings. It loses wherever people phrase things differently than your texts do. Three typical cases:

Synonyms: your shop says «cordless drill», the customer searches «battery screwdriver». Zero results.

Paraphrases: your help page is called «Returns process», the search says «send items back». Zero results.

Natural questions: «Which oil for beech wood?» matches no product name, even though the right care oil sits in your range.

Such zero-result searches are silent: the visitor who finds nothing doesn't complain to support, they move on to the next provider. The problem only becomes visible in your search analytics — more on that later.

Semantic search solves exactly these cases: it recognizes that «cordless» and «battery» live in the same meaning space. That is why it is strongest on content with a lot of language: blog articles, help centers, documentation, advice-heavy product ranges.

A practical exercise helps with the assessment: take a hundred real queries from your search log and mark how many of them are paraphrases rather than exact terms. In advice-heavy ranges, in my experience, this share is regularly higher than the operators estimate — in a pure spare-parts business it is often vanishingly small.

And where does keyword search win? Everywhere exactness matters. Someone searching «HC-4711-B» wants exactly this item, not a semantically similar neighbor. Part numbers, SKUs, error codes, proper names: here the exact match is the right result, and a meaning model tends to make the result list worse.

The consequence up front: the question is rarely «keyword or semantic», it is almost always «how much of each». That is exactly what hybrid search is for — more on it in a moment.

Three terms come up in every conversation about semantic search, and they get mixed up constantly. Yet they describe three different jobs with different tools.

Vector search is the engine room of semantic search: every document gets an embedding vector, every query gets one too, and the search looks for the nearest neighbors in vector space. The result is a ranking by closeness of meaning. You already know its weakness from the last section: exact codes and part numbers drown in meaning space.

Important for your budget: the vectors are created once per document at indexing time, not on every search. Only the query itself is embedded live, and queries are short. This asymmetry is what makes the cost calculation further down so friendly.

Hybrid search combines both methods in a single request: keyword hits and vector hits flow into one shared ranking. In Meilisearch, a parameter called semanticRatio controls this: 0.0 means pure keyword search, 1.0 means purely semantic, and the default is 0.5 (meilisearch.com/docs, retrieved September 4, 2026). For end-user search on websites and in shops, hybrid is the practical standard case.

An example of how the interplay looks: the query «Bosch cordless drill quiet» matches «Bosch» and «cordless drill» exactly as keywords, while the vector share pulls devices with a «low-noise gearbox» in their description up the list. Neither method alone would have built this order.

RAG (retrieval-augmented generation) uses the same vector technique but is a different product: a language model fetches matching text passages and formulates an answer in full sentences. The user sees no result list, but an answer. That is no longer a website search — it is a knowledge interface for applications. Typical uses: internal knowledge bases, support assistants, contract research.

This dividing line sounds academic but has tangible consequences: the two worlds have different tools, different cost profiles and different failure modes. The next section turns it into a concrete stack decision.

Before you compare tools, answer one question: who is actually searching here — a visitor on your website, or an application that needs knowledge? The answer determines the entire stack.

End-user search means: a search box, typos, facets, results while you type. For this I use Meilisearch: typo tolerance and facets are built in, and hybrid search ships in the standard binary. The vendor promises answers «in under 50 milliseconds» — that is a vendor claim, but the instant-search architecture behind it is real. What Meilisearch is exactly and where its limits lie is in my Meilisearch guide.

Important context: often you don't even need that. The search hierarchy starts with Postgres full-text search, which is entirely sufficient in many projects. Only when instant search, facets or, indeed, semantics are needed does a dedicated search service pay off. Elasticsearch sits one level higher still and is oversized for most websites — I have compared the Elasticsearch alternatives separately.

Knowledge retrieval inside applications is the other job: an internal tool should answer questions about contracts, a customer portal should serve knowledge from your documentation. For this I use pgvector on PostgreSQL, specifically on Supabase: the vectors then live in the same database as your other application data, with the same access rights and backups. A separate search service would only be a detour — and one more service with access to your data.

The rule of thumb for the split: a visible result list for humans means Meilisearch. Text passages as fuel for a language model mean pgvector. If a project needs both (shop search plus an advisory chat), those are two components with clearly separated jobs — not one system that half-does both.

Deliberately left out here is Elasticsearch with its own vector features: it can do semantic search as well, but it plays in a different weight class, with the operating effort to match. For most websites and shops it is not the first sensible step.

The implementation is manageable: you need a running Meilisearch index, an embedder and two configuration decisions. Here is how I go about it in projects.

First, on currency: hybrid search ships in the normal Meilisearch binary, currently version 1.53.1 from August 13, 2026 (github.com/meilisearch/releases, retrieved September 4, 2026). So you need neither a special binary nor an enterprise contract to get started.

The embedder is the service that translates your texts into vectors. Meilisearch ships integrations for OpenAI, Cohere, Mistral, Gemini, Cloudflare, Voyage AI, Jina, AWS Bedrock and HuggingFace, plus a REST embedder for arbitrary APIs (meilisearch.com/docs, retrieved September 4, 2026). Through the REST embedder you can also connect a self-hosted embedding model — relevant if your data must not leave the EU.

My standard starting point: OpenAI text-embedding-3-small. It costs $0.02 per million tokens, which makes it so cheap that model choice is rarely the cost question (developers.openai.com, retrieved September 4, 2026). Consistency matters more: documents and search queries must be embedded with the same model, otherwise the vector spaces don't fit together.

With every search request you specify the embedder (the field is mandatory) and set the semanticRatio between 0.0 and 1.0. The default of 0.5 weights keyword and vector hits equally (meilisearch.com/docs, retrieved September 4, 2026).

My experience from projects: start at the default, test with real queries from your search log and adjust in steps of 0.1. Ranges with many part numbers tolerate rather little semantics, text-heavy help centers considerably more. The dial is not a set-once setting but the result of these tests. And document the values you tested: six months from now, someone will want to know why it ended up at 0.4.

The document template defines which text gets embedded per document. This is where relevance is decided: title, description and category belong in it, internal IDs and URLs do not — they only dilute the meaning vector. Short and dense beats long and complete.

A workable template for a shop consists of title, category and description in a fixed sentence pattern. Usually that is all it takes. But check beforehand whether every document fills the template meaningfully: empty descriptions produce empty meaning — and with it, results that look random.

After that, indexing runs: Meilisearch sends every document through the embedder once and stores the vector in the index. When your data changes, it re-embeds — plan this pipeline in from the start, because a catalog that changes daily also embeds daily. What that costs is worked out in the next section.

From my experience: budget a few days for a clean implementation, not weeks — provided the Meilisearch index itself is already in place. The effort driver is not the configuration but the testing against real search queries.

Now for the question that none of the definition articles ranking at the top of Google answers: what does it cost, concretely? The answer surprises most people — the AI fees are the smallest item.

All numbers in this section come from the vendors' pricing pages, retrieved September 4, 2026, and from one worked example: 100,000 documents, 50,000 search queries per month. That corresponds to a mid-sized shop or a well-stocked help center.

Let's work through a mid-sized example: 100,000 documents at around 200 tokens each makes 20 million tokens. With text-embedding-3-small at $0.02 per million tokens, the complete initial indexing costs around $0.40 (developers.openai.com, retrieved September 4, 2026). Not a typo: forty cents.

The search queries are even cheaper: 50,000 queries at about 10 tokens each are 0.5 million tokens, so around $0.01 per month. Even if you re-embed the entire catalog weekly, you stay under $2 monthly. The fees do accrue per document and per query — at this order of magnitude they are still not a decision criterion.

Meilisearch Cloud starts at $20 per month. The pricing calculator quotes around $30 monthly usage-based for 100,000 documents and 50,000 search queries, alternatively $23 with a fixed instance (meilisearch.com/pricing, retrieved September 4, 2026). There is no surcharge for hybrid search on the pricing page: you pay the embedder fees directly to the AI provider.

Self-hosting costs only the server. Since 2025 the license has come with a nuance: the Meilisearch core is MIT-licensed and free for commercial use; only enterprise modules such as sharding sit under the Business Source License and need a contract with Meili SAS for production use — each release converts to MIT after four years (github.com/meilisearch, LICENSE, retrieved September 4, 2026). For a single website search this does not affect you.

For the operations decision the usual logic applies: self-hosting saves the cloud fee but costs you updates, monitoring and backups in your own hands. With a single search index that is manageable — still, price it in honestly instead of calculating with «the server is running anyway».

The honest calculation does not end at the API fees. What a project like this really costs is working time: designing the document template, testing the semanticRatio against real search queries, building and running the re-indexing pipeline, watching relevance after launch.

From my project experience, these items sit orders of magnitude above the cent amounts for embeddings. If you budget only the API prices, you budget the wrong thing: the agency or your own team costs more than the entire AI share of the project.

Summed up for the example: around $20 to $30 of infrastructure per month, cent amounts for embeddings, plus the working time for implementation and upkeep. That is not an enterprise budget — it is a feature project you can weigh against other features.

Now the part that can cost me business: many websites do not need semantic search. They first need a working search — and that is often something else.

The most common case in my practice: a well-maintained catalog with clean titles and descriptions whose search fails on typos and missing facets. Typo tolerance and good ranking rules solve most of the complaints there — without embeddings, without an AI provider, without ongoing extra costs.

Hence my order of operations: measure first, pay later. Look into your search analytics and answer two questions: which queries return zero results? And are those typos and spelling variants, or real meaning gaps like «gift for barbecue fans»?

Only the second category justifies semantic search. Without this measurement, you are buying a solution for a problem you have not proven.

Second limit: explainability. With a keyword search, you can tell from every hit why it is there. Behind a semantic hit stands a similarity score from a model — when an off result lands in position three, debugging gets sticky. Plan time for that instead of hoping for magic.

Third limit: vendor benchmarks. Numbers like «X percent better relevance» almost always come from vendor material with an unknown test setup. I never adopt such figures, and you should not base a buying decision on them: measure relevance with your own search queries, before and after.

How to measure «before and after» in practice: take twenty real queries from your log, ten of them known problem cases, and rate the first five hits for each, before and after the switch. That is not a scientific method — but it beats every gut decision and every vendor benchmark.

Fourth limit: semantics is no substitute for data upkeep. If your product texts consist of three words, even the best embedding model has nothing to draw meaning from. Content first, then intelligence — more on that in the B2B special case in a moment.

In short: semantic search is a precise tool for a precise problem. The guiding sentence of the whole search topic applies here too:

One special case deserves articles of its own: B2B product data. When your customers search by application instead of by part number («seal for drinking-water pipe» instead of a DIN designation), search quality depends less on the technology than on the product data itself. A meaning model can only find what is in the data. The classic pattern: the buyer knows exactly what the part has to do, but not what you call it.

How you get from part-number thinking to application search is covered in the article on semantic product search in B2B. And if your catalog texts are too thin for that, the step before it is enriching catalog data with AI: usable descriptions first, then embeddings. Reversing that order wastes money.

The difference from this article here: that one takes the data perspective — attributes, use cases, data upkeep. This one takes the generic technology and cost perspective. Only both together produce a search that actually gets B2B buyers to their goal. That is also why the two articles deliberately share no keywords: they answer different questions.

If you have read this far, you already know my recommendation: do not start with the tool, start with your search data. Pull the zero-result queries of the last three months from your search analytics, sort them into typos and meaning gaps, and only then decide on the stack. This analysis costs you an afternoon — and it tells you whether you are looking at a typo-tolerance problem or a real semantics project.

The decision in short: Postgres full-text search if a simple search is enough. Meilisearch with typo tolerance if users type like humans. Hybrid search if your search analytics shows real meaning gaps. pgvector on Supabase if an application should answer questions instead of finding documents.

If you want support along the way: I will go through your search analytics with you and tell you honestly, even when typo tolerance is enough and you can skip the embedding pipeline. Book a no-obligation intro call — after 30 minutes you will know which level of the search hierarchy your project needs.