MA

Manticore Search

Fast, low-footprint database for search

Search Engines ★ 12k stars Medium setup GPL-3.0

Manticore Search is an open-source, easy-to-use database designed for search. It offers full-text, faceted and vector search with a small memory footprint and SQL-like query syntax.

Key features

  • Full-text and vector search
  • SQL and HTTP query interfaces
  • Low memory footprint
  • Real-time indexing

Pros & cons

Strengths

  • Lightweight and fast
  • SQL-friendly

Trade-offs

  • Smaller community than Elasticsearch

Manticore Search replaces

Last reviewed Aug 26, 2026 · 865 words

Manticore Search is what you reach for when you want Elasticsearch-grade full-text search but would rather write SELECT ... WHERE MATCH('...') over a MySQL connection than post JSON to a JVM with 2 GB of heap. It is C++, runs in 256 MB, descends from Sphinx (the fork dates from 2017), carries 12,000 stars and a GPL-3.0 licence, and behaves like a database rather than a search-as-a-service box. That last point is the one to hold onto: it is not the tool for typo-tolerant instant search on a 10,000-product shop, where Meilisearch or Typesense give you a better result in an afternoon. It is the tool for millions of documents, logs, facets, joins and vectors on hardware that would make Elasticsearch weep.

The MySQL protocol changes how you build with it

Manticore listens on 3 ports: 9306 speaks the MySQL wire protocol, 9308 is HTTP with JSON, and 9312 is the binary protocol older Sphinx clients use. The first one is the interesting one, because any language with a MySQL driver already has a Manticore client, and mysql -h 127.0.0.1 -P 9306 gives you a shell to it.

CREATE TABLE docs(title text, body text, tags multi, published timestamp);

INSERT INTO docs(id, title, body, tags, published)
VALUES (1, 'Reverse proxy showdown', 'Caddy, Traefik and nginx compared', (3,7), 1724630400);

SELECT id, title, WEIGHT() AS score
FROM docs WHERE MATCH('@title proxy') AND tags = 3
ORDER BY score DESC LIMIT 10;

Real-time tables accept inserts and are searchable immediately, which is what a self-hoster usually wants. The MATCH() syntax supports field targeting, phrase and proximity operators, and the ranking can be tuned per query. FACET clauses give you the counts-per-category sidebar that shops and archives want, in one query rather than an aggregation tree.

One container, one volume

services:
  manticore:
    image: manticoresearch/manticore:latest
    ports:
      - "9306:9306"
      - "9308:9308"
    volumes:
      - ./data:/var/lib/manticore
    ulimits:
      nofile:
        soft: 65536
        hard: 65536
    restart: unless-stopped

The file-descriptor limit is worth setting up front because the columnar storage opens many files, and the failure when you hit the default is confusing. Backups are handled by the bundled manticore-backup tool, which snapshots the tables consistently while the daemon runs, and replication between nodes exists if you outgrow one box. For a homelab, one box plus a nightly backup of /var/lib/manticore is plenty.

Vectors live in the same table as the text

A column declared as float_vector with knn_type='hnsw' gives you approximate nearest-neighbour search, and the query is a knn() clause in the same SELECT you already use, so hybrid keyword-plus-semantic search is a WHERE MATCH(...) AND knn(...) rather than two systems glued together. You compute the embeddings outside Manticore with whatever model you like and insert them alongside the document. For a personal document search or a RAG pipeline that also needs exact-term matches, that is a tidy setup; the practical guidance on which embeddings to use and how to avoid the common failures is in embeddings search in production.

Where it loses to the instant-search tools

Meilisearch and Typesense make typo tolerance, prefix matching and relevance defaults work with zero tuning, and ship a dashboard. Manticore has fuzzy matching and autocomplete features, but they are options you enable and tune per query rather than the default behaviour, and there is no admin UI in the box. If the job is "search box on a small site that forgives spelling", the instant-search tools win on time to a good result. If the job is "index 20 million log lines or 2 million articles and let people slice them", Manticore wins on memory, on SQL, and on facets. It also accepts Elasticsearch-style JSON writes, so log shippers like Filebeat, Logstash and Vector can feed it, which makes it a lightweight substitute for the ELK stack on a single node. The surrounding choices are laid out in the search category.

The licence question, briefly

GPL-3.0 on a search daemon matters less than it sounds: you talk to it over a network socket, your application does not link against it, and the GPL's copyleft does not reach across that boundary. Anyone weighing it against Elastic's licence terms for a product should read the Elasticsearch alternatives page, but for a homelab or an internal app the licence changes nothing.

What I'd do

For a site search under 100,000 documents, use Meilisearch and move on. Above that, or for anything log-shaped, or when the application already speaks SQL and you want facets and vectors without another service, run Manticore with the compose file above, create real-time tables, and index through the MySQL port from whatever language you already use. Set the file-descriptor limit, run manticore-backup nightly, and give it 1 GB rather than the 256 MB minimum so the columnar cache has room. It is the rare piece of search infrastructure that gets smaller and simpler the more you learn about it.

Compare Manticore Search

28 head-to-head comparisons.

Similar search engines apps