SeekStorm: vector and lexical search in one Rust process
SeekStorm: vector & lexical search - in-process library & multi-tenancy server, in Rust.
At a glance
- What is it?
- SeekStorm ships as a Rust library and a multi-tenancy server, with separate native indexes for keyword and vector search. Here is what the repository documents, where the setup is thin, and who should look elsewhere.
- Who is it for?
- Adopt SeekStorm if you want lexical and vector search in one Rust process, either embedded as the seekstorm crate or behind the seekstorm_server REST API, and you are willing to read ARCHITECTURE.md before trusting the defaults. Skip it if you need a managed service with a support contract, or if you cannot pin a release because the README calls the project work in progress.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem SeekStorm solves: two search types, one process
Most search stacks end up running two systems: an inverted index for keyword relevance and a vector store for semantic similarity. SeekStorm's README states that it uses "two separate, first-class, native index architectures" for vector search and keyword search, and that these are "integrated at the query planner level." The pitch is that you do not bolt a vector layer onto a lexical engine, and you do not run two services. The audience is Rust teams building search into an application, and teams that want a self-hosted search server with an HTTP API rather than a hosted vendor. The repository is a Cargo workspace with three members: seekstorm (the library), seekstorm_server (the multi-tenancy server), and seekstorm_client (the Rust REST client). Clients also exist for Python, TypeScript, C#, and Java, plus an InstantSearch adapter that the README describes as a drop-in way to point an existing Algolia InstantSearch.js frontend at a SeekStorm backend.
How the two native indexes and the query planner fit together
The repository keeps its design notes outside the README: ARCHITECTURE.md, FACETED_SEARCH.md, and NGRAM_SEARCH.md sit at the top level. The README summarizes the split: an inverted index "optimized for lexical relevance" and an ANN index "optimized for vector similarity," with a query planner that exposes multiple QueryModes and decides how to combine the two. That is the mechanism to evaluate. A single query can be answered lexically, by vector similarity, or by a hybrid path, and the planner is the component that chooses. The README also lists faceted search, geo proximity search, result sorting, and query auto-completion as features, each with a blog post linked from the README. None of those details are in the README body itself, so anyone making an adoption decision should read ARCHITECTURE.md rather than the front page. The workspace Cargo.toml sets missing_docs = "warn" across the workspace, which suggests public items are expected to carry documentation, but that is a lint setting, not a guarantee about depth.
Installing the library and running a first query
The library is published on crates.io as seekstorm, and the README links its docs.rs page for API documentation. The crate name is the same as the workspace member directory. Add it to a Cargo project with:
[dependencies]
seekstorm = "3"The README shows the version badge pointing at 3.3.13, so pin whatever release you have reviewed rather than floating. The README does not include a copy-paste Rust example for creating an index and querying it; it points readers to docs.rs and to ARCHITECTURE.md. Treat docs.rs as the source of truth for the exact API surface before writing code.
For the server, the repository ships a Dockerfile that builds the workspace in release mode and runs the server binary with three arguments baked into the entrypoint:
ENTRYPOINT ["./seekstorm_server","local_ip=0.0.0.0","local_port=80","index_path=seekstorm_index"]That means a container built from this Dockerfile listens on port 80 and writes its index to a path called seekstorm_index inside the container. If you run it, mount a volume at that path or your index disappears with the container. The server is also published on crates.io as seekstorm_server and on Docker Hub as wolfgarbe/seekstorm_server, according to the README badges. The REST API documentation lives at seekstorm.github.io/documentation. The README does not document a configuration file format or an environment variable list for the server; the arguments shown in the Dockerfile entrypoint are the only configuration surface visible in the repository files.
Where SeekStorm is the wrong tool
The README says the project is "work in progress" and that the work started in 2015 with a Rust port in 2023 and open sourcing in 2024. Recent releases are frequent, with v3.3.13 on 2026-09-12 and v3.3.11 and v3.3.10 in the same month, and the last push to the repository was on 2026-09-12. That release cadence cuts both ways: fixes arrive quickly, and so do changes you may need to track. If your team cannot absorb version churn, this is a poor fit. Two other limits are visible in the repository. First, the README does not document rollback, backup, or index migration procedures, so operating the server in production means working that out yourself. Second, the Dockerfile runs the server as root (USER root) and binds port 80, which is convenient for a demo and awkward under a hardened container policy. If you need a managed service with an SLA, SeekStorm is not that; it is a library and a self-hosted server.
SeekStorm compared with Quickwit
Quickwit comes up in the same searches as SeekStorm, and the two solve different problems. Quickwit is a distributed search engine aimed at log and observability workloads, where you index large volumes of append-heavy data across multiple nodes and query it with a cluster. SeekStorm's README describes an in-process library and a multi-tenancy server; the emphasis is on embedding search in an application or serving many tenants from one server, with two native index types and a query planner that mixes lexical and vector retrieval. If your workload is hybrid semantic plus keyword search over application data, SeekStorm's design targets that directly. If your workload is terabytes of logs with a cluster to scale out, that is Quickwit's territory, and SeekStorm's README does not claim to cover it. The comparison is about query type and deployment shape, not about which engine is faster.
License, maintenance and upgrade cost
SeekStorm is licensed under Apache License 2.0, and the Dockerfile labels the image with org.opencontainers.image.licenses="Apache-2.0". Apache-2.0 permits commercial use and modification and includes an explicit patent grant; it also requires that you keep the license and notice files. One detail worth noting: the InstantSearch adapter is MIT licensed, not Apache-2.0, so that component carries different terms. This is a description of what the repository states, not legal advice; run your own review if the distinction matters to you. On maintenance, the last push was on 2026-09-12 and the repository is not archived, with three releases in the week before that. The practical upgrade cost comes from that pace: the README describes the project as work in progress, so pinning a specific version and reading the CHANGELOG.md before each bump is the cheap insurance. The workspace requires a recent Rust toolchain; the Dockerfile builds on rust:slim-bookworm, and the workspace Cargo.toml sets resolver = "3", which is a modern Cargo resolver.
Editorial conclusion
Adopt SeekStorm if you want lexical and vector search in one Rust process, either embedded as the seekstorm crate or behind the seekstorm_server REST API, and you are willing to read ARCHITECTURE.md before trusting the defaults. Skip it if you need a managed service with a support contract, or if you cannot pin a release because the README calls the project work in progress. Before committing, verify the query planner's behavior when a query mixes both modes, and check whether the Docker image's port 80 entrypoint fits your deployment.
Frequently asked questions
What is SeekStorm and what does it do?
SeekStorm is a Rust search project that provides vector and lexical search as both an in-process library and a multi-tenancy server. It uses two separate native index architectures, an inverted index for keyword relevance and an ANN index for vector similarity, combined by a query planner.
How do I install SeekStorm?
The library is on crates.io as seekstorm and the server as seekstorm_server, both linked from the README badges. The repository also includes a Dockerfile that builds the server and runs it with local_ip=0.0.0.0, local_port=80, and index_path=seekstorm_index.
Does SeekStorm support hybrid search?
Yes. The README states that SeekStorm uses two separate, first-class, native index architectures for vector search and keyword search, integrated at the query planner level, and that the query planner exposes multiple QueryModes.
What license is SeekStorm under?
SeekStorm is licensed under Apache License 2.0, and the Dockerfile labels the image accordingly. The InstantSearch adapter is a separate component published under the MIT license.
Community notes