Most products don’t need a search team. They need a search box that returns sensible results without becoming the thing that pages someone at 2am. This is for founders and product leads who’ve just heard “we need proper search” in a planning meeting and want to know what that actually means before they sign a contract or brief an engineer.
The honest answer is that in-app search sits on a spectrum, not a binary. At one end is a single SQL query against your existing Postgres database. At the other is a dedicated Elasticsearch cluster with its own uptime, its own on-call rota and its own bill. Most teams jump straight to the expensive end because “Algolia” and “Elasticsearch” are the names they’ve heard, when a much cheaper option would have covered them for the next two years. This guide walks through the three realistic tiers — Postgres, managed search, and Elasticsearch — what triggers a move up, and what it actually costs at each stage.
Tier one: Postgres already does this
If you’re running PostgreSQL, you have a working full-text search engine sitting underneath your application right now. It supports stemming, ranking, and phrase matching out of the box, and more recent extensions add typo tolerance and fuzzy matching on top. For most B2B tools, internal admin panels, ticketing systems and content-driven sites, this is genuinely enough.
Postgres full-text search is the right starting point when:
- Your searchable dataset is well under a million rows.
- Users are searching structured records — customers, orders, tickets, articles — rather than free-form documents.
- Search results need to respect the same permissions and joins as the rest of your data.
- You’re working in one primary language.
- You don’t need faceted filtering (price ranges, category counts, drill-downs) as a first-class feature.
The appeal isn’t just cost, though it is free at this scale — it’s operational simplicity. There’s no second system to keep in sync with your primary data, no separate index to rebuild after a schema change, and no extra vendor in your stack. If you’re still validating the product, this matters more than marginal relevance gains. We’ve written before about why schema decisions that survive growth tend to be the boring, well-understood ones rather than the fashionable ones, and search is a good example: reach for what you already run before reaching for a new category of infrastructure.
Tier two: managed search-as-a-service
You outgrow Postgres search when you can name a specific limit you’re hitting, not because a search bar appeared in a competitor’s demo. The usual triggers are: relevance quality genuinely affects conversion (e-commerce, marketplaces, content discovery), you need instant-as-you-type results at low latency, you need faceted filtering as a core UX pattern, or your catalogue has grown past the point where a single Postgres index performs comfortably.
At this point, a managed service is usually the pragmatic choice, because building relevance tuning, typo tolerance and synonym handling from scratch is a multi-month project, not a sprint.
Algolia remains the best-known option and is genuinely excellent for instant search UX, but its usage-based pricing (roughly £0.40–£0.50 per 1,000 searches once you’re past the free tier) scales with your traffic in a way that can surprise a growing product. Typesense and Meilisearch have become credible, open-source alternatives that offer comparable relevance and sub-50ms response times at a fraction of the cost — both are free to self-host, and their managed cloud tiers typically start much lower than Algolia’s equivalent usage. For most SaaS products and marketplaces, one of these two is the sensible default rather than the most famous name.
Before signing up for any managed search product, it’s worth running the same due diligence you’d apply to any vendor dependency. We cover this in more depth in our guide to third-party API integration cost — the sticker price is rarely the whole story once you account for indexing pipelines, webhook sync and the engineering time spent keeping a second copy of your data fresh.
Tier three: Elasticsearch, OpenSearch and self-hosted infrastructure
Elasticsearch (and its open-source fork, OpenSearch) earns its keep when search stops being “find this record” and becomes an analytics problem: aggregations across millions of documents, price histograms, category drill-downs, or log and event search at high write volume. If your search page needs to answer “how many results fall into each of these forty categories” in real time, that’s an aggregation engine’s job, not a database query you’ll maintain by hand.
Multi-language search across many locales simultaneously, with per-language analysers and custom tokenisers, is another genuine reason to reach for a dedicated engine rather than a managed SaaS tier.
The trade-off is operational weight. Elastic Cloud removes some of the hosting burden, but you’re still tuning shard counts, managing reindexing during mapping changes, and monitoring cluster health as a permanent line item — this is a decision to run a small standing service, not just ship a feature. It’s the same calculation we walk through in build vs buy authentication: the “buy” or “self-host mature open source” option is rarely about avoiding engineering effort altogether, it’s about spending that effort on your product instead of on infrastructure your competitors also have to maintain.
A simple decision framework
Rather than picking a tool because it’s popular, work through these questions in order:
- Can Postgres do it? If your dataset is small, single-language, and permission-scoped, start here. You can always migrate later — and you’ll know far more about your actual query patterns once you do.
- Do you need instant, typo-tolerant, faceted search? If yes, and your data volume is moderate, evaluate Typesense or Meilisearch before Algolia. Compare total cost at your projected traffic, not just the free tier.
- Is search actually an analytics or logging problem? If you need aggregations across millions of records, or you’re indexing high-volume event data, Elasticsearch or OpenSearch is the right category of tool — budget for the operational overhead honestly.
- Can you afford to be wrong? Whichever tier you choose, keep your search layer behind an interface your application code doesn’t need to know the internals of. Swapping Postgres FTS for Typesense later should be a backend change, not a rewrite of your product.
That last point is the one teams most often skip under deadline pressure, and it’s the one that saves the most pain later. A thin search service or repository layer — even a single function such as searchProducts(query, filters) — means the decision you make this quarter isn’t the decision you’re stuck with in two years. This is the same discipline behind avoiding costly rebuilds that we discuss in our guide to SaaS product development that avoids costly rebuilds: the goal isn’t to predict the future perfectly, it’s to make sure today’s reasonable choice doesn’t become tomorrow’s rewrite.
What this costs in practice
Postgres full-text search costs nothing beyond development time, since it’s already part of infrastructure you’re paying for. Self-hosted Typesense or Meilisearch are free software with real but modest server costs; their managed cloud tiers tend to start in the tens of pounds per month rather than hundreds. Algolia’s usage-based model can work out cheaper at low volume and considerably more expensive at scale — it’s worth modelling your expected search volume against their pricing calculator before committing, not after. Elasticsearch and OpenSearch bring both infrastructure cost and, more significantly, the engineering time to run them properly — factor in the person, not just the server.
None of these numbers are fixed, so treat any comparison, including this one, as a starting point for your own estimate rather than a quote.
If you’re scoping a search feature and want a second opinion on which tier actually fits your product — rather than the tier your last hire is most excited about — our team can help you work through the trade-offs before you commit engineering time. Book a free consultation and we’ll talk through your specific data and traffic shape.
FAQ
Can I just use Postgres full-text search for my app? For most early-stage products, yes. If your searchable data is under roughly a million rows, mostly one language, and doesn’t need faceted filtering, Postgres’s built-in full-text search covers it well and avoids adding a second system to maintain.
When should a startup move to Elasticsearch or Algolia? Move when you can point to a specific limit: relevance quality is affecting conversion, you need instant typo-tolerant search at scale, you need real-time aggregations across millions of records, or you’re indexing high-volume log or event data. Don’t move simply because a competitor’s search box feels faster.
Are Typesense and Meilisearch good alternatives to Algolia? Yes, for most SaaS products and marketplaces. Both are open source, can be self-hosted for free, and deliver comparable relevance and speed to Algolia at a fraction of the cost at scale, making them a sensible default before reaching for the more expensive managed option.
How much does adding search to a SaaS product typically cost? It depends entirely on which tier you need. Postgres-based search is close to free beyond development time; self-hosted or lower-tier managed search engines are typically tens of pounds a month; usage-based services like Algolia and fully managed Elasticsearch clusters can run into hundreds or thousands of pounds a month at scale. Get a feel for your real numbers via our pricing page or a quick conversation before assuming the worst case.
