Up front: which tier does your website search need?
Most website searches are bad: they don't forgive typos, they rank results with no discernible logic, and nobody reads their logs. The question is rarely which search technology is «the best». The question is which tier your project needs — and at what point the next tier is worth its money.
You rarely need Elasticsearch. You almost always need a better search than your website has today.
At happycoding we think about website search in three tiers. Tier 1: the Postgres full-text search that is probably already sitting in your database. Tier 2: Meilisearch, a standalone search engine with typo tolerance and facets. Tier 3: Elasticsearch or OpenSearch, when search and analytics touch your core business.
This article gives you three things: concrete criteria for when each tier is enough. Real costs with retrieval dates instead of «it depends». And the one lever almost everyone misses: your search log. By the end you can make the decision yourself — or at least properly evaluate any agency quote.
Why write this down? Because the guidance on this topic is surprisingly thin: what you find on «site search» today is mostly CMS click-through tutorials and forum threads. A decision guide along technology tiers, with real costs and dates, is what we could not find. So now it exists.
One boundary before we start: this article is about end-user search on your website or in your shop. Knowledge retrieval inside internal applications, i.e. RAG over your own documents, is a separate construction site with its own toolbox. We draw that line sharply once more further down.
Tier 1: the search you already have — Postgres full-text search
Before you buy a new search engine, look inside your database: PostgreSQL ships with a full-fledged full-text search. If your website runs on Postgres or Supabase anyway, Tier 1 is not a purchase but a configuration.
What Postgres can do — and what it can't
Postgres full-text search works with tsvector and tsquery: text is broken down into word stems, so «gaskets» also finds pages that say «gasket». On top of that you get relevance ranking including word proximity, phrase search, and preconfigured language profiles, German included (postgresql.org, retrieved September 4, 2026).
What's missing is typo tolerance: the query «gaskt ring» returns zero hits in the standard full-text search. With the pg_trgm extension you can retrofit fuzzy matching via trigrams — with your own indexes, your own thresholds, and your own query logic. That works, but it is manual labor instead of a built-in default.
In practice, Tier 1 means: one search endpoint in your existing application, querying the database you already operate. No second system, no second index, no synchronization. What you still have to build is the results page itself: hit list, highlighting, empty state. At Tier 1, the search logic is often the smallest part of the work.
When Tier 1 is enough
Our rule of thumb from projects: Tier 1 is enough when four criteria come together.
A manageable inventory: your website has a few hundred pages or records. At that scale, full-text search returns usable hits without long fine-tuning sessions on relevance.
No facets: nobody needs to filter results by category, price, or manufacturer. As soon as filter bars enter the picture, you are in Tier 2.
Search is a side function: your visitors navigate primarily via the menu and internal links. Search is a fallback, not a central control.
Your data already lives in Postgres: that eliminates the biggest cost item of any search solution, the indexing pipeline. You simply query the database you already operate.
If you meet all four points, a new search engine is money thrown away: you would be running a second system that finds nothing Postgres doesn't find too. If one of the points breaks, read on.
Tier 2: Meilisearch — when search is a feature
As soon as your search is a product feature, say in the shop, the customer portal, or the knowledge base, a dedicated search engine pays off. Our default recommendation for that is Meilisearch. What the tool is exactly and where it fits, we've written up in our CIO guide to Meilisearch.
What you get
Meilisearch is built for instant search: results appear as you type, and typo tolerance and facets are the default rather than an add-on project. «gaskt ring» becomes «gasket ring» without any configuration. The vendor promises answers in under 50 milliseconds — a vendor claim (meilisearch.com, retrieved September 4, 2026), but one that matches our project experience at typical data volumes.
Semantic search is part of the normal binary, too: via the semanticRatio parameter you blend full-text and vector hits continuously. Available embedding sources include OpenAI, Cohere, Mistral, Gemini, and HuggingFace, plus a REST embedder for arbitrary APIs. What that buys you in practice, and when it is overkill, is in our article on semantic search.
For perspective: Meilisearch finds documents for your visitors. If you want to answer questions in natural language, you are looking at RAG — a different tool for a different problem; we show that stack in Supabase as an AI backend with pgvector.
What it costs
Since August 2025 the license has two halves, and both belong in any serious recommendation. The core is MIT-licensed: free to use, in production and commercially. Alongside it sits the Enterprise Edition under the Business Source License 1.1: production use requires a contract, and each release converts to MIT after four years. Enterprise-exclusive right now are modules such as sharding, i.e. distributed setups, plus analytics and access-control features (meilisearch.com/blog, retrieved September 4, 2026).
On prices, retrieved September 4, 2026: Meilisearch Cloud starts at $20 per month. The cost calculator quotes around $30 per month for 100,000 documents and 50,000 search requests. Self-hosting is free; in return, updates, backups, and scaling are on you.
For our positioning, a third path counts as well: self-hosting on your own server in the EU. Your search queries, and with them a surprisingly honest picture of what your visitors want, then stay entirely on your infrastructure. The project is actively maintained: as of September 4, 2026, v1.53.1 from August 13, 2026 is the current release.
Tier 3: Elasticsearch and OpenSearch — when search is your core business
Tier 3 is for cases where search is more than a search bar: analytics across millions of events, log analysis, very large or fast-growing data volumes. Elasticsearch and OpenSearch are built for that — and in return they demand a dedicated operations team or a budget for managed hosting.
Typical signals that you really are in Tier 3: you don't just want to find things but to analyze them, say search trends over months or dashboards over log data. Your data volume grows faster than a single instance can grow with it. And someone in the building runs the cluster as part of their job, not on the side.
Briefly on licensing, because it is often told wrong. Since the end of August 2024, Elasticsearch is triple-licensed: ELv2, SSPL, and additionally AGPL (elastic.co, retrieved September 4, 2026). OpenSearch, created in early 2021 as a fork of Elasticsearch, is under Apache 2.0 and since September 2024 belongs to the OpenSearch Software Foundation under the umbrella of the Linux Foundation (linuxfoundation.org, retrieved September 4, 2026).
For you this means: both options are viable for production as far as licensing goes. The decision comes down to operations and ecosystem, not the license.
Our honest limit: we advise most clients against Tier 3. A cluster wants to be sized, monitored, updated, and secured — running costs that a website search rarely justifies. Which of the two options fits when, we compare in Elasticsearch vs. OpenSearch; lightweight ways out are collected in our Elasticsearch alternatives.
What the switch costs: experience values from our projects
Up front: the following effort figures are happycoding experience values from our own projects, not market data. Your case can differ — upward as well as downward.
Making the most of Tier 1: setting up full-text search on existing Postgres data, including ranking and a German language profile, typically takes us two to five person-days. With retrofitted pg_trgm typo tolerance, expect the upper end.
Introducing Tier 2: setting up Meilisearch, syncing data into it, and building a search interface with facets usually takes us between one and three weeks. The server itself is up quickly; the time goes into the edges around it.
Introducing Tier 3: an Elasticsearch or OpenSearch setup starts at several weeks and never quite ends, because operations need permanent attention. That is why this tier is only up for debate with us when the requirements force it.
The three biggest effort drivers are the same at every tier. The indexing pipeline: how do changes from your system reliably reach the search index? The facet data model: filters are only as good as the data fields behind them. And multilingual content: every language needs its own language profiles and often its own indexes.
For your next agency quote, that means: have the effort broken down along these three drivers. A flat price for «adding search» without a look at the data model and the languages involved is not a calculation, it is a bet.
Your search log: the cheapest source of insight on your website
Whichever tier you choose: log every search query, especially the ones with zero results. That log is the cheapest user research you can get — your visitors literally type out what they expect and cannot find.
Zero-result queries are three lists in one. A synonym backlog: if people search for «invoice» but your site says «receipt», you add the synonym. A content gap list: frequent searches with no matching page are an editorial plan nobody bills you for. And a source of product ideas: recurring queries for features that don't exist are feature requests in raw form.
In practice you need very little: log the search term, the number of hits, and a timestamp — nothing more. A simple database table is enough to start. What matters is the routine: once a month, look at the most frequent zero-result queries and fix three of them. That is one hour of work with a measurable outcome.
Baymard's research shows how much is left on the table here: in large-scale user tests of e-commerce search, more than 700 search-specific usability issues surfaced, and the benchmark across 344 large US and EU websites rates site search as weak overall (baymard.com, retrieved September 4, 2026). The conversion multipliers circulating on top of that, we deliberately do not cite: the primary sources are not freely accessible.
And thought one step further: whoever systematically derives features from search queries ends up building software, not just search. That is exactly where custom software development starts for us — not with a greenfield idea, but with documented demand from your own search log.
Next steps
Run the self-test with three questions. First: do your visitors need filters or typo tolerance? No means Tier 1. Second: is search a feature of your product? Yes means Tier 2, in most cases Meilisearch. Third: do you need analytics across very large data volumes, and do you have an operations team? Only then is Tier 3 an answer.
The cheapest first step costs you nothing: activate your search log today and look at the zero-result list in two weeks. It will tell you more reliably than any consultant whether your visitors are failing at your search — and exactly where.
If the search becomes part of a larger application, say a portal or a shop, you'll find our approach under web app development. And if you are unsure which tier fits your project: book a free initial call with me — we'll look together at your data, your search log, and the most honest answer to the question of whether you need anything new at all.
