snikolaev

Analysis: Google, Apple, and Amazon each have more meetings with European parliament and European Commission officials than any individual European company

some test

Fair. We spent months optimizing query execution and approximately 1 minute optimizing the hero image. Clearly the latter made the bigger impression :)

Authentication, sharded tables, conversational search and faster vector search

Great to hear! 16 years is impressive. Glad to see the new semantic features caught your eye — we're excited to keep improving the project.

If your setup works fine and doesn't need any maintenance, there's really no reason to switch to something else. But once you upgrade to a newer version of Sphinx and it crashes, I personally feel more comfortable knowing I can report the issue on GitHub and expect it to be fixed eventually. Unfortunately, that's not how it works with Sphinx.

Speaking of features, both Sphinx (as a closed-source project) and Manticore (as an open-source project) have added some nice improvements during last years. But again, if you're happy with the 20-year-old version, there's probably nothing to worry about.

Thank you!

Complex boolean queries work great. Manticore also supports over 20 full-text operators — a lot more than Elasticsearch. That's one reason it's popular in areas like patent and legal search, where strong full-text matching is especially important.

Custom script scoring is available - https://manual.manticoresearch.com/Extensions/UDFs_and_Plugi...

Vectors - yes. Recent blog post on it https://manticoresearch.com/blog/quantization/

Pipelined aggregations - no.

Nested documents - no, but Manticore supports INNER JOIN and LEFT JOIN.

There's a JSON field type that lets you use any schema, but it doesn't support full-text filtering. If you are not using it and if your next document has a different schema, it will cause an error when you try to insert it.

But not everything works with Kibana. What are some well known alternatives besides Manticore?

Autosharding, authentication, dynamic mapping.

It's somewhat smaller, but I believe not 20 times smaller. Among the major features, probably only authentication and auto-sharding are missing. Both are already in progress. On the other hand, the main feature missing in Elasticsearch is proper SQL support, which many Manticore users really appreciate.

It's not a drop-in replacement in general, but it can be seen as a drop-in replacement for Elasticsearch in the ELK stack because: - You can send data to Manticore using Logstash (L) - You can visualize the data using Kibana (K)

Sorry for the confusion :)

Not every, but Kibana can be used with Manticore with some limitations - https://github.com/manticoresoftware/kibana-demo

Thanks for sharing! What sets Manticore apart from Meilisearch and Elasticsearch is that it lets you configure tokenization at a low level by:

- choosing which characters should be treated as token characters, and using the rest as token separators

- defining "blend chars" — for example, the hyphen (-) could make sense as both a separator and a non-separator in your case

- or optionally adding it to the ignore_chars list

- there's also regexp_filter to process tokens when indexing and searching

That said, setting things like this up perfectly is always tricky with any search engine, because the words and punctuation in real data often don't follow regular patterns. It's especially difficult when you want to find "abc def" by "ab cd ef" which may be a common situation in your case.

We made a blogpost "TF-IDF in a nutshell" - https://manticoresearch.com/blog/tf-idf-in-a-nutshell/

Manticore Search's query language is more expressive than Lucene's. While Lucene supports basic boolean logic, field search, phrase queries, wildcards, and proximity, Manticore adds many powerful operators. These include quorum matching (/N), strict word order (<<), NEAR/NOTNEAR proximity, MAYBE (soft OR), exact form (=word), position anchors (^word, word$), full regular expressions, and more. Manticore uses SQL-style syntax with a MATCH() clause for full-text search, making it easier to combine text search with filters and ranking.

The speedup comes from a number of architectural and low-level performance optimizations in Manticore Search.

Manticore has a modern multithreading architecture with efficient query parallelization that fully utilizes all CPU cores. It supports real-time indexing - documents are searchable immediately after insertion, with no need to wait for flushes or refreshes.

It uses row-wise storage optimized for small to large datasets, and for even larger datasets that don’t fit into memory, there's support for columnar storage through the Manticore Columnar Library.

Secondary indexes are built automatically using the PGM-index (Piecewise Geometric Model index), which enables efficient filtering and sorting by mapping keys to their memory locations. The cost-based query optimizer uses statistics about the data to choose the most efficient execution plan for each query.

Manticore is SQL-first: SQL is its native syntax, and it speaks the MySQL protocol, so it works out of the box with MySQL clients.

It's written in C++, starts quickly, uses minimal RAM, and avoids garbage collection — which helps keep latencies low and stable even under load.

As for benchmarks, there's a growing collection of them at https://db-benchmarks.com, where Manticore is compared to Elasticsearch, MySQL, PostgreSQL, Meilisearch, Typesense, and others. The results are open and reproducible.

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?

Happy to answer any questions or dive deeper.

The Manticore Search github repository calls it a "drop-in replacement for E in the ELK stack," not just a replacement for Elasticsearch. On https://manticoresearch.com/, it's described as an "Elasticsearch alternative," so the confusion is probably just here on HN :)

Prometheus Integration, Enhanced Monitoring, and Major Improvements

Prometheus Integration, Enhanced Monitoring, and Major Improvements

Manticore Search + Columnar Storage

This article may be more relevant https://manticoresearch.com/blog/github-semantic-search/

Meilisearch doesn't support BM25, does it?

Check out Manticore Search for your use case. It's open-source, cost-effective, and doesn't require keeping everything in memory.

Key points:

- Columnar Storage: Efficiently handles large datasets on disk, ideal for terabyte-scale data. It's not enabled by default but can be set up easily with "CREATE TABLE ... ENGINE='columnar'".

- Faceted Search: Probably easier than anywhere else with just "FACET <field name>" added to your "SELECT" query.

- MySQL Protocol and SQL Support: If you’re familiar with SQL and MySQL, it's easier to get started compared to other search engines.

> We filtered out PISA Search and Manticore because neither of them offers search-as-you-type and facet search features

Manticore does support facet search and it's quite powerful in Manticore:

- docs - https://manual.manticoresearch.com/Searching/Faceted_search#...

- interactive course - https://play.manticoresearch.com/faceting/

Search-as-you-type depends more on the client, not on the backend. However, Manticore provides the autocomplete and fuzzy features (both in beta stage though). More info here https://github.com/manticoresoftware/manticoresearch/issues/...

Manticore Search

MySQL's full-text ranking capabilities are quite limited and AFAIK full-text wasn't a priority for them lately. The related article is "Rankings with InnoDB Full-Text Search" [1]

If it works for you - great. If you need more flexibility in terms of data tokenization, matching and ranking you can consider Manticore Search [1] instead of Elasticsearch since it's a continuation (a fork made in 2017) of the Sphinx search engine mentioned in the article on mysql.com and has a better integration with MySQL than Elasticsearch (e.g. you can use Linux mysql client or any programming language mysql connector to make queries to Manticore).

[1] https://dev.mysql.com/blog-archive/rankings-with-innodb-full...

[2] https://github.com/manticoresoftware/manticoresearch

> I decided to experiment with this setup and the NY Taxi Dataset. The initial goal was to populate ElasticSearch with ~14 million rows, loading data from a compressed parquet file of ~350 MB.

> I tried multiple times, but the operation failed continuously, due to JVM memory constraints

Here's a script https://github.com/db-benchmarks/db-benchmarks/blob/main/tes... which loads 1.7B NYC taxi ride documents into Elasticsearch.