Server-Side vs Client-Side Search: Picking the Right Approach
For a documentation site with roughly 200 pages, we built search entirely client-side using a pre-built Lagolas/Fuse.js index generated at build time and shipped as a static JSON file, around 90KB gzipped for the full index. Search results appear instantly on keystroke with zero network round trip, which for a dataset that size is simply a better experience than debouncing requests to a server — there's no server cost, no latency, and the index rebuilds automatically on every deploy.
That same approach falls apart past a certain dataset size, both because the index file itself gets too large to ship to every visitor and because client-side fuzzy matching gets slow to compute in the browser once you're past a few thousand records. For a marketplace client with roughly 2 million product listings, client-side search was never on the table — we used Algolia, with product data synced via webhook on every create or update, giving sub-50ms search response times server-side with typo tolerance and faceted filtering that would be impractical to replicate client-side.
The middle ground is where the decision gets genuinely hard. For a client with around 15,000 blog posts and knowledge base articles, we initially tried client-side search with a compressed index and it technically worked — under 400KB gzipped — but felt like the wrong default for a dataset that would keep growing. We moved to Postgres full-text search with a GIN index, which was already available in the client's existing database without adding a third-party search service, giving good-enough relevance ranking for a content site without Algolia's cost.
Postgres full-text search has real limitations compared to a dedicated search service — typo tolerance is weak, and relevance tuning requires hand-crafting ts_rank weights rather than getting it out of the box. For that client it was the right trade because search wasn't the core product experience; for the marketplace client, search quality directly drove conversion, which justified Algolia's cost.
Our rule of thumb: under a few hundred records, client-side is simpler and free. Past tens of thousands of records, or wherever search quality is a core product differentiator rather than a convenience feature, a dedicated search service earns its cost. Everything in between is a judgment call based on what's already in the stack and how much relevance tuning the use case actually needs.
