search-index: a persistent full-text search library for the browser and Node.js

What search-index solves, and for whom

Most full-text search is a server round trip. You type, the request goes out, a remote engine answers, and if the connection drops the feature disappears. search-index inverts that: the index lives where the application runs, in the browser or in a Node.js process, and the README describes the library as "network resilient, persistent full-text search". Persistence is the second half of the promise. An index built in one session is still there in the next, which is what separates this from an in-memory filter over an array.

The audience is narrow and specific. If you are building an offline-first application, a documentation viewer, a desktop wrapper around web technology, or a prototype that should not require a search cluster, this is the shape you want. The package keywords list "search", "offline" and "front-end", and the repository topics include "offline-first", which matches the README's framing. If you are building a multi-tenant search backend with per-field boosting, faceting and analytics, this is the wrong tool, and the rest of this article says why.

The PUT and QUERY mechanism

The public surface is deliberately small. The README's quick start shows a class imported from the package, constructed with an options object, which returns two functions. PUT writes documents into the index. QUERY reads them back. There is no separate schema declaration step in the example, no mapping file, no analyzer configuration shown.

import { SearchIndex } from 'search-index' 

// initialize an index
const { PUT, QUERY } = new SearchIndex(options)

// add documents to the index
await PUT(documents)

// read documents from the index
const results = await QUERY(query)

Both calls are asynchronous, which matters: indexing is not a synchronous array push, and the persistence layer is doing work between the call and the resolution. The package.json points at two different entry points, and this is the most interesting architectural detail in the repository. The "main" field is src/entrypoints/classiclevel.js, the Node entry point. The "browser" field is src/entrypoints/browserlevel.js. Both names end in "level", which tells you the storage layer is a Level-style key-value store, with different backends selected per environment. That is how the same API persists in a browser and on a server without the caller choosing a database.

The practical consequence is that document size and index size are bounded by whatever the underlying key-value store can hold in that environment. The README does not document those limits, and it does not document what happens when a PUT fails partway through a batch.

Installing search-index and running a first query

The package is published on npm as search-index. The README does not include an install command, but the npm badge and the package name make the source unambiguous, and the package is ESM: package.json sets "type": "module", so an import statement is the expected form rather than require.

npm install search-index

The engines field sets the floor at Node 22, so check your runtime before anything else.

node -v

If that prints a version below 22, the package's declared engine requirement is not met. Once installed, the smallest useful program mirrors the quick start: construct an index, put an array of documents, query it. The README does not show the shape of a document or the shape of a query object, so those details have to come from docs/API.md in the repository. That is the first place to look after the quick start, because the four-line example tells you the call sequence but not the data contract.

The repository also ships a browser demo, linked from the README as a CodeSandbox project with its source in a separate repository, search-index-demo. For browser use, the "browser" field in package.json routes the import to the browser entry point, so the same import line resolves differently depending on the bundler target.

Where search-index falls short

The README is thin in ways that will cost you time. It documents the four-call shape and links to docs/API.md and docs/FAQ.md, but the front page itself does not describe document structure, query syntax, index options, or the semantics of the options object passed to the constructor. You cannot evaluate relevance behaviour from the README alone.

Failure handling is the sharper gap. PUT is asynchronous and writes into a persistent store, but the README does not document rollback, partial-write behaviour, or how to recover an index that was interrupted mid-batch. If your application writes documents continuously, that is a real question the documentation does not answer.

The scale ceiling is structural rather than a bug. A local key-value index in a browser tab or a single Node process has no sharding, no replication, no distributed scoring, and no separate query service to absorb load. The README makes no claims about index size or query latency, and nothing in the repository suggests benchmarks. Treat it as a single-node index and plan accordingly. If your corpus is large enough that you are asking about memory ceilings, you have already outgrown the design.

search-index compared with a server-side engine

The obvious comparison is a server-side engine such as Elasticsearch. The difference is not features, it is topology. Elasticsearch runs as a separate service: documents are shipped to it over HTTP, the index lives on that cluster, and every query is a network call. That buys distributed storage, replication, aggregations and a query DSL, and it costs you an operational dependency and a network hop on every search.

search-index keeps the index inside the process that needs it. There is no service to run and no request to make, which is exactly why the README calls it network resilient: with no network in the path, there is nothing to lose. The trade is everything the cluster provides. No replication, no sharding, no aggregation framework, no cluster monitoring. A second comparison is a plain in-memory filter over an array, which is simpler still but does not persist and does not build an inverted index, so it degrades as the corpus grows in a way a real index does not. search-index sits between those two: more durable than an array filter, far less capable than a search cluster.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-13, three days before this writing. The most recent release listed is v6.0.2 from 2026-08-14, preceded by v6.0.0 in March 2025 and v5.1.3 in September 2024. The cadence is irregular rather than continuous, and the jump from 5.x to 6.x is a major version, so anyone on 5.x should read the release notes before upgrading rather than assuming a drop-in.

The package is ESM-only in practice: "type": "module" is set in package.json, and the exports are import-based. A CommonJS codebase will need a wrapper or a build step. The Node engine floor of 22 is also an upgrade constraint, since it rules out older runtimes regardless of what the library itself does.

The licence is MIT, stated in package.json and present as a LICENSE file at the repository root. That is a permissive licence, but it says nothing about the licences of the storage backends the entry points pull in, and nothing here is legal advice: check the dependency licences yourself if that matters to your organisation.

Editorial conclusion

search-index fits products that need offline-capable search inside a browser or a Node process: note-taking apps, documentation sites, kiosk software, and prototypes where standing up a search server is overkill. It does not fit teams that need relevance tuning at scale, cross-node replication, or an analytics layer over query traffic; for those, a server-side engine is the right shape. Before committing, check the API document at docs/API.md for the exact QUERY syntax and index options, since the README shows only the four-call shape, and confirm your runtime is Node 22 or newer, because package.json sets that floor.

Frequently asked questions

Official sources

1. fergiemcdowall/search-index on GitHub
2. Issues
3. License: MIT
4. README
5. Releases