Open Semantic Search

Last reviewed Sep 13, 2026 · 762 words

Most people who land on Open Semantic Search want Paperless-ngx, and should run it instead. Paperless gives you OCR, full-text search and tagging for a household's worth of PDFs on 1 GB of RAM in an afternoon. Open Semantic Search is a different animal: an Apache Solr search engine wrapped in a text-mining pipeline, built for the person who has 200,000 documents from a records request, a newsroom leak or a research archive and needs entity extraction, faceted exploration and a thesaurus, not a filing cabinet. It needs 4 GB of RAM at minimum, and the listing's "Hard" is earned.

The stack under the hood

The project is a bundle rather than a single program, which is why the catalogue lists its language as Shell: the repository is mostly packaging and glue around Apache Solr for indexing and search, Apache Tika for pulling text out of roughly any file format, Tesseract for OCR, a Python enrichment pipeline that does named entity recognition and dictionary matching, and a Django web front end for the search UI and admin. Data flows in from a watched folder or a crawler, gets converted and enriched, and lands in Solr. Every one of those components consumes memory, and Solr on its own wants a couple of gigabytes of heap before it is comfortable.

What it does that a document manager does not

The search interface is faceted: after a query you can narrow by person, organisation, location, date, file type, and whatever custom lists you loaded. Named entity extraction populates those facets automatically from the text. You can load a thesaurus or a list of names and have every document that mentions any of them tagged, then get alerts when new documents arrive matching a saved search. There are graph views of which entities appear together. Annotation and manual tagging exist too, but the value is in the automatic layer. This is the toolset investigative journalists and archivists actually use, and there is no self-hosted equivalent at this price, which is zero.

Installation: Debian packages or Docker, and patience

The maintained routes are a .deb package set for Debian and Ubuntu, and a Docker Compose stack from the repository. Docker is the sane choice on anything but a dedicated box, because the package route installs Solr, Tika, Tesseract language packs and a pile of Python dependencies system-wide. Either way, budget an hour for the first index of a few thousand documents; OCR is CPU-bound, and Tika will choke on the occasional malformed PDF. Give the stack 4 GB as a hard floor and 8 GB if OCR and entity extraction run at the same time, and put the index on SSD.

Signs of age

The project started in 2014 and the release cadence has been slow. Expect an interface that looks its age, documentation that assumes you know Solr, and a small community: 1,208 stars and a handful of contributors. Nothing about that makes it unfit, but it does mean you will read Solr's own documentation when something misbehaves, and that a search stack built on OpenSearch or Elasticsearch plus your own ingestion scripts is a live alternative if you have the engineering time. Lighter search engines exist, but none of them ship the enrichment pipeline.

Who should actually run this

Three profiles: a newsroom or NGO handling a document dump; a researcher or historian with a scanned archive who needs to find every mention of every name; and a company with a legacy file share that nobody can search. The first two are the sweet spot. The third should look at document management tools first, since they want workflows and permissions rather than text mining. A household with tax returns and appliance manuals is not on the list; the Paperless-ngx guide covers that case fully.

What I'd do

If the archive is under 10,000 documents and the question is "where is that invoice", run Paperless-ngx and stop reading. If it is 50,000 or more, the documents are about people and organisations, and finding patterns across them is the job, deploy Open Semantic Search through Docker on a machine with 8 GB and a fast disk, load your name lists before the first import so the entities land in one pass, and accept that you are running Solr now. Keep the source documents outside the containers so a rebuild of the index is a nuisance rather than a loss.