Site Search for Web Apps: Typesense, Meilisearch or Algolia?

Search is one of those features that looks trivial in a design file and turns out to be surprisingly deep in production. A box at the top of the page, a list of results underneath. But users judge a product quickly by whether search "just works": whether it forgives typos, shows results as they type, understands that "t-shirt" and "tee" are the same thing, and puts the right item first.

For startups, the decision is not only which engine is best. It is how much search quality your product genuinely needs, how much operational burden you can carry, and what you can afford as your data grows. This guide compares the main options, from your existing database to open-source engines to hosted services, and offers a practical way to choose.

Start with the question: what does search do for your business?

Before comparing tools, define the job. A few typical cases look very different from each other:

• E-commerce catalogue search. Typo tolerance, filters by size, price, and brand, synonyms, and ranking by popularity or margin directly affect revenue.
• SaaS in-app search. Users look up records, documents, or people. Permissions matter: results must respect who is allowed to see what.
• Content and documentation search. Relevance across long text, highlighted snippets, and quick navigation matter most.
• Marketplace search. Location, availability, and personalised ranking come into play.

Write down your top five search queries, the filters people will need, the number of records now and in a year, and how fresh results must be. That short brief makes every later decision easier.

Option 1: Your database's built-in search

If you already run PostgreSQL, MySQL, or a similar database, start by checking what it offers. PostgreSQL, for example, has full-text search with ranking, stemming for many languages, and trigram indexes for fuzzy matching. It keeps everything in one system, with no extra infrastructure, no sync problem, and transactional consistency.

It works well when:

• Your dataset is modest and queries are mostly keyword based.
• You can accept simpler relevance tuning.
• You want the fewest moving parts possible.

It struggles when:

• You need instant as-you-type results with strong typo tolerance.
• You need rich faceting and counts across many filters.
• Search load competes with your transactional workload.

For many early products this is the right call. Ship it, measure how people use search, and move up only when the pain is real.

Option 2: Open-source engines (Typesense and Meilisearch)

Typesense and Meilisearch were built for the "search-as-you-type" experience. They are designed to be easy to set up, fast on modest hardware, and forgiving of typos out of the box. Both offer filtering, faceting, sorting, and sensible default relevance, and both provide client libraries and ready-made UI components for common front-end frameworks.

The attractions are similar: predictable cost since you can self-host or use the vendor's cloud offering, fast responses because indexes are optimised for search, and a developer experience that is simpler than older engines. The trade-offs are operational: you now run another service, plan for backups and upgrades, and think about high availability as you grow. Features such as clustering, multi-tenancy controls, and vector or hybrid search differ between the two and evolve quickly, so check current documentation against your requirements instead of relying on a feature table from last year.

Option 3: Hosted search (Algolia and similar services)

Hosted platforms like Algolia remove the operational burden. You send records to their API, configure relevance in a dashboard, and use their front-end libraries. They typically provide analytics on what users search for, A/B testing for ranking changes, and global infrastructure for low latency.

The main consideration is pricing. Hosted services usually charge based on the number of records and search requests, so a product with heavy autocomplete traffic can find the bill growing faster than expected. For example, a catalogue that triggers a search request on every keystroke could multiply your request count several times over compared with search-on-submit. Always model costs for realistic traffic before committing, and check the vendor's current pricing page.

Option 4: Larger engines (Elasticsearch and OpenSearch)

When you need complex aggregations, log analytics, or very large-scale distributed search, engines in the Elasticsearch family remain powerful. They are also heavier to operate and tune. For most startups building product search, they are more than needed on day one, though they can be the right choice if your team already has the expertise or if your needs include advanced analytics alongside search.

A real-world example: a niche marketplace growing its catalogue

Consider a hypothetical marketplace for handmade furniture. At launch it has a few hundred listings, and PostgreSQL full-text search is enough. Buyers search for "oak table" and get sensible results.

As the catalogue grows to tens of thousands of listings, problems appear. Shoppers type "walnt bookcse" and get nothing. They want to filter by material, price range, and delivery time, and see counts next to each filter. The team notices that search queries are slowing down the main database during sales events.

At this point, the team introduces a dedicated engine. They index listings through a background job triggered whenever a listing changes, keep Postgres as the source of truth, add synonyms (for example "couch" and "sofa"), and boost items with good reviews and fast delivery. They keep the old Postgres search as a fallback for a few weeks while comparing results. The key lesson is that the migration is driven by evidence from users, not by fashion.

If your product also needs semantic matching, for example finding "something cosy for a small flat", you can add embeddings on top. Our comparison of vector databases like pgvector, Pinecone, and Weaviate explains the options for that layer.

How to choose: a step-by-step process

