MARC21-aware retrieval
Defined title, author, subject and ISBN profiles; whole-field matching; ISBN normalization; supported native facets with pagination; and Latin diacritic folding so accented and unaccented query spellings can match.
RustSearch 0.6.0 release candidate
Native Rust + Tantivy search for Koha. Explore your catalog with relevance-ranked results, facets, and connected authorities.
Download the KPZ Release notes SHA-256 checksum · Setup, migration and limits · Optional OpenSearch API & Swagger · Updating RustSearch
INTRODUCING RUSTSEARCH Bounded performance update
Koha search.
Written in Rust.
Your library’s catalog deserves a focused engine.
RustSearch brings native Rust and Tantivy to Koha: MARC21-aware indexing, relevance-ranked results, native facets, and connected authorities. Built by Lightwave Library, with a clear path from evidence to adoption.
THE SEARCH PATH01 / NATIVE
Your Koha catalogStaff interface + OPAC
Perl adaptervalidated native request
LIGHTWAVE LIBRARY
RustSearch
Rust service · Tantivy indexes
BibliographyRecords & facets
AuthoritiesPreferred & alternate
LinksNative usage lookup
One selected engine. Native execution.
Architecture illustration. Existing Koha and database services remain part of the system.
70,410Indexed titles in the benchmark catalog
5Workloads in the latest three-engine comparison
540Timing samples in the latest tuning follow-up
Evidence snapshot · October 2026 PURPOSE-BUILT FOR LIBRARY SEARCH
A native core.
A familiar catalog.
The search engine changes. Koha continues to supply the bibliographic records and holdings your staff and patrons use.
Download the technical briefAuthorities, connected
Preferred and alternate heading profiles, native authority-ID usage queries, and a dedicated link index. Duplicate matching has passed isolated installed-Koha checks in the candidate.
View the validated scope →Explicit search ownership
When RustSearch is selected, supported searches execute in Rust. Native routing keeps the selected engine responsible for the search, with no automatic fallback to another engine.
Updates, with a way back
Upgrade in place without uninstalling. The guided SSH updater builds and tests the engine, backs up files, pauses indexing for the switch, installs matching components and verifies the result. Validation failures trigger rollback; index migrations are handled separately.
Configuration confidence
A green Normal indicator checks 10 Koha integration files by size and SHA-256 fingerprint. If those files change, the plugin highlights the change and offers an administrator-controlled repair for compatible integration changes, with protected backups and validation.
MARC advice, ready to copy
Recommend Fix prepares a prompt with the record’s MARC text and indexing diagnostic. Copy it into your preferred AI chat for suggested corrections, then review the advice before editing. Records stay unchanged, and nothing is sent automatically.
THREE ENGINES. DIFFERENT TRADEOFFS.
Choose the architecture
that fits your library.
Zebra and Elasticsearch are established Koha options. RustSearch introduces a focused native alternative, with its current pilot scope made explicit.
| What matters | LIGHTWAVE LIBRARYRustSearch Development pilot | INDEX DATAZebra | ELASTICElasticsearch |
|---|---|---|---|
| Search foundation | Rust + TantivyA native compiled search service. | Structured-record enginePurpose-built indexing and retrieval for formats including MARC and XML. [1] | Java + LuceneA JVM search service built around Lucene indexes. [2] |
| Runtime footprint | No JVM required by the backendKoha adapters communicate with a loopback Rust service. Existing Koha/DB services remain. | Zebra server + Koha integrationStructured queries and access through the Z39.50 ecosystem. [1] | Elasticsearch service + JVMDeployment also involves cluster, index and shard settings. Single-node setups are possible. [2] |
| Relevance scoring | Tantivy BM25RustSearch uses BM25 term scoring for supported relevance-ranked queries. | Engine-specific scoringZebra supports ranked retrieval; its scoring behavior is configured for the Koha profile. [1] | Lucene relevance scoringElasticsearch uses Lucene scoring, including BM25 by default for standard similarity. [2] |
| Catalog model | Defined MARC21 profilesBibliography, authority and link indexes, with native supported facets, normalized ISBN forms and Latin diacritic folding. | MARC/XML indexingStructured-record support with configurable indexing and exact Boolean or ranked queries. [1] | Document indexesKoha provides the integration and mappings; Lucene indexes underpin the shards. [3] [2] |
| Deployment focus | Single-node, library-focusedDistributed/federated search is outside the current release scope. | Library search infrastructureAn established option in Koha; behavior depends on local mappings and configuration. [3] | Distributed search capabilitiesNodes, shards and replicas support distribution and resilience. [2] |
| Koha readiness | Controlled v0.6.0 pilotKoha 26.05.04 baseline tested. Full query/workflow parity and larger-scale acceptance remain open. | Established Koha backendValidate required behavior against your Koha version and indexing definitions. [3] | Established Koha backendValidate required behavior against your Koha version and mappings. [3] |
| Measured head-to-head results | Same-host three-engine comparisonNative adapter and shared Koha formatting times; hit counts and overlap reported. | Rebuilt catalog indexThe same requested workloads and shared record corpus are measured below. | Measured on the same test bedElasticsearch 8.19.23, native Koha adapters, and shared result formatting. |
Architecture and maturity remain separate from performance. The latest three-engine workloads appear below. Result semantics and ranking differences are disclosed.
MEASURED ON DOCUMENTED WORKLOADS
Engineering you
can inspect.
Explore the candidate’s local authority-duplicate measurements. Every timed response was checked for its expected count and IDs.
57ARM64 test executionsAcross four targets; shared tests repeat.
15Installed-Koha assertionsIsolated authority-duplicate probe.
21Local HTTP checksReal client routing and response validation.
RUSTSEARCH ONLYLocal x86-64 · Release build
Authority duplicate lookup
46.57 ms
Median backend HTTP latency
10,000 authorities in one type
100100,000 authorities
Sampled p95: 50.94 msDownload CSV ↓
Synthetic, just-indexed data; one sequential client; nine timed trials. This is duplicate detection, not general catalog-query speed or an engine-to-engine comparison.
RUSTSEARCH · ZEBRA · ELASTICSEARCH
Three engines.
One measured test bed.
Explore the latest tuning follow-up: five workloads on the same catalog and ARM64 host. Switch workloads and timing layers to inspect the latest results.
DIRECT RUST QUERY PATH
90–96% lower latencyImmutable facet dictionaries are reused; matching documents and facet counts are computed fresh for every search. Repeated A/B runs returned identical responses.
FULL KOHA PATH
7–14% fasterMeasured keyword, title, author and accent queries improved against the earlier snapshot. Record loading and formatting still account for most elapsed time.
FOUR-CLIENT MIXED PROBE
2.89 vs 2.92 requests/sRustSearch versus Elasticsearch with shared Koha formatting. Forty requests per engine: a bounded comparison, not sustained production capacity.
The 90–96% figure measures loopback HTTP/JSON query time, excluding Koha. The 7–14% figure compares full-path medians with the earlier snapshot, so host and timing effects may contribute. No-match improved 46%. Native engines return different match sets; title and author searches still favor Elasticsearch. Read the tuning evidence ↓
The downloadable candidate includes the measured Rust defaults: facet dictionary caching enabled, one search thread, and request-local metadata prefetch. Fresh server setup builds this engine. Existing installations can use Configuration → Update RustSearch to check and apply a compatible update over SSH, with backups and rollback. Installation details ↓
Loading the latest published measurements.
Warm-cache medians and sampled p95, with rotating engine order and the same Koha result formatter. Matching terms can still produce different records because mappings and relevance differ.
Download latest results (CSV) ↓Read this run’s methodology ↓
Search + Koha formatting
Koha result formatting: saved full-path results
Previously measured October 30, 2026: search adapter plus Koha’s shared C4::Search::searchResults formatter. Values are median / p95 in milliseconds from the existing 20 trials per engine and workload. These are combined search and formatting times, not isolated formatter timings. Browser rendering and network travel are excluded. No new benchmarks were run.
| Workload | RustSearch | Zebra | Elasticsearch |
|---|---|---|---|
| Keyword dogs | 652.7 / 697.9 ms | 1293.7 / 1605.7 ms | 670.7 / 705.8 ms |
| Title dogs | 638.3 / 674.7 ms | 855.1 / 875.0 ms | 510.1 / 548.2 ms |
| Author bridwell | 688.2 / 783.3 ms | 821.6 / 857.9 ms | 553.2 / 589.0 ms |
| Accent cafe | 399.5 / 415.3 ms | 967.7 / 1045.1 ms | 589.7 / 621.9 ms |
| No match | 13.9 / 16.0 ms | 18.6 / 30.0 ms | 122.6 / 145.7 ms |
This panel checks for a newly published benchmark every 60 seconds. It displays timestamped test results, not live service telemetry or production capacity. Browser, page rendering, and network travel are outside these timings.
A CLEAR PICTURE OF THE PILOT
Progress with a paper trail.
Promising architecture deserves precise claims. Here is where RustSearch stands in the October 2026 development snapshot.
VALIDATED WITHIN THE TESTED SCOPE
Native capabilities with evidence
- Controlled catalog, facets, pagination and holdings checks
- Defined authority heading profiles and native Used-in links
- ARM64 candidate build and isolated duplicate-function acceptance
- Defined native profiles and integration checks
- Local HTTP routing and synthetic latency checks
- Scheduled 500-record batch and manual 1,000-record check passed
- 70,410-title catalog measurements and explicit Zebra comparison
DOCUMENTED BOUNDARIES
Know the supported profile
- Accepted advanced queries, limits, browse/scan and authority profiles are documented
- Custom MARC mappings require library-specific validation
- No automatic transliteration or unspaced CJK dictionary segmentation
- Arabic vowel marks remain significant; Latin accent folding is supported
- Measured workloads do not certify every production capacity or configuration
Benchmark methodology & current limitations
The October 2026 experiment used a local AMD Ryzen 7 7735U, 16 logical CPUs, Linux x86-64, and a release-build RustSearch candidate. One authority type held 100, 1,000, 10,000, 50,000 or 100,000 synthetic headings. A single sequential HTTP client ran one initial request followed by nine timed requests per query and corpus size. Counts and returned IDs were validated for every response.
The chart reports backend HTTP/JSON time, excluding Perl, Koha and database overhead. Data was freshly indexed; the first sample is not a cold-disk test. The paginated case uses offsets up to 10,000. With nine samples, sampled p95 should not be treated as production tail latency. At 100,000 authorities, the match case measured 510.98 ms median and 1003.24 ms sampled p95.
Duplicate matching currently scans the stored headings selected by authority type. Whole-process peak RSS reached about 1.5 GiB across incremental indexing and queries; this is not the memory allocation of a single search. Concurrent authority-search performance and agreed catalog latency budgets remain open. A bounded batch-aware worker is deployed on the AWS test host. A manual run reindexed 1,000 existing records in ten batches of 100 in 90.525 seconds (about 663 records/minute), with 1,000 successes and no retries. This included Koha shell/Perl startup and used a 300-second worker budget rather than the scheduled cadence. It is a small sequential sample, not a full reconciliation or concurrency benchmark; historical prior log rates were about 34–40 records/minute but were not measured in a controlled A/B run.
The duplicate candidate mirrors the installed Koha function’s lossy punctuation/zero-digit input filtering. Its tests do not prove exact equality of raw dates or arbitrary MARC frameworks. The installed-function probe used process-local factory, coverage and CLI overrides. The local HTTP tests used synthetic Koha database/context/MARC objects and a shortened test timeout. Neither substitutes for complete live browser and cataloguing acceptance.
Download the public measurement data →What does a pilot installation require?
The tested baseline is Koha 26.05.04 on ARM64 Linux. RustSearch integrates through search, query-builder and indexer adapters. A compatible plugin-engine integration patch may be required by the installed Koha version. Availability in your Administration settings should be verified, not assumed.
A scoped pilot includes matching native artifacts, indexing/queue coverage checks, backups, a rollback plan and acceptance of the library’s actual search workflows. The separate OPAC enable flag is distinct from the selected search engine. This page is not an automatic production installation or activation guide.
Do we need authority records?
No. Bibliographic titles, authors and subjects remain searchable without authority records. Unresolved authority identifiers are preserved in MARC and shown separately as warnings. Only verified local relationships enter the authority-link projection; real indexing and backend failures remain errors.
Can my library keep using Zebra or Elasticsearch?
Other engines remain independently selectable in Koha Administration. RustSearch’s strict routing does not automatically fall back to them when RustSearch is selected. The test platform has also been configured and validated with native Elasticsearch searches. The separately timestamped three-engine benchmarks above measure each native adapter independently.
Distributed/federated catalogs and Koha REST API investigation are deferred. Existing database-backed API contracts are preserved; this page does not promise a new Koha REST implementation.
FOR KOHA COMMUNITY TESTERS
One download.
A guided path forward.
Release candidate — for staging validation before production. Tested Koha 26.05.04/05 MARC21 integration, with native ARM64 and x86-64 builds. Setup checks the required plugin-engine interfaces and installs the backed-up integration on recognized stock Koha source; a version number alone is insufficient.
New installation
Upload and enable the KPZ, open Configuration, and follow its server setup guide over SSH. Required plugin-aware Koha search interfaces must be present; a version number alone does not supply them. SELECT RUSTSEARCH IN SEARCHENGINE to use the current index. Pending updates and record errors remain visible but do not block searches.
Existing installation
Check the index schema before replacing anything. Schema-6 installations require a separate schema-7 candidate and the guarded migration workflow; the ordinary updater refuses incompatible changes. Preserve the matching old runtime and indexes for recovery. A KPZ upload alone is not a migration.
Installation, update and recovery notes ↓ · MIT license ↓
Multiple Koha instances
Run one setup command for the instances that want RustSearch. Normal password-protected sudo is supported; setup prompts when needed. Discover with --list-instances, then select with --instances central branch mobile. Setup installs each selected tenant’s plugin, engine, private indexes and workers and assigns an available loopback port. Reruns reuse existing assignments. Authority records are optional for bibliographic search; unresolved authority links are shown as warnings without changing MARC. Each tenant keeps its own SEARCHENGINE selection. Setup validates and enables OPAC independently of indexing completion.
BUILD THE NEXT CHAPTER OF LIBRARY SEARCH
Explore RustSearch
with your library in mind.
Discuss a controlled pilot, your catalog’s requirements, and the evidence needed for adoption.
Download release candidate Candidate notes & setup requirements ↓View release status →Talk to Lightwave Library Get the technical brief ↓Release candidate · Validate on staging before production
Technical references
Comparison facts come from the vendors and Koha documentation; RustSearch claims come from the project’s October 2026 validation snapshot.