Tantivy is a search engine library, not a search server, and that changes the comparison

A crate rather than a server, which is the whole framing

The most useful thing in the README is the sentence that tells you what Tantivy is not. It says Tantivy is closer to Apache Lucene than to Elasticsearch or Apache Solr, because it is not an off-the-shelf search engine server but a crate you use to build one, and that the design is strongly inspired by Lucene.

That distinction matters for every decision that follows. There is no process to deploy, no REST endpoint to point a browser at, no cluster to form. You add a dependency and construct an index inside your own program. `Cargo.toml` describes the package with the categories database-implementations and data-structures, which is a fair summary.

The same framing appears in the non-features section, which states that distributed search is out of scope and redirects anyone who needs it to Quickwit, the distributed search engine the maintainers build on top of Tantivy.

Building from source with cargo test

The contributing section gives the checkout, which is also the quickest way to confirm your toolchain is fine:

git clone https://github.com/quickwit-oss/tantivy.git
cd tantivy
cargo test

Tantivy compiles on stable Rust and supports Linux, macOS and Windows. `Cargo.toml` sets edition 2021 with a `rust-version` of 1.87, so the floor is higher than a bare stable channel, which is worth knowing if you are on an older pinned toolchain.

The repository tree shows the internal split, and it explains a good deal about the design: `columnar/` handles the column-oriented storage, `stacker/` the postings and term dictionary machinery, `sstable/` the sorted string table format, `bitpacker/` integer compression, `query-grammar/` the query parser, `tokenizer-api/` the tokenizer interface extracted into its own crate, and `examples/` holds a long list of runnable programs covering everything from basic search to faceted search, fuzzy search and custom collectors. `benches/` and `ARCHITECTURE.md` are there for anyone reading the source.

BM25 scoring, the query language, and phrase search

Scoring is BM25, which the README notes is the same as Lucene's. That is the single most consequential compatibility fact in the project: query semantics and relevance behaviour transfer from a Lucene-based system with less translation than you would get switching to a different scoring model.

The query language is described as natural, with examples such as `(michael AND jackson) OR "king of pop"`, and phrase queries search for `"michael jackson"` as a unit. Range queries, faceted search and a JSON field are also listed.

The feature list is long enough to be worth skimming in full rather than trusting a summary. Fast fields cover single valued and multivalued u64, i64 and f64 as well as `&[u8]`, which the README calls the equivalent of Lucene's doc values, and they are what make filtering and sorting cheap without touching the full text postings. Fields cover text, i64, u64, f64, dates, ip, bool and hierarchical facets. The document store can be compressed with LZ4, Zstd or left uncompressed. There is an aggregation collector with histogram, range buckets, average and stats metrics, plus a searcher warmer API.

Why startup time under ten milliseconds matters

The README lists tiny startup time, under ten milliseconds, and says it is perfect for command-line tools. That claim is a design constraint more than a feature: a CLI tool that has to boot a JVM or a search server before answering a query is unpleasant to use, and a Rust library with no daemon can answer immediately.

Incremental and multithreaded indexing are both supported, and the README gives a concrete data point for the latter, noting that indexing English Wikipedia takes under three minutes on the maintainer's desktop. Storage is memory-mapped, and integer compression uses SIMD when the CPU has the SSE2 instruction set.

`tantivy-cli` is referenced as a command-line interface built for creating a search engine, indexing documents and querying either from the CLI or through a small server with a REST API, with a tutorial that walks through a Wikipedia search engine. The README also points to a simple search example rendered on the project's documentation site, and to the docs.rs reference for the last released version. If you want to evaluate the API without writing anything, the examples directory is the shortest path.

Tokenizers, and third-party support for languages beyond Latin

The tokenizer is configurable and supports stemming for 17 Latin languages out of the box. Everything else is delegated to other crates, and the README names them: `tantivy-jieba` and `cang-jie` for Chinese, `lindera` and `Vaporetto` plus `tantivy-tokenizer-tiny-segmenter` for Japanese, and `lindera` with `lindera-ko-dic-builder` for Korean.

The `frostem` dependency in `Cargo.toml` carries feature flags for Arabic, Danish, Dutch, English, Finnish, French, German, Greek, Hungarian, Italian, Norwegian, Portuguese, Romanian, Russian, Spanish, Swedish, Tamil and Turkish, which lines up with the 17 languages the README mentions.

If you are implementing your own tokenizer, the contributing section says to depend on the separate `tantivy-tokenizer-api` crate rather than against internals. Extracting that interface into its own crate is a good sign for a project you might hold a custom analyzer behind.

Benchmarks, and what the project asks of you instead

There is a published benchmark that breaks down performance by query type and collection, hosted with its source in a separate search-benchmark-game repository. The README attaches a warning to it that your mileage will vary depending on the nature of the queries and their load, which is the honest framing: benchmark numbers for a search engine say little without the shape of the corpus and the query mix.

The rest of the README asks for support in ordinary ways: report bugs, write a blog post, ask questions that improve the documentation, contribute code through the GitHub pull request workflow with a referenced ticket and a comprehensive commit message, and update `CHANGELOG.md` with a contribution. There is a Discord link and an email address listed for the maintainer.

One more practical detail for anyone evaluating the API: the README's own FAQ points to `tantivy-py` for Python and `tantiny` for Ruby, and notes that other bindings exist on GitHub but may be less maintained. Release notes for 0.26.1 and 0.25.0 show the work landing in areas you would expect from a search library, regex query grammar support, query deduplication, exists-query optimization for many dynamic columns, and moving the crate to edition 2024.

Editorial conclusion

Tantivy is the right crate when the search index belongs to a single process: a CLI tool that should start instantly, a service that indexes its own documents, an application that needs faceted search without a second system to operate. The README is direct that it is closer to Lucene than to Elasticsearch, and the feature list backs that up, since the non-features section states plainly that distributed search is out of scope. If your requirement includes sharding, replication or a query interface that other services can call, the project points you to Quickwit, built on top of Tantivy. `Cargo.toml` reports version `0.27.0` with a minimum Rust of 1.87, and the last push was on 2026-09-21, so the crate is still moving.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. quickwit-oss/tantivy on GitHub
4. README
5. Releases