Six search options, four genuinely different briefs — pick by the workload, not the brochure
Algolia, Typesense, Meilisearch, Pagefind, Elasticsearch, Postgres FTS. The choice depends on whether search is your protagonist, your storefront sidekick, or just a feature on a static site.
READ THE FULL COMPARISONThe options, ranked by the workload that picks each one
Algolia
When the team needs a managed search that just works
Hosted, polished SDKs, instant-search UI components, faceted search out of the box. Most expensive by a wide margin once you cross 1M records, but the operational overhead is near zero. Default for funded teams that want to stop thinking about search.
Read the take →Typesense
Algolia's open-source equal
Open source, self-hostable, drop-in replacement for Algolia's API on most workloads. Cloud option if you want managed. The right call for cost-sensitive teams with the operations bandwidth to host it (or pay for Typesense Cloud).
Read the take →Meilisearch
Search-as-an-API for product teams
Open source, fast typo tolerance, simpler config than Elastic. Smaller community than Typesense but a cleaner first-run experience. Right call for product-search on storefronts.
Read the take →Pagefind
When the site is static and you want zero infrastructure
Static-site search — index runs at build, search is pure WASM in the browser. No backend. The right call for documentation, blogs, and content sites under ~25k pages where adding any infrastructure is overhead.
Read the take →Elasticsearch / OpenSearch
When the workload is more than search
Full-blown distributed search engine. Logs, analytics, vector search, faceting — handles workloads the others cannot. Operational complexity is real. Right call for teams already running it for adjacent reasons.
Read the take →Postgres full-text + pgvector
When you already have Postgres and want to keep using it
Full-text and vector search inside the database you already run. No new service, no sync. Right call for sites under a few million rows or where keeping the data layer simple beats raw search performance.
Read the take →The decision in one sentence
Pick Pagefind if your site is static and under 25k pages and you want zero infrastructure. Pick Algolia if budget is not the constraint and you want managed peace of mind. Pick Typesense or Meilisearch if you want Algolia capability at a fraction of the cost and have the operations bandwidth (or pay for cloud). Pick Elasticsearch / OpenSearch only when search is one of several heavy workloads on the same cluster. Pick Postgres FTS + pgvector when you already have Postgres and adding a service is overhead.
The supporting comparisons
- Search infrastructure 2026: Algolia, Typesense, Meilisearch, PagefindThe pillar comparison post — production numbers, pricing, when to pick each.
- Vector databases 2026: pgvector, Pinecone, Weaviate, Qdrant, ChromaWhen search becomes semantic — the vector-search adjacency.
- Algolia vs Typesense — the open-source migration pathThe cost / control tradeoff for teams running Algolia at scale.
The full directory of 12 search engines
This hub is the editorial top-5. The full directory at /search/ covers 12 engines across 5 categories (hosted SaaS / open source / embedded / database-native / AI-aware), filterable by pricing, vector support, and edge readiness — including the niche options the top-5 cuts: OpenSearch, MongoDB Atlas Search, Postgres FTS, Lunr, Manticore, Marqo, Vespa.
When your project is ready, the conversation is short
If search is the bottleneck on your storefront or directory, the right starting place is a quick audit of where the user is failing — typo tolerance, faceting, latency.