FYI, manticore is not "new". It has been around many years, and is based on Sphinx search which has been around longer than, I think, Lucene (which elasticseaech is built on)
It sounds like they're really targeting the logging search store part of ELK, which can be a perfectly fine objective, but no need to mislead audiences since they will find out and then you've made an enemy
Hi everyone — I'm one of the maintainers of Manticore Search. Huge thanks to @klaussilveira for submitting this — we really appreciate the interest and the thoughtful discussion here.
A few points that came up in the thread and are worth clarifying:
- We do get compared to Elasticsearch a lot. While we support some of its APIs, Manticore isn't a drop-in replacement. We've focused on performance, simplicity, and keeping things open-source without vendor lock-in. Our own SQL-based query language and REST endpoints are part of that philosophy.
- @mdaniel was right to question the "drop-in" wording — that's not our goal.
- As @sandstrom pointed out, tools like Typesense and Meilisearch are part of this evolving search space. We see Manticore fitting in where users want powerful full-text and vector search capabilities with lower resource overhead and SQL capabilities (we support JSON too though)
We'd love to hear from you:
- What are your main use cases for search or log indexing?
- Which Elasticsearch features (if any) are absolutely essential for you?
- Are there performance comparisons or scaling challenges you'd like to see addressed?
"What are your main use cases for search or log indexing?"
To me, storing and searching logs is quite different from most other search use-cases, and it's not obvious that they should be handled by the same piece of software.
For example, tokenization, stemming, language support many other things and are basically useless in log search. Also, log search is often storing a lot of data, and rarely retrieving it (different usage pattern from many search use-cases which tend to be less write-heavy and more about reads).
I know ElasticSearch has had success in both, but if I were Manticore/Typesense/Meilisearch I'd probably just skip logs altogether.
Loki, QuickWit and other such tools are likely better suited for logs.
I've been using Sphinx for 20 years for full-text search with a custom stemmer. I considered switching to Manticore, but didn't see a huge need to do so, because Sphinx still works well for me and requires zero maintenance. Any big new features that might entice me to switch? (I only have a few GB of indexes, covering a few million documents.)
> We do get compared to Elasticsearch a lot. While we support some of its APIs, Manticore isn't a drop-in replacement.
Thank you for saying that up front. I read a description of your product and the first thing I thought was, "this looks like a potential alternative to ElasticSearch, but it is not a drop-in replacement for ElasticSearch".
Curious about the architecture here. Where does the 20x speedup come from ?
Recently had a look at Tantivy as well, although compared to raw lucene, their perf is actually inferior. Wonder if there are specific benchmarks here which measure performace and if they compared tail latencies as opposed to averages.
If I had to guess, I would say it’s the 20x smaller feature set compared to Elasticsearch.
We built a custom search engine on top of Elasticsearch. Our query builder regularly constructs optimised queries that would be impossible to implement in any of the touted alternatives or replacements, which almost always focus on simple full text search, because that’s everything the developers ever used ES for. There’s a mindboggingly huge number of additional features that you need for serious search engines though, and any contender will have to support at least a subset of these to deserve that title in the first place.
I’m keeping an eye on the space, but so far, I’m less than impressed with everything I’ve seen.
I like Manticore. It's easy to setup, lean on resources and quite fast. I use it when I want to quickly pour a lot of semi-structured text into a database for exploratory browsing and prototype web applications.
The auto-bolding of query terms in responses is quite convenient and has allowed me to skip annoying little regexes many times. Maybe other engines have it too and I never noticed?
manticore, earlier sphinx search, has been rock solid for us for the past 16 years. now serving searches across nearly 300M short documents. we're using it in the old mode - where full index is re-created every 24h.
it's great to see that the project is alive and adding embeddings-related functions needed for semantic search.
18 comments
[ 3.1 ms ] story [ 50.0 ms ] thread(both are also trying to replace Algolia, because both have cloud offerings)
Edit: Nevermind, in another part of this thread the maintainer said:
Which conflicts with the README: "Drop-in replacement for E in the ELK stack"I have no affiliation.
It sounds like they're really targeting the logging search store part of ELK, which can be a perfectly fine objective, but no need to mislead audiences since they will find out and then you've made an enemy
A few points that came up in the thread and are worth clarifying:
- We do get compared to Elasticsearch a lot. While we support some of its APIs, Manticore isn't a drop-in replacement. We've focused on performance, simplicity, and keeping things open-source without vendor lock-in. Our own SQL-based query language and REST endpoints are part of that philosophy. - @mdaniel was right to question the "drop-in" wording — that's not our goal. - As @sandstrom pointed out, tools like Typesense and Meilisearch are part of this evolving search space. We see Manticore fitting in where users want powerful full-text and vector search capabilities with lower resource overhead and SQL capabilities (we support JSON too though)
We'd love to hear from you: - What are your main use cases for search or log indexing? - Which Elasticsearch features (if any) are absolutely essential for you? - Are there performance comparisons or scaling challenges you'd like to see addressed?
Happy to answer any questions or dive deeper.
Does this mean you've at least implemented every API that Kibana requires?
To me, storing and searching logs is quite different from most other search use-cases, and it's not obvious that they should be handled by the same piece of software.
For example, tokenization, stemming, language support many other things and are basically useless in log search. Also, log search is often storing a lot of data, and rarely retrieving it (different usage pattern from many search use-cases which tend to be less write-heavy and more about reads).
I know ElasticSearch has had success in both, but if I were Manticore/Typesense/Meilisearch I'd probably just skip logs altogether.
Loki, QuickWit and other such tools are likely better suited for logs.
- https://github.com/quickwit-oss/quickwit - https://github.com/grafana/loki
Thank you for saying that up front. I read a description of your product and the first thing I thought was, "this looks like a potential alternative to ElasticSearch, but it is not a drop-in replacement for ElasticSearch".
Recently had a look at Tantivy as well, although compared to raw lucene, their perf is actually inferior. Wonder if there are specific benchmarks here which measure performace and if they compared tail latencies as opposed to averages.
We built a custom search engine on top of Elasticsearch. Our query builder regularly constructs optimised queries that would be impossible to implement in any of the touted alternatives or replacements, which almost always focus on simple full text search, because that’s everything the developers ever used ES for. There’s a mindboggingly huge number of additional features that you need for serious search engines though, and any contender will have to support at least a subset of these to deserve that title in the first place.
I’m keeping an eye on the space, but so far, I’m less than impressed with everything I’ve seen.
What was the reason for the fork, and in what ways does Manticore Search differ from Sphinx today?
as far as i understand apparent death of sphinx and demand for continued development/support from big users of it led to creation of manticore.
The auto-bolding of query terms in responses is quite convenient and has allowed me to skip annoying little regexes many times. Maybe other engines have it too and I never noticed?
MIT: https://github.com/meilisearch/meilisearch/blob/v1.15.2/LICE...
from a few months ago: https://news.ycombinator.com/item?id=43680699 and the .com has quite a few submissions, but without any obvious commentary upon them https://news.ycombinator.com/from?site=meilisearch.com
it's great to see that the project is alive and adding embeddings-related functions needed for semantic search.