HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
valeriansaliou
sonic
Rust2019–2024
valeriansaliou / sonic

sonic

🦔 Fast, lightweight & schema-less search backend. An alternative to Elasticsearch that runs on a few MBs of RAM.

35Distinct people
48Mentions
0Explicit recommenders
21.4KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

🦔 Fast, lightweight & schema-less search backend. An alternative to Elasticsearch that runs on a few MBs of RAM.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year48 dated mentions

Observed mentions: 2019-03-23 17:51:47 UTC to 2024-10-14 15:35:49 UTC.

0369122019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 11 mentions; 2 submissions, 9 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 12 mentions; 1 submissions, 11 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC1129
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC909
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC12111
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC1019
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC404

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Sonic Important📢 Heads up! Sonic is undergoing a big rework and contributions on the master branch are now bug fixes only. All of our efforts go to the v2 branch, where we are introducing long-awaited features. Sonic v2 will support Terabyte-scale ingestion/storage along with BM25 scoring and snippet retrieval (among other things). Stay tuned! Until Sonic v2 is released, don’t waste time diving into the source code of Sonic, as most of it will be completely different in v2. Outside contributions will be limited to short bug fixes until we consider Sonic stable again. Sonic is a fast, lightweight and schema-less search backend. It ingests search texts and identifier tuples that can then be queried against in a microsecond's time. Sonic can be used as a simple alternative to super-heavy and full-featured search backends such as Elasticsearch in some use-cases. It is capable of normalizing natural language search queries, auto-completing a search query and providing the most relevant results for a query. Sonic is an identifier index, rather than a document index; when queried, it returns IDs that can then be used to refer to the matched documents in an external database. A strong attention to performance and code cleanliness has been given when designing Sonic. It aims at being crash-free, super-fast and puts minimum strain on server resources (our measurements have shown that Sonic - when under load - responds to search queries in the μs range, eats ~30MB RAM and has a low CPU footprint; see our benchmarks). Tested at Rust version: rustc 1.98.0 (88d9e12ae 2026-08-18) 🇫🇷 Crafted in Nantes, France. 📰 The Sonic project was initially announced in a post on my personal journal. « Sonic » is the mascot of the Sonic project. I drew it to look like a psychedelic hipster hedgehog. Who uses it? Crisp Scrumpy 👋 You use Sonic and you want to be listed there? Contact me. Demo Sonic is integrated in all Crisp search products on the Crisp platform. It is used to index half a billion objects on a $5/mth 1-vCPU SSD cloud server (as of 2019). Crisp users use it to search in their messages, conversations, contacts, helpdesk articles and more. You can test Sonic live on: Crisp Helpdesk, and get an idea of the speed and relevance of Sonic search results. You can also test search suggestions from there: start typing at least 2 characters for a word, and get suggested a full word (press the tab key to expand suggestion). Both search and suggestions are powered by Sonic. Sonic fuzzy search in helpdesk articles at its best. Lookup for any word or group of terms, get results instantly. Features Search terms are stored in collections, organized in buckets; you may use a single bucket, or a bucket per user on your platform if you need to search in separate indexes. Search results return object identifiers, that can be resolved from an external database if you need to enrich the search results. This makes Sonic a simple word index, that points to identifier results. Sonic doesn't store any direct textual data in its index, but it still holds a word graph for auto-completion and typo corrections. Search query typos are corrected if there are not enough exact-match results for a given word in a search query, Sonic tries to correct the word and tries against alternate words. You're allowed to make mistakes when searching. Insert and remove items in the index; index-altering operations are light and can be committed to the server while it is running. A background tasker handles the job of consolidating the index so that the entries you have pushed or popped are quickly made available for search. Auto-complete any word in real-time via the suggest operation. This helps build a snappy word suggestion feature in your end-user search interface. Full Unicode compatibility on 80+ most spoken languages in the world. Sonic removes useless stop words from any text (eg. 'the' in English), after guessing the text language. This ensures any searched or ingested text is clean before it hits the index; see languages. Simple protocol (Sonic Channel), that let you search your index, manage data ingestion (push in the index, pop from the index, flush a collection, flush a bucket, etc.) and perform administrative actions. Sonic Channel was designed to be lightweight on resources and simple to integrate with; read protocol specification. Easy-to-use libraries, that let you connect to Sonic from your apps; see libraries. How to use it? Installation Sonic is built in Rust. To install it, either download a version from the Sonic releases page, use cargo install or pull the source code from master. 👉 Install from packages: Sonic provides pre-built packages for Debian-based systems (Debian, Ubuntu, etc.). Important: Sonic only provides 64 bits packages targeting Debian 12 for now (codename: bookworm). You might still be able to use them on other Debian versions, as well as Ubuntu (although they rely on a specific glibc version that might not be available on older or newer systems). First, add the Sonic APT repository (eg. for Debian bookworm): 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 curl -fsSL https://packagecloud.io/valeriansaliou/sonic/gpgkey | gpg --dearmor -o /usr/share/keyrings/valeriansaliou_sonic.gpg apt-get update Then, install the Sonic package: apt-get install sonic Then, edit the pre-filled Sonic configuration file: nano /etc/sonic.cfg Finally, restart Sonic: service sonic restart 👉 Install from source: If you pulled the source code from Git, you can build it using cargo: cargo build --locked --release You can find the built binaries in the ./target/release directory. Install build-essential, clang, libclang-dev, libc6-dev, g++ and llvm-dev to be able to compile the required RocksDB dependency. Note that the following optional features can be enabled upon building Sonic:
Read the full README on GitHub

