Sonic indexes identifiers and never stores your documents

Search returns identifiers, so every hit costs you a second lookup

Sonic's most consequential decision is what it refuses to keep. It stores no direct textual data in its index. It ingests search texts and identifier tuples, maintains a word graph for auto-completion and typo correction, and returns object identifiers at query time for you to resolve against an external database.

That choice is what makes the footprint plausible. Roughly 30MB of RAM under load and microsecond-range query responses, in the project's own measurements, are not the numbers of an engine holding your documents. They are the numbers of one holding words and identifiers.

The cost moves to your side of the wire. A result set of identifiers has to be joined against your database before a user sees anything, so the latency budget has two parts and Sonic only owns the first. Anyone expecting highlights or matched snippets from a search engine will not find them here.

Terms live in collections, and collections are organized in buckets. One bucket can serve the whole platform, or each user can get a bucket of their own when they need separate indexes.

The Debian package is 64-bit bookworm and wants a specific glibc

The packaged path is narrow by design. Pre-built packages live on packagecloud for Debian-based systems, and the project states that only 64-bit packages targeting Debian 12, codename bookworm, exist. Other Debian releases and Ubuntu may still run them, provided the glibc those binaries need happens to be present.

Three commands set up the repository. First the source list:

echo "deb [signed-by=/usr/share/keyrings/valeriansaliou_sonic.gpg] https://packagecloud.io/valeriansaliou/sonic/debian/ bookworm main" > /etc/apt/sources.list.d/valeriansaliou_sonic.list

Then the signing key, dearmored into a keyring the source list points at:

curl -fsSL https://packagecloud.io/valeriansaliou/sonic/gpgkey | gpg --dearmor -o /usr/share/keyrings/valeriansaliou_sonic.gpg

Then the package itself and the config file it pre-fills:

apt-get update
apt-get install sonic

nano /etc/sonic.cfg

service sonic restart

There is no 32-bit build and no package for a base older than bookworm. A fleet on an older image ends up compiling RocksDB itself or running something else.

Building from source means RocksDB and a C++ toolchain

The source route assumes you already have a C and C++ toolchain installed. The project asks for build-essential, clang, libclang-dev, libc6-dev, g++ and llvm-dev, and gives the reason: RocksDB is a required dependency that has to be compiled.

cargo build --locked --release

The binaries land in ./target/release. The --locked flag matters more than it looks, since it forces the build onto the exact dependency versions recorded in the lockfile rather than whatever the registry serves that morning.

The release profile is tuned hard, with opt-level 3, fat LTO and stripped symbols. A separate lint profile turns LTO off and switches panics from unwind to abort, so a lint build and a release build are not the same program.

cargo install sonic-server gives you the server and the path fix

The shortest install names a single crate:

cargo install sonic-server

Two follow-ups are named with it. Your PATH has to be configured to source the Crates binaries, and the command you then run is `sonic`. The crate is the server. The workspace it comes from has three members, core, server and client, so the client library is a separate artifact you do not receive from this command.

The three routes are presented as interchangeable, and they are not equally reproducible. A download from the releases page is a build you did not compile. Cargo install resolves dependencies on your machine at install time and never sees the repository lockfile. Only the source build pins versions.

One detail tells you where the maintainers think the front door is: the project homepage is the crates.io listing for sonic-server, not a docs site.

A background tasker consolidates the index while the server keeps serving

Items move in and out with push and pop operations that can be committed while the server is running, and a background tasker handles the job of consolidating the index so that entries you pushed or popped become quickly available for search.

Read that twice before loading data. There is no stated instant at which a pushed term is guaranteed searchable. Code that reads immediately after writing has to tolerate a short lag, and a data-quality check that counts terms right after ingestion will see fewer than it wrote.

The administrative surface is small on purpose. The Sonic Channel protocol covers searching, ingestion including push, pop, flushing a collection and flushing a bucket, and administrative actions, with the full specification in PROTOCOL.md rather than in prose. Bucket-level flush is the operation that makes per-user buckets recoverable, since you can clear one user's index without touching anyone else's.

Typo correction only fires once exact matches run short

Correction in Sonic is a fallback, not a default. Typos are corrected if there are not enough exact-match results for a given word in a search query. When exact matches are plentiful, the word is used as given.

That ordering cuts both ways. Search stays predictable while the index is well populated, which is what you want for a term that happens to be a product name. It also means the query your user typed is not necessarily the query that ran, and the substitution is visible only in the results.

Auto-completion rests on the same foundation. The suggest operation completes any word in real time, built on the word graph the index keeps even though no document text is stored, and that graph is also what feeds correction.

Language handling carries its own step. Stop words are removed only after Sonic guesses the text language, and the compatibility claim covers 80 or more of the most spoken languages. A wrong guess changes which words get treated as noise.

The container advertises port 1491 and hands you no config file

The Docker image is short enough to read whole. It builds on rust:1-slim-trixie, installs build-essential and clang, runs a locked release build, strips the binary, then copies one file into a distroless base:

FROM gcr.io/distroless/cc

WORKDIR /usr/src/sonic

COPY --from=build /app/target/release/sonic /usr/local/bin/sonic

CMD ["sonic"]

EXPOSE 1491

Two consequences follow. Port 1491 is the only port the image advertises, and it is the endpoint your Sonic Channel client connects to. And a distroless base has no shell, so the packaged install's `nano /etc/sonic.cfg` step has no counterpart in the image.

Server and core ship as two separate version lines

The most recent release is v1.10.2 on 2026-10-05, after v1.10.1 on 2026-09-25 and v1.10.0 on 2026-09-21.

The toolchain floor is in the workspace manifest: rust-version 1.92.0, edition 2024, resolver 3, with members core, server and client. The project notes it was tested at rustc 1.98.0. That gap is the usual one between a declared minimum and the version used for testing, but it means a machine on an older pinned toolchain can compile the workspace and still meet behaviour nobody has checked.

The licence is MPL-2.0, which applies copyleft per file rather than across the whole tree, so a distributed modification to a covered file carries an obligation to publish that file's source. Nothing in the repository requires you to change the licence when you embed Sonic, and nothing forbids it either. Read LICENSE.md before shipping a fork instead of treating the identifier as the whole answer. The last push was on 2026-10-30.

Editorial conclusion

Adopt Sonic when your searches resolve to IDs you already store in a database, your users have separate indexes worth isolating, and you want auto-complete and typo correction without running a cluster. Do not adopt it if you need highlighting, snippets, full document storage or a query language, because none of those are in the index. Before you install, decide which of the two buckets arrangements you will use, then confirm your base image matches the bookworm package or budget for compiling RocksDB yourself.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. Project website
3. README
4. Releases
5. valeriansaliou/sonic on GitHub