Extremely Fast and Flexible, but Requires Deep Understanding

[Serminos]

I use Manticore Search in my project, mainly with plain tables. One of the reasons I use plain tables is that they can be built directly from an SQL query as a data source. The indexer is extremely fast — so fast that I don’t really want to build a separate loader for RT tables just to get the same result.

What I like most about Manticore is its speed, low resource usage, open-source nature, and flexibility. I also appreciate the Russian-speaking support community, which is very helpful.

At the same time, this flexibility can be challenging. There are many powerful text-processing options — word forms, morphology, tokenization, exceptions, ignored characters, blended characters, charset settings, expand options, and so on. It can be hard to understand the exact order in which everything is applied. A visual flowchart or an online playground where you could enter settings, run search queries, and see how Manticore processes them step by step would be very useful.

Another area that could be clearer is the difference between CRC and keyword dictionaries. Some things work differently depending on which one is used, and the documentation could probably be split more clearly between CRC and keyword use cases. In my project, I still use CRC because it performs faster in my scenarios, even though keyword is generally recommended.

I also had some difficulty understanding high availability for plain tables. For RT tables, clustering is described more clearly, but for plain tables it wasn’t obvious how to properly configure distributed tables and failover between two servers. I eventually found a working approach through support discussions, but it would be great to have this explained directly in the documentation.

Query planning is another area where I had to experiment a lot. In one case, I wanted to search a smaller address table first, get IDs, and then search a larger table with full addresses using those IDs as a filter. I expected the ID filter to be applied before MATCH, but in practice MATCH was applied first and filtering happened afterward. The predictable and fast workaround was to include the IDs directly inside the MATCH expression, but that requires generating a long query string and being very careful with search operators. Similar questions came up when trying to use columnar storage for filtering.

I also worked with Manticore from a Java API using a reactive stack. There is a client, but it didn’t fit my WebFlux-based approach, so I ended up using regular HTTP calls with raw SQL queries. It works, and the SQL syntax with search operators is very powerful, but it takes time to understand the model properly.

Custom ranking and sorting were also difficult for me to configure. The documentation explains individual operators, but it is still hard to understand the full logic and how to combine everyt.

!!! WORTH EVERY MINUTE !!!
Overall, Manticore Search is very fast, uses few resources, and its flexibility is great — you can configure almost everything. But that same flexibility can also be confusing, both in the documentation and in practice. It seems like everything is there and should work, but as soon as you start combining features, inconsistencies pop up here and there. You have to dig really deep, experiment a lot, and try out different combinations. While tuning the search engine, you feel like a researcher and a pioneer. But once you figure out all the possibilities, the incredible performance is truly impressive.

[sanikolaev]

Thank you for the detailed review and for sharing your experience with Manticore!

We're glad to hear that the performance, low resource usage, and flexibility have made it worth the effort. We also appreciate the honest feedback about the documentation and some of the more advanced features. Feedback like yours helps us understand where we can do a better job and what deserves more attention.

Thanks again for your support, your patience, and for being part of the community!