What Hacker News says

48 sources
I don't believe there is just one answer to that, because it really depends on your needs, existing stack, and skillset. Disclaimer aside, I've heard very positive things about the search that ships with PostgreSQL, and similarly positive things for the few search extensions one can add (assuming extensions are available where you're running PG) https://github.com/quickwit-oss/tantivy#features seems to be a good starting place if you want to embed search, and its https://github.com/quickwit-oss/quickwit friend comes up a lot, but be sure to bear its AGPL license in mind Toshi is one of the ones which is striving for ES compatibility at the search level, making it a drop-in replacement https://github.com/toshi-search/Toshi#example-queries although last time I played with it, they were QUITE A WAYS away, depending on how deep one is in the
Read the rest
ES query DSL And then just last week <https://news.ycombinator.com/item?id=41797041> we were blessed with Nixiesearch <https://github.com/nixiesearch/nixiesearch> which is a pretty specialized engine but will almost certainly be less resource intensive than Elastic (or it's FOSS friend OpenSearch) Browsing https://github.com/topics/search-engine I was reminded about a bunch that I either haven't tried or I tried so long ago I don't recall their pro/con lists https://github.com/meilisearch/meilisearch https://github.com/typesense/typesense https://github.com/qdrant/qdrant https://github.com/valeriansaliou/sonic https://github.com/manticoresoftware/manticoresearch
In Huly – Open-source project management platform
This is uncanny, I just discovered ArchiveBox earlier today and set up a self-hosted instance on some home hardware for a collection of bookmarks of useful guides, tutorials, and references I've collected over the years. Setting it up on K8s with sonic [1] as the search backend and importing a few hundred URLs only took ~an hour or so, and the cached pages look great for the most part. [1] https://github.com/valeriansaliou/sonic
In ArchiveBox: Open-source self-hosted web archiving
Read the rest
onic Algolia https://github.com/marconi1992/algolite https://quickwit.io/ https://github.com/quickwit-inc/quickwit https://docs.meilisearch.com/ https://github.com/prabhatsharma/zinc phalanx https://github.com/blugelabs/bluge https://github.com/mosuka/phalanx https://github.com/mosuka/blast ManticoreSearch https://github.com/manticoresoftware/manticoresearch https://github.com/manticoresoftware/docker https://manticoresearch.com/blog/manticore-alternative-to-el... https://manticoresearch.com/ https://manual.manticoresearch.com/Introduction https://forum.manticoresearch.com/t/manticore-search-cheatsh... https://forum.manticoresearch.com/ Whoosh https://whoosh.readthedocs.io/en/latest/ https://pypi.org/project/Whoosh/ lyra https://github.com/nearform/lyra https://nearform.github.io/lyra/ https://github.com/LyraSearch/lyra https://lyrasearch.io/ flexsearch https://github.com/nextapps-de/flexsearch#performance-benchm... https://pagefind.app/docs/ Lucene https://github.com/apache/lucene https://lucene.apache.org/ ZincSearch https://zincsearch.com/ Solr https://solr.apache.org/ https://solr.apache.org/operator/ https://solr.apache.org/guide/solr/latest/getting-started/so... https://github.com/apache/solr https://solr.apache.org/guide/solr/latest/deployment-guide/s... Konnu https://gitlab.com/shadowislord/konnu Quickwit QuickWit + Clickhouse https://clickhouse.com/docs/en/guides/developer/full-text-se... https://clickhouse.com/docs/en/sql-reference/functions/strin... There is no way I can get to running all of these (this project was supposed to be quick!!), but I will run the ones I noted earlier, and probably manticore too since it was high on my list since it's quite polished looking.
In Sonic: Fast, lightweight and schema-less search backend
Wow it's weird that this comes up, I'm actually running a site I am going to repost to HN today that I want to use as a testbed for search engines (kind of like an extension to my recent collaboration with supabase[0]). Right now I've got the site going on just Postgres FTS + trigram and it's pretty darn fast, looks like I need to test sonic too. Going to burn some midnight oil (in my timezone, anyway) and get it out -- though sonic isn't implemented yet! Anyway to make this comment useful to people, here's my short list of engines that I want to run in parallel: - MeiliSearch (https://github.com/meilisearch/MeiliSearch) - TypeSense (https://github.com/typesense/typesense) - Lyra (https://github.com/LyraSearch/lyra) - OpenSearch (https://github.com/opensearch-project/OpenSearch) - ZincSearch (https://github.com/prabhatsharma/zinc) - Sonic
Read the rest
(https://github.com/valeriansaliou/sonic) There isn't enough out there comparing all these for the simple typical fuzzy search/search box usecase, so I'm adapting a little podcast search site I made to try and use all of these at the same time. So far only Postgres though, will try and add Meilisearch today and post it! Like other people are pointing out, most of these engines won't have all the features of ES (or more accurately Lucene) but I am pretty convinced that most of the time it doesn't actually matter and if someone is searching on your site excessively maybe there's a problem with your UX (unless you're a search engine or repository of information). [0]: https://supabase.com/blog/postgres-full-text-search-vs-the-r...
In Sonic: Fast, lightweight and schema-less search backend
Yup! I'd heard of Quickwit and sonic, but Quickwit seems to have pivoted to being a log-search focused engine. It's built on Tantivy[0] IIRC so I could have used something like Toshi[1]. Sonic[2] I know much less about but it also seems good. Honestly anything except ES is what I like to hear about (though OpenSearch is interesting). Another thing I think the world really needs is a CLI +/- API tool (ideally rust lib + CLI + API) that unifies interacting with these things. I got REALLY close to writing it while working on this article, but I was already running late and I have a penchant for yak shaving. This won't be the last thing I write about search engines -- there's been a LOT of movement in the space that has nothing to do with the elastic/opensearch debacle and I don't see enough tires getting kicked. [0]: https://github.com/quick
Read the rest
In Postgres Full Text Search vs. the Rest
I've never worked on a project that encompasses as many computer science algorithms as a search engine. There are a lot of topics you can lookup in "Information Storage and Retrieval": - Tries (patricia, radix, etc...) - Trees (b-trees, b+trees, merkle trees, log-structured merge-tree, etc..) - Consensus (raft, paxos, etc..) - Block storage (disk block size optimizations, mmap files, delta storage, etc..) - Probabilistic filters (hyperloloog, bloom filters, etc...) - Binary Search (sstables, sorted inverted indexes, roaring bitmaps) - Ranking (pagerank, tf/idf, bm25, etc...) - NLP (stemming, POS tagging, subject identification, sentiment analysis etc...) - HTML (document parsing/lexing) - Images (exif extraction, removal, resizing / proxying, etc...) - Queues (SQS, NATS, Apollo, etc...) - Clustering (k-means, density, hierarchical, gaussi
Read the rest
an distributions, etc...) - Rate limiting (leaky bucket, windowed, etc...) - Compression - Applied linear algebra - Text processing (unicode-normalization, slugify, sanitation, lossless and lossy hashing like metaphone and document fingerprinting) - etc... I'm sure there is plenty more I've missed. There are lots of generic structures involved like hashes, linked-lists, skip-lists, heaps and priority queues and this is just to get 2000's level basic tech. If you are comfortable with Go or Rust you should look at the latest projects in this space: - https://github.com/quickwit-oss/tantivy - https://github.com/valeriansaliou/sonic - https://github.com/mosuka/phalanx - https://github.com/meilisearch/MeiliSearch - https://github.com/blevesearch/bleve - https://github.com/thomasjungblut/go-sstables A lot of people new to this space mistakenly think you can just throw elastic search or postgres fulltext search in front of terabytes of records and have something decent. The problem is that search with good rankings often requires custom storage so calculations can be sharded among multiple nodes and you can do layered ranking without passing huge blobs of results between systems. Source: I'm currently working on the third version of my search engine and I've been studying this for 10 years.
In Ask HN: I want to dive into how to make search engines
There isn't a one-size-fits all approach, but I've never worked on a project that encompasses as many computer science algorithms as a search engine. - Tries (patricia, radix, etc...) - Trees (b-trees, b+trees, merkle trees, log-structured merge-tree, etc..) - Consensus (raft, paxos, etc..) - Block storage (disk block size optimizations, mmap files, delta storage, etc..) - Probabilistic filters (hyperloloog, bloom filters, etc...) - Binary Search (sstables, sorted inverted indexes) - Ranking (pagerank, tf/idf, bm25, etc...) - NLP (stemming, POS tagging, subject identification, etc...) - HTML (document parsing/lexing) - Images (exif extraction, removal, resizing / proxying, etc...) - Queues (SQS, NATS, Apollo, etc...) - Clustering (k-means, density, hierarchical, gaussian distributions, etc...) - Rate limiting (leaky bucket, windowed, etc.
Read the rest
..) - text processing (unicode-normalization, slugify, sanitation, lossless and lossy hashing like metaphone and document fingerprinting) - etc... I'm sure there is plenty more I've missed. There are lots of generic structures involved like hashes, linked-lists, skip-lists, heaps and priority queues and this is just to get 2000's level basic tech. - https://github.com/quickwit-oss/tantivy - https://github.com/valeriansaliou/sonic - https://github.com/mosuka/phalanx - https://github.com/meilisearch/MeiliSearch - https://github.com/blevesearch/bleve - https://github.com/thomasjungblut/go-sstables A lot of people new to this space mistakenly think you can just throw elastic search or postgres fulltext search in front of terabytes of records and have something decent. That might work for something small like a curated collection of a few hundred sites.
In Writing your own search engine is hard (2004)
Is there a tool that automatically forwards every URL + HTML of the page you visit to a webhook so you could write an endpoint that would index everything? If not, I would love to see this add a "forward to webhook" option. I would be happy to write up a real backend that parsed the content and indexed it. Actually, there are lots of OS projects for this: https://github.com/quickwit-oss/tantivy, https://github.com/valeriansaliou/sonic, https://github.com/mosuka/phalanx, https://github.com/meilisearch/MeiliSearch, etc... I would think that with the thousands (tens of thousands?) of pages I would index just browsing each year it would be relativity easy to find ways to automatically expand the index to include links that appear multiple times in those pages or some other heuristic
In Show HN: I built a self hosted recommendation feed to escape Google's algorithm

Showing the 15 most recent of 48 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.