Typesense in practice: search that knows what it searches
AI-generated, human-reviewed
On most websites, search is the weakest part. That is rarely the fault of the search technology and almost always a matter of what it is given to work with. A CMS’s built-in search usually knows one kind of content — “page” — and ranks by how often a word appears in it. Search an art magazine for a gallery name and you get three articles that mention the gallery, but not the gallery itself.
For full-text search we have settled on Typesense, an open-source search engine you run yourself. This article covers what it does across three very different projects, why the real work sits in the data model, and how the same index lets a website answer questions instead of only returning links.
1. What Typesense is, briefly
Typesense is a small service running alongside the website. It keeps a copy of the content in memory and answers queries in a few milliseconds, typos included. Unlike the well-known cloud search products it runs on your own infrastructure: the content never leaves the building, and there is no usage-based bill.
The index is not a data set you have to look after. It is regenerated from the website, which makes it disposable — no backups, no migrations, and a rebuild whenever in doubt.
2. openDesk: search where the CMS has none
For the German Centre for Digital Sovereignty we built the openDesk website, deliberately lean, on a file-based CMS with no runtime database. That is good for operations and security, and bad for search: with no database, there is nothing to search across.
Typesense fills exactly that gap: the search index sits beside the website as its own service rather than in a database behind the CMS. Search on opendesk.eu filters by content type — blog, FAQ, product pages — and keeps the German and English versions apart. A bilingual site needs that: a search that mixes English hits into a German result list does not read as multilingual, it reads as broken.
The effort here is small because the content base is small. It gets interesting an order of magnitude up.
3. Monopol: when content is not just content
For Res Publica Verlag we run the Cicero and Monopol platforms. An art magazine is not a pile of articles. Alongside some 26,000 editorial pieces, Monopol carries several thousand exhibitions and events, several hundred venues — galleries, museums, art associations — and artist profiles.
These things have nothing in common beyond the language they are written in:
| Content type | What defines it |
|---|---|
| Article | Author, section, date, paywalled or not |
| Exhibition | Venue, city, run dates |
| Venue | City and kind of institution (gallery, museum, art association) |
| Artist profile | Name, linked coverage |
A classic full-text search throws all of that away. It knows one title and one text snippet per hit, and has to render an exhibition closing tomorrow exactly like a comment piece from 2019.
In search on monopol-magazin.de, every content type keeps its own fields. Results sit side by side grouped by type, each group with its own count. An exhibition shows venue, city and dates; a venue shows its city and what kind of institution it is; an article shows author and section — and whether it sits behind the paywall is its own field in the index, and therefore visible before the click.
That is the actual point of structured data in search. The search engine does not get better; what it can hand back does. The work is not in the installation but in deciding which fields belong in the index per content type, and which of them have to be filterable. That decision is editorial rather than technical, and it is best made before anyone writes a schema.
4. kontrollfeld.de: the same index answers questions
On this site we go one step further. The wordmark in the header is an input field: ask a question, get an answer in prose with pointers to the passages it came from. The mechanism behind it is Retrieval-Augmented Generation (RAG) — retrieve first, then phrase.
flowchart LR
A[Visitor's question] --> B[Typesense retrieves passages]
B -->|sources known immediately| C[Evidence is shown]
B -->|retrieved passages| D[Language model phrases]
D --> E[Answer with evidence]
Three things matter here, and all three are about the index rather than the model:
The index is cut into sections, not pages. A whole page in the index is useless for an answer: it arrives complete or not at all, and a citation points at best to the top of the page. Split into sections with their own headings, the citation lands on the passage that carries the claim.
The sources are known before the answer is. Once retrieval is done, what the answer will rest on is settled — long before the model has written its first sentence. So we show the evidence straight away. If the phrasing fails, the evidence stays on screen and the visitor still has something to work with.
The model only sees what retrieval found. That is the uncomfortable half. For a long time the question “Who owns Kontrollfeld?” got the answer that our content does not cover it — although the website says so plainly. The model was not at fault: the legal notice was missing from the corpus, so the model judged correctly on what it could see. Anyone running RAG debugs retrieval first and the prompt second.
Typesense matches words, not meaning. Search for “vehicle” and you will not find “car”. For a manageable content base that is tolerable, and the answer to gaps is better retrieval rather than an immediate jump to vector search. Where a vector store starts to pay off, and which one, we compared separately. And if content should be callable by AI assistants rather than merely readable, what belongs in front of it is a control layer, not an open search route — an MCP server of your own.
5. What it costs
Typesense is one more service to run, monitor and update, and the index lives in memory — that is the price of the response times. In exchange there is no usage-based billing, and the content stays on your own infrastructure.
The honest precondition is the other one. Search earns its keep where there is something to tell apart. At fifty pages, good navigation is enough. At 30,000 documents across four content types, search is the table of contents.
Takeaways
- Search is only as good as the data model beneath it. The work is in choosing the right fields per content type, not in setting up the engine.
- Structured data beats a flat list: when exhibitions, venues and articles keep their own fields, the result list can show what makes each hit what it is — and filter on it.
- Self-hosting is light here: one service, an index reproducible from the website, no backup duty, no usage-based bill.
- RAG stands or falls on retrieval. Index by section, show evidence before the answer, and when an answer is wrong, first check what the model was given to see.