1. Define your search requirements. List typical queries, filters, languages, expected data size, and freshness needs.
2. Create a test set. Gather 30 to 50 real queries with the results you would consider correct, including misspellings and vague phrases.
3. Prototype with your database first. Measure where it falls short against your test set.
4. Trial two or three engines. Index a representative sample of your data into each and compare relevance, speed, and setup effort.
5. Estimate total cost. Include hosting or subscription fees, engineering time, and the cost of running and monitoring the service.
6. Design the indexing pipeline. Decide how changes flow from your database to the index, and how you will reindex from scratch.
7. Handle permissions. Ensure users only see results they are allowed to access, using filters at query time or separate indexes per tenant.
8. Launch with analytics. Track searches with no results, queries followed by no clicks, and top queries.
9. Iterate on relevance. Add synonyms, adjust ranking rules, and use the analytics to guide improvements.

Keeping the index in sync

The most common source of bugs in search is not the engine but the sync between your database and the index. A reliable approach looks like this:

• Treat the database as the single source of truth.
• On every create, update, or delete, publish an event or enqueue a job that updates the index.
• Make index updates idempotent so retrying a failed job is safe.
• Run a scheduled full reindex, ideally into a new index that you swap in atomically, to correct any drift.
• Monitor lag and failure counts, and alert when the index falls behind.

If you manage content through a CMS, the same pattern applies to publishing events. Our overview of headless CMS architecture shows how content changes can drive downstream systems like search.

Relevance tuning that actually helps users

Most search improvements come from a handful of practical techniques:

• Searchable attributes with weights. A match in the title should count more than a match in the description.
• Synonyms and abbreviations. Map the words your customers use to the words your catalogue uses.
• Business ranking signals. Popularity, rating, stock availability, and recency can break ties between equally relevant results.
• Typo tolerance settings. Allow more flexibility for longer words and less for short ones to avoid odd matches.
• Zero-result handling. Suggest alternatives, show popular items, or relax filters instead of presenting a blank page.
• Language support. If your audience searches in several languages, test tokenisation for each, including mixed-script input.

Performance and front-end experience

A fast engine can still deliver a slow experience if the front end is careless. Debounce keystrokes so you are not firing a request on every character, cache recent queries, show a skeleton or previous results while loading, and make sure the interface is accessible with keyboard navigation and screen reader labels. If search is central to your site, check that it does not harm your page speed. Our web development team builds these interfaces with performance budgets from the start.

Key benefits of getting search right

• Higher conversion. Users who find what they need quickly are more likely to buy, sign up, or continue using your product.
• Lower support load. Good in-app search reduces "where do I find...?" questions.
• Insights into demand. Search queries reveal what users want and what you do not yet offer.
• Scalability. A dedicated engine keeps search fast without burdening your primary database.
• Better product experience. Features like filters, suggestions, and instant results make a product feel polished.

Conclusion

There is no universally best search engine, only the best fit for your data, budget, and team. Begin with what your database offers, and move to Typesense or Meilisearch when you need instant, typo-tolerant, faceted search with predictable cost. Choose a hosted service like Algolia when you value speed to market and strong tooling, and model its pricing carefully. Whatever you pick, invest in the indexing pipeline, permissions, and analytics, because that is where search succeeds or fails in practice.

If you would like help evaluating options against your own data and designing a search experience that fits your product, our team can prototype and benchmark candidates with you before you commit.

Frequently Asked Questions

Do I need a dedicated search engine for my web app?

Not always. For small datasets and simple keyword lookups, your database's built-in full-text search may be enough. A dedicated engine becomes valuable when you need typo tolerance, instant results as users type, faceted filtering, ranking control, or fast search across large catalogues.

What is the difference between Typesense and Meilisearch?

Both are open-source search engines focused on fast, typo-tolerant, developer-friendly search. They differ in architecture details, clustering and high-availability options, filtering and ranking features, and licensing and hosting models. The best approach is to test both with a sample of your own data and queries.

Is Algolia worth the price for a startup?

Algolia is a mature hosted service with strong tooling, analytics, and relevance features, which saves engineering time. The cost can grow with search volume and records, so estimate your usage before committing. Many startups start hosted for speed, then revisit the decision as traffic grows.

How do I keep my search index in sync with my database?

Treat the database as the source of truth and push changes to the index through events: on create, update, or delete, enqueue a job that updates the search record. Add a periodic full reindex as a safety net, and monitor for drift between the two.

Can I combine keyword search with AI or vector search?

Yes. Hybrid search blends keyword matching with semantic similarity, which helps when users describe what they want in different words than your content uses. Several modern engines and databases support both, so you can often add semantic search without replacing your existing setup.