Client-Side Search & Database Options for Static Sites — Master Report

1. Executive summary

A static site has no server to run queries, so every option either ships an index or database to the browser and queries it in memory, or queries a file on the static host in small pieces (a chunked index, or HTTP Range requests into a single file).

Combining tools is normal. A common pattern is Pagefind for site-wide search plus MiniSearch or SQLite for one data-heavy page.

2. Architectural families

3. Master comparison table

Versions are from the npm registry and sizes are measured gzip, both as of 2026-10-23. "Fixed cost" is the library or runtime only; your index or data is extra and is usually the bigger number for families B, C and G.

4. Tool-by-tool findings

4.1 Pagefind

What it is. A Rust CLI that runs after your generator, crawls the built HTML, and writes a pagefind/ folder containing a fragmented index, a JS/WASM search API, and optional UI.

How it works. On first search the client loads a small metadata file, around 10–30 kB, that maps term prefixes to index chunks. Then it fetches only the chunks matching the query terms. The project states a 10,000-page site stays under ~300 kB of total transfer, usually nearer 100 kB.

Strengths

• Framework-agnostic, because it only needs HTML output. It's distributed as a standalone binary, on npm, and as Python bindings, so Hugo users don't need Node.
• data-pagefind-body, data-pagefind-ignore, data-pagefind-filter and data-pagefind-meta control what gets indexed and exposed.
• Multilingual with zero config, faceted filters, and multi-site search.
• New in 1.5: a web-component search UI (the older Default and Modular UIs still work), improved ranking, diacritics support, automatic CJK segmentation, search in a Web Worker, smaller indexes, and faster indexing. 1.5.2 fixed a musl-allocator slowdown in Linux builds.
• It's the default search in Astro Starlight, which is a strong adoption signal.

Weaknesses

• It doesn't run in the dev server. The index exists only after a real build, so test with build && preview.
• Matching is prefix plus stemming, not true edit-distance fuzzy. A typo that changes the term prefix finds nothing.
• It only indexes rendered pages, so it can't query records that never become HTML.
• Bundlers can choke on its runtime import (a known Next.js issue, "Failed to load Pagefind metadata"). Use a bundler-ignored dynamic import.
• The index is tied to the build. Any content or layout change needs the post-build step in CI.

Best for: blogs, docs, knowledge bases, i.e. "search the pages".

4.2 MiniSearch

What it is. A tiny, dependency-free, in-memory full-text engine built on a radix tree and an inverted index.

Strengths

• BM25-style ranking, prefix search, fuzzy search by edit distance, field boosting and restriction, and autoSuggest.
• Pluggable tokenizer, term processing and field extraction, which helps with non-English text.
• Build the index at compile time, then load it in the browser with MiniSearch.loadJSON.
• Supports adding, removing and replacing documents, which suits dynamic data.
• Query time depends on matching postings, not total document count, so queries take under a millisecond for thousands of records.

Weaknesses

• The whole index downloads up front and lives in memory. That's fine for a few thousand records but gets costly for large corpora with long bodies.
• No UI and no chunking.

Best for: catalogs, recipe or glossary collections, and small-to-medium content sites where you want ranking control.

4.3 Fuse.js

What it is. A zero-dependency approximate string matcher using the Bitap algorithm.

Strengths

• The best typo tolerance on short strings: names, titles, tags, commands.
• Weighted keys, extended search syntax (exact, prefix, inverse), logical queries, and match highlighting.
• Actively developed: v7.2 added Fuse.use() plugins, v7.3 a static Fuse.match(), v7.4 Web Worker search with typed entry points, and 7.5.0 shipped July 2026.

Weaknesses

• Not a full-text engine. There's no inverted index, and each query is O(N × string length), so latency grows linearly with the data.
• It gives noisy, CPU-heavy results on long article bodies.

Best for: command palettes and quick filters over a few hundred to a few thousand short items.

4.4 FlexSearch

What it is. A full-text library built for raw throughput.

Strengths

• Consistently near the top of JS search benchmarks.
• The v0.8 rewrite added persistent indexes (IndexedDB in the browser; Redis, SQLite, Postgres, MongoDB and ClickHouse on servers), worker indexes, export/import, a Resolver for boolean queries, and an Encoder class for language customization.
• Multiple builds: light is ~4.5 kB gz and bundle ~18 kB gz.

Weaknesses

• The API is complex and the 0.7 → 0.8 migration is non-trivial. Scoring is less transparent than BM25, and the docs are dense.

Best for: large in-browser datasets, and offline-first apps caching their index in IndexedDB.

4.5 Orama

What it is. A TypeScript search engine, formerly "Lyra", that runs in any JS runtime, with an optional hosted cloud.

Strengths

• The most built in: BM25, typo tolerance, facets, filters, sorting, grouping, geosearch.
• Vector and hybrid search via plugins, which is rare for a client-side library.
• Adopted by docs tooling: Fumadocs moved its built-in search from FlexSearch to Orama, and the Node.js docs use it too.

Weaknesses

• Bigger than MiniSearch or Fuse. Its "< 2 kB" marketing claim doesn't match the measured ~26 kB gz for the v3.1.18 core; third-party trackers report ~22–24 kB.
• The whole index lives in memory, and vector indexes make it heavier still.
• Some features point you toward the commercial cloud.

Best for: React/Next.js docs sites, faceted shop-like search, and semantic-search experiments.

4.6 SQLite in the browser

Build-time tips

1. Build the .sqlite file at site-build time with any language (Go, Python, a Hugo data pipeline), run VACUUM, and serve it as a static asset.
2. Because the whole file downloads, keep it small: drop unused columns, and consider splitting large datasets into per-section files that load on demand.
3. Use a cache-busting filename when the DB changes.

Caveats

• The WASM runtime (~335–406 kB gz) is the biggest fixed cost outside DuckDB and PGlite.
• OPFS persistence needs a Worker. The opfs VFS needs cross-origin isolation (COOP/COEP headers), which many static hosts can't set. The opfs-sahpool VFS avoids that requirement.
• Bundling the worker plus the .wasm file needs per-bundler configuration.
• The whole database lives in Worker memory. On mobile, a large DB can push the browser to kill the Worker, which forces a cold restart.

Best for: small-to-medium filterable, sortable catalogs, data journalism, "browse this dataset" pages, and offline-first tools.

4.7 DuckDB-WASM

An in-process analytical (OLAP) SQL engine. It reads Parquet, CSV, JSON and Arrow, either local or over HTTP. For Parquet it fetches the footer first, then only the referenced column chunks.

• Pros: fast vectorized aggregates over millions of rows, and remote Parquet over Range requests. Great for dashboards.
• Cons: measured ~7–9 MB gzip runtime, plus 1–3 MB per extension. It runs in memory with high RAM use (~100–300 MB is typical for real workloads), is slower than native, and isn't a search engine.
• Best for: interactive charts and data exploration, not site search.

4.8 hyparquet

A pure-JS, zero-dependency Parquet reader (~20 kB gz) built to read Parquet over HTTP with Range requests, so a Parquet file on static hosting can be read straight from the browser. It doesn't support SQL. You select columns and row ranges, then filter or aggregate in JS.

• Use it when you want DuckDB-style "only fetch what you need" reads of a Parquet file without the ~8 MB runtime, for example a table viewer or a chart over a few columns.
• Gotcha: cross-origin Range requests trigger CORS preflights. Host the file on the same origin, or configure OPTIONS and 206 responses with exposed range headers.

4.9 PGlite

Postgres compiled to WASM by ElectricSQL. Measured ~5.3 MB gz (3.4 MB WASM plus 1.9 MB data file). It supports pgvector, PostGIS and other extensions, and persists to IndexedDB or OPFS.

• Pros: the same SQL dialect as a server Postgres, and a good fit for local-first sync (ElectricSQL).
• Cons: heavy, and historically slower than SQLite WASM for simple workloads. Overkill for static search.

4.10 Client-side vector / semantic search

The pattern for static sites: compute document embeddings at build time, ship them as JSON or binary (or cache them in IndexedDB), and embed only the user's query in the browser. Transformers.js running a small model such as all-MiniLM-L6-v2 (384 dimensions) does the embedding.

• Libraries: Orama with its vector plugin (hybrid BM25 plus vector), client-vector-search (aimed at hundreds to thousands of vectors; HNSW is still on its roadmap), and altor-vec (a ~54 KB WASM vector index; its author reports ~0.6 ms p95 for 10k vectors).
• Cost: the embedding model download, typically tens of MB, usually dwarfs everything else. Lazy-load it, and consider hybrid search where keyword results show instantly and semantic results load later.

4.11 Others worth knowing

• staticseek: a lightweight full-text engine supporting all Unicode languages. It's niche but worth a look for CJK-heavy sites that don't use Pagefind.
• Hosted search (Algolia DocSearch, Typesense, Meilisearch): not static, but the usual escape hatch when you need analytics, synonyms or merchandising, or when the corpus outgrows client-side search. Starlight documents Algolia and Typesense plugins as alternatives to Pagefind.

5. Performance at a glance: a 10,000-page / ~30 MB text site (Rough guideline only)

Network-profile insight

Pagefind and the Range-request tools (DuckDB-WASM, hyparquet) swap one big download for many small requests. That works well on HTTP/2 or HTTP/3 multiplexing but suffers head-of-line blocking on HTTP/1.1. Every major static host (GitHub Pages, Netlify, Cloudflare Pages, Vercel) serves HTTP/2+, but check self-hosted nginx and Apache setups.

6. Charts

Scores are qualitative (1–10) and drawn from the findings above.

6.1 Setup effort vs. query power

6.2 Measured runtime download (kB, gzip, excluding your data)

Each gridline is 10× the one before it. On a normal scale the JS libraries would be invisible next to the WASM databases, which are one to three orders of magnitude heavier. Pagefind is left out because its cost is runtime plus index chunks, ~100–300 kB per search session.

6.3 Capability scores (1–10)

6.4 Decision flow

7. Framework integration

7.1 Compatibility matrix

7.2 Hugo

Hugo is a single Go binary with no JS runtime at build time.

• Pagefind fits best:

  hugo --minify
  pagefind --site public
  

• JSON-index libraries: add a JSON output format for the home page and an index.json template that ranges over .Site.RegularPages. Bundle the library with Hugo Pipes (js.Build, which uses esbuild). Fetch the index on search-box focus, not on page load.
• SQLite: generate the DB in a separate step (Go's modernc.org/sqlite, a Python script, etc.), apply the build tips from §4.6 (SQLite in the browser), and drop it into static/.

7.3 Svelte / SvelteKit

• Use @sveltejs/adapter-static and prerender every route.
• Hydration isolation: anything touching window or WASM goes inside onMount or a dynamic import(). Otherwise prerendering fails.
• Pagefind: run it on build/ after vite build, and load /pagefind/pagefind.js with a dynamic import inside onMount.
• MiniSearch/Orama: emit /search-index.json from a prerendered +server.js endpoint.
• SQLite/DuckDB: Vite's ?worker and ?url imports make this the smoothest framework for WASM. Wrap the Worker message interface in a Svelte store.

7.4 Next.js (App Router, static export)

• Set output: 'export' in next.config to get an out/ directory.
• Search components need 'use client'. Initialize engines in useEffect, because client-side routing doesn't re-run <script> tags.
• Pagefind: add "postbuild": "pagefind --site out" and load it with import(/* webpackIgnore: true */ '/pagefind/pagefind.js'). Community wrappers such as next-static-search and pagefind-react package this up.
• WASM: configure webpack/Turbopack to emit .wasm as a static asset, and never evaluate it during prerender.
• Orama is the path of least resistance for React docs (Fumadocs).
• With SSR or ISR instead of export, search can live in a route handler, but then the setup is no longer static.

7.5 Astro

• Starlight ships Pagefind by default with no config. Algolia DocSearch and Typesense are documented plugin alternatives.
• Plain Astro: use a Pagefind integration, or emit a JSON index from a static endpoint (src/pages/search.json.ts) for MiniSearch, Fuse or Orama, then hydrate a search island with client:idle or client:visible.

8. Recommendations by scenario

9. Practical gotchas

1. Measure the index, not just the library. A 6 kB library with a 4 MB index is a 4 MB feature. Only Pagefind, DuckDB/Parquet and hyparquet avoid an all-at-once download.
2. Prebuild indexes at compile time for MiniSearch, Fuse, FlexSearch and Orama, so users don't spend CPU on indexing.
3. Lazy-load search. Load the runtime and index on search-box focus, not on every page view.
4. Range requests need uncompressed, Range-capable hosting. GitHub Pages works. Some CDNs gzip on the fly and break Range requests. Cross-origin Range requests need CORS that exposes Content-Range, Accept-Ranges and Content-Length.
5. Prefer HTTP/2 or HTTP/3 for the many-small-requests tools (Pagefind, DuckDB-WASM, hyparquet).
6. CSP: the WASM tools (Pagefind, SQLite, DuckDB, PGlite) may need 'wasm-unsafe-eval'.
7. COOP/COEP: some SQLite OPFS modes and multithreaded WASM builds need cross-origin isolation headers, which many static hosts can't set. Pick a VFS that doesn't need them (e.g. opfs-sahpool).
8. Dev vs. production: Pagefind's index exists only after a build, so test with build && preview.
9. Index staleness: build-tied indexes (Pagefind, prebuilt SQLite or Parquet) must regenerate in CI on every content change. Use cache-busting filenames.
10. Worker memory: in-memory databases (SQLite, DuckDB, PGlite) can grow large, and mobile browsers may kill Workers. Handle re-initialization gracefully.
11. Privacy: every client-side option keeps queries on the visitor's device, unlike hosted search.
12. Re-check sizes and versions before committing. These numbers drift between releases.