# Manticore Search treats search as a SQL database, not a Java service > A C++ search engine with two storage engines, vector search inside the table definition, and benchmark claims pinned to a version two majors behind the current release. **manticoresoftware/manticoresearch** — Open-source search database for full-text, vector, and hybrid search with real-time indexing and SQL. - Repository: https://github.com/manticoresoftware/manticoresearch - Website: https://manticoresearch.com - Stars: 12,050 · Forks: 646 - Language: C++ - License: GPL-3.0 - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/manticoresoftware-manticoresearch ## A search engine whose interface is SQL The repository description is unusually specific for a search project: an open-source search database for full-text, vector and hybrid search with real-time indexing and SQL. Four capabilities in one sentence, and the last one is the load-bearing choice. SQL is the interface, and the README says it plainly, describing Manticore Search as SQL-first and MySQL-compatible, with SQL as the native syntax used through your preferred MySQL client. That decision has consequences for everything else. There is no Java or Go service to deploy alongside your application, no REST layer to translate between your query builder and an internal DSL, and no schema registry to keep in sync. The topics on the repository track the same idea: full-text-search, search-engine, search-server, search-api, sql, mysql, bm25, json, stream-filtering. BM25 sits next to sql because ranking and querying are not separate systems here. The language is C++, which tells you where the engineering went. The repository carries 12,026 stars, 643 forks and 652 open issues, and GitHub reports the license as GPL-3.0. The README badge reads GPLv3 or later, and a `component-licenses/` directory at the root suggests the project tracks the licences of what it vendors. The homepage is manticoresearch.com, and the documentation lives on a separate manual subdomain rather than in the repository. ## Two storage engines, two different products The single most useful thing in the README is that Manticore offers two storage layouts, and they are aimed at different problems. Row-wise storage is described as fast for small, medium and large datasets. That is the default-shaped option, and it is what you get when your index fits comfortably in memory. Columnar storage is credited to a separate project, the Manticore Columnar Library, and is described as handling datasets too large to fit in RAM. That distinction drives a lot of the release notes. Recent work has gone into memory-mapped columnar attributes by default, configurable file access, faster columnar KNN rescoring and distributed-query memory use. Those are all symptoms of the same pressure: columnar storage exists because someone tried to index more data than RAM would hold, and each of those changes is a fix for a way that attempt used to fail. The 29.0.2 release also adds distributed and sharded table optimization, which is the other half of the same scale story. So when you evaluate this, the first question is not which engine is faster in the abstract. It is whether your data fits in memory. If it does, the row-wise path is the simpler one and the columnar work is irrelevant to you. If it does not, the columnar path is the product, and its tuning history is the thing to read. ## Vector search moved inside the table definition The 29.9.0 release, published 2026-09-11, is the clearest statement of where the project is heading: chunked and multi-vector auto-embeddings, configurable embedding input limits and safe UTF-8 identifiers. Auto-embeddings with automatic chunking generate vectors from text and can split long documents into fixed-size, recursive or sentence-based chunks stored in a `float_vector_array`. The README is direct about why that matters, saying it makes relevant sections searchable without chunking on your side. This is a real change in where the work happens. Vector pipelines usually mean an embedding call, a splitter, a batch job and a place to keep the intermediate state. Here the column type is part of the table, so the splitting is a property of the storage rather than a step in your code. Hybrid search combines full-text and vector retrieval in a single query, which is the mode most teams actually want, since pure vector search loses exact matches and pure keyword search loses paraphrase. Conversational search goes one step further, letting existing vectorized tables answer questions with KNN retrieval, conversation history and LLM-backed responses through a SQL `CALL CHAT` statement or the HTTP JSON `/search` endpoint. The 29.0.2 notes describe conversational search as more reliable, which reads like an admission that the first version was not. What none of this changes is the boundary. Embedding still means sending text somewhere and paying for it, and the release adds limits on embedding input rather than removing them. The feature list here stops partway through the official clients row, so treat the client list as partial and read the manual for the current roster. ## Reading the benchmark numbers honestly The README leads with speed claims, and they are specific: 340x faster than MySQL 9.7.1 and 6.51x faster than Typesense 27.1 on 1.1 million Hacker News comments, 3.85x faster than a tuned Elasticsearch 9.4.3 on 100 million-plus comments, 2.02x faster than that Elasticsearch on 1.7 billion NYC taxi rides, and 1.71x faster than ClickHouse 26.6.1.1193 on the dashboard's default 10 million-log selection. Two details matter more than the multiples. First, every one of those comparisons is against Manticore Search 27.1.5, while the newest release in this repository is release-29.9.0 from 2026-09-11. The benchmark describes a build two majors behind the current one. That does not make it wrong, and faster code does not usually get slower, but it does mean the figures describe a version you cannot install from these tags. Read them as a claim about direction, not as a measurement of the build you would deploy. Second, the README says so itself, noting that results are workload-specific and pointing readers at the linked dashboard to select queries matching their own workload. The ingestion comparison is the most useful of the set, because it reports resources rather than a ratio: the same 10 million Nginx logs took 5 minutes 46 seconds against 10 minutes 15 seconds, on 1.02 versus 3.80 CPU cores, with 3.98 GB versus 36.98 GB of RAM, and 0.41 MB read against 322.14 MB. A tenfold difference in resident memory is the kind of number that changes an architecture decision, and it is worth checking against your own row sizes. ## The release notes as a maintenance signal Three recent tags show the shape of the project's upkeep, and the naming convention is worth noting: the tags are prefixed, so you get release-29.9.0 rather than a bare 29.9.0. release-29.9.0 landed on 2026-09-11 and covers chunked and multi-vector auto-embeddings, German sharp-s normalization, richer benchmarking for the manticore-load tool, authenticated cloud-aware backups and memory-mapped columnar attributes by default, with fixes spread across KNN, hybrid and grouped search, schema changes, bulk ingestion, replication and binlog recovery. release-29.0.2 on 2026-08-14 adds sharded-table settings inspection, Unix-socket callbacks for Buddy and configurable file access. release-28.6.6 on 2026-07-31 adds UUID document IDs for real-time tables and an ordered, limited `GROUP_CONCAT()`. The body of each release rolls up several versions rather than describing only its own tag, so the 29.0.2 notes include entries labelled 29.0.0 and 28.10.0. That makes the changelog harder to read version by version and much better for seeing what an upgrade actually brings you. The last push to the repository is dated 2026-09-21, days after the newest tag, which is the sort of cadence you want from a database you plan to depend on. What the notes also reveal is a long tail of SQL compatibility work. Recent fixes cover JDBC compatibility, highlighting, template tables, concurrent optimization of real-time tables, backups and replication. For a project whose pitch is that you can use your existing MySQL client, that tail is the honest cost of the pitch: you get the client's familiarity, and you inherit the gaps between the client's SQL and Manticore's. ## What is vendored, and what you would build yourself The repository root shows a C++ project that carries its dependencies as submodules rather than fetching them at build time. `.gitmodules` is present, and the tree includes `libicu/`, `libre2/` and `libstemmer_c/`, which are the text-matching pieces a search engine cannot do without. `deps.txt` sits alongside them as the declared dependency list. The build is CMake plus a `configure` script, with `CMakeLists.txt` at the root and `cmake/` holding the module files: ```text CMakeLists.txt configure INSTALL deps.txt example.sql ``` The testing story is visible in the file names. `test/` holds the suite, `docker-compose-test.yml` suggests the suite runs against containers, and there are scripts named `smoke.sh`, `smokeci.sh`, `memcheck.sh` and `valgrind`, along with a `mcl` directory for its own command-line client. `memdocker.sh` and `docker-compose-test.yml` point at a container-based path for the memory checking work. Documentation lives in `manual/` and `doc/`, distribution packaging in `dist/` and `installer/`, and `galera_packaging/` hints at the clustering story. One oddity worth flagging: a `.gitlab-ci.yml` at the root alongside a `.github/` directory. Continuous integration is configured on both GitLab and GitHub for the same project, which is either a deliberate mirror or a leftover, and either way it tells you the project has outgrown a single forge. The root also carries `116.conf`, a configuration file with a number in its name that no documentation in the repository explains. ## Conclusion Manticore Search rewards an evaluation that starts with your workload rather than its feature list. Two storage engines means the first question is whether your data fits in RAM, and the columnar path is the one built for when it does not. Two things deserve a close look before you commit. The benchmark figures in the README were measured against version 27.1.5 while the newest tag here is release-29.9.0 from 2026-09-11, so run your own comparison on the build you would actually deploy rather than quoting those multiples. And note that the feature list stops partway through the official clients row, so the documentation site at manual.manticoresearch.com is where the current client roster and the SQL dialect live. What the repository does make clear is the shape of the thing: a database you talk to with SQL, licensed GPL-3.0, with 652 open issues against 12,026 stars and a release cadence of roughly one tag a month. ## FAQ ### What is Manticore Search? An open-source search database written in C++ that handles full-text, vector and hybrid search with real-time indexing and SQL. It is MySQL-compatible, so you query it with SQL through your preferred MySQL client instead of translating to a separate query language. ### How is Manticore Search different from Elasticsearch? The README positions Manticore as an alternative to Elasticsearch and reports it as 3.85x faster than a tuned Elasticsearch 9.4.3 on 100 million-plus Hacker News comments, and 2.02x faster on 1.7 billion NYC taxi rides. Those figures were measured against Manticore 27.1.5 while the current tag is release-29.9.0, so the comparison describes an older build. ### What is the difference between row-wise and columnar storage in Manticore? Row-wise storage is intended for small, medium and large datasets that fit in memory, while columnar storage, provided by the separate Manticore Columnar Library, is for datasets too large for RAM. Recent releases have concentrated on the columnar side, with memory-mapped attributes by default and faster KNN rescoring. ### How do you install Manticore Search? The README points to the downloads page at manticoresearch.com/install and the documentation at manual.manticoresearch.com rather than listing install commands in the repository. From source, the root carries a `configure` script and `CMakeLists.txt`, and the tree includes an `installer/` directory. ### Does Manticore Search support vector and hybrid search? Yes. Auto-embeddings with automatic chunking generate vectors from text and can split long documents into fixed-size, recursive or sentence-based chunks stored in a `float_vector_array`, and hybrid search combines full-text and vector retrieval in one query. Conversational search is available through SQL `CALL CHAT` and the HTTP JSON `/search` endpoint. ## Sources - [License: GPL-3.0](https://github.com/manticoresoftware/manticoresearch/blob/main/LICENSE) - [manticoresoftware/manticoresearch on GitHub](https://github.com/manticoresoftware/manticoresearch) - [Project website](https://manticoresearch.com) - [README](https://github.com/manticoresoftware/manticoresearch/blob/main/README.md) - [Releases](https://github.com/manticoresoftware/manticoresearch/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/manticoresoftware-manticoresearch