I Tried 4 Search Engines So You Don't Have To

Here's the definitive guide to choosing between Orama, Pagefind, Meilisearch, and Google for your static site.

Pixel art of two knights clashing swords in a crowded arena under red skies.

I’ve implemented search four different ways on this blog. First with Orama, then tried Google Programmable Search, migrated to Meilisearch, and finally settled on Pagefind.

Each solution claims to be the “best,” but they solve fundamentally different problems. Here’s my honest comparison from the perspective of a design engineer running a small(ish) static site.

The Quick Breakdown

FeatureOrama (Open Source)PagefindMeilisearchGoogle Programmable
ArchitectureIn-Memory (Monolith)Static (Chunked)Server-BasedExternal API
Setup Complexity⭐ Very Easy⭐ Easy⭐⭐⭐ Moderate⭐⭐ Easy
Initial LoadHigh (Downloads full DB)Low (~5KB + Chunks)Low (API Call)Low (API Call)
Typo Tolerance✅ Excellent (Levenshtein)⚠️ Basic (Stemming/Prefix)✅✅ Industry Leading✅ Good
Server Cost$0$0$5-10/mo (VPS)$5/1000 queries
Best ForSmall Apps (<100 pages)Content Sites (Any Size)E-commerce / SaaSLegacy/Enterprise

1. Orama (Open Source)

Orama is a modern, in-memory search engine written in TypeScript. It’s designed to be the “SQLite of search”—running entirely inside the browser or on the edge.

The Good: It’s incredibly easy to set up. You feed it a JSON array, and it builds a highly optimized index that supports fuzzy matching, stemming, and even vector search (if you bring embeddings). The query performance is sub-millisecond because there’s no network latency—it’s all in RAM.

The Bad: The architecture is a bottleneck for content sites. Because Orama is in-memory, the browser must download the entire index before it can search.

You’re effectively forcing users to download your entire database just to search for one keyword.

Verdict: Use Orama for small documentation sites or client-side apps where the dataset is small and guaranteed to fit in memory.

2. Pagefind

Pagefind feels like it was built specifically to solve the bandwidth problem Orama creates. It’s a “static” search library that runs after your build process.

The Good: Pagefind splits your search index into thousands of tiny binary “chunks.” When a user searches for “React”, it only downloads the specific chunk containing “React”.

  • Bandwidth Efficient: It scales to 100,000 pages without bloating the initial page load.
  • Zero Config: It scrapes your HTML automatically. No schema definitions required.
  • Multi-Site: It can merge indexes from different domains (e.g., your blog and your docs).

The Bad: It trades precision for performance. Pagefind uses stemming and prefix matching, not true fuzzy logic.

  • Searching “running” finds “run”. (Stemming: ✅)
  • Searching “astor” finds “astro”. (Typo Tolerance: ❌)
  • Note: Pagefind will fallback to prefixes if no match is found, but it lacks the sophisticated Levenshtein distance algorithms of Orama.

Verdict: Use Pagefind for blogs, portfolios, and marketing sites. It’s the most scalable “static” option.

3. Meilisearch

Meilisearch is a production-grade search server built in Rust. It’s an open-source alternative to Algolia.

The Good: It’s powerful. It handles typos better than anything else I’ve tested. It supports complex faceted filtering (e.g., “Show items <$50 in Blue”), sorting, and even hybrid vector search (Semantic Search). Since it runs on a server, your client bundle is tiny, and updates happen in real-time via API without rebuilding your site.

The Bad: It breaks the “static” philosophy. You need a server.

  • You have to pay for a VPS ($5-10/mo).
  • You have to maintain Docker containers.
  • You have to secure API keys and set up rate limiting.
  • If the server crashes, your search dies.

Verdict: Use Meilisearch for E-commerce, SaaS dashboards, or dynamic apps where data changes frequently and faceted filtering is a requirement.

Google Programmable Search (formerly Custom Search Engine) seems like the obvious choice—Google already indexes your site, and their search is best-in-class. But the reality is disappointing.

The Good: It leverages Google’s actual search index. Setup is straightforward: create a search engine in Google’s console, get an API key, and call their JSON API. The search quality is excellent because it’s the same algorithm that powers google.com.

The Bad: The pricing model is brutal. You get 100 free queries per day. After that, it’s $5 per 1,000 queries. For a modest blog with 200 visitors doing 2 searches each, that’s ~$45/month.

Worse, indexing delays mean new content won’t appear in search for hours—or even days. You publish a post, but Google hasn’t crawled it yet. Meanwhile, Pagefind and Orama index at build time—instant availability.

You also have zero control over relevance tuning. No boosting title matches, no filtering by tags, no customizing fuzzy tolerance.

Verdict: Skip Google for static sites. You’re paying to search your own content with someone else’s crawler.

The Decision Matrix

Use Orama if:

  • You have <100 pages.
  • You need true typo tolerance.
  • You have zero budget ($0).

Use Pagefind if:

  • You have >100 pages.
  • You want a “set it and forget it” solution.
  • You care about initial page load speed.
  • This is what I use on this blog.

Use Meilisearch if:

  • You’re hosting a large dataset or documentation site.
  • You need complex filters (Tags + Date + Price).
  • You need real-time updates (no rebuilds).

Avoid Google Programmable Search if:

  • You have a personal blog or portfolio (the cost doesn’t justify it).
  • You publish frequently and need instant indexing.
  • You want control over relevance and ranking.

Conclusion

For 99% of static blogs, Pagefind is the correct choice. It respects the user’s bandwidth and requires zero maintenance.

Orama is fantastic technology, but its “load everything” architecture fights against the grain of web performance for larger content sites. Meilisearch is brilliant, but overkill for most cases.

Stick to Pagefind. Your lighthouse score will thank you.


What’s next?

This is part of a series of posts on implementing search for static sites:

All with practical examples from a real production blog.

Subscribe to my newsletter

I send out a newsletter every week, usually on Thursdays, that's it!

You'll get two emails initially—a confirmation link to verify your subscription, followed by a welcome message. Thanks for joining!

You can read all of my previous issues here

Related Posts.