If Zebra is working and nobody is complaining about search, stay on Zebra. If your catalogue is large, your patrons complain that they cannot find things they know you own, or you want facets and relevance you can actually tune — Elasticsearch is worth the second service it costs you to run.
That is the whole answer. The rest of this is why, because the decision is one of the few in Koha that changes what a library has to operate rather than only what it has configured.
What each one actually is
Zebra is a specialised bibliographic index. It was designed for library data, it has been Koha's default for the whole life of the project, and it is included: no separate service to install, tiny memory footprint, and it will run on the smallest server you would put a catalogue on.
Elasticsearch is a general-purpose search engine. It is a separate Java service with its own port, its own memory, its own upgrade cycle and its own operational failure modes. Koha talks to it over the network, even when "the network" is localhost.
That difference — a library included in Koha versus a service beside Koha — is the entire trade, and everything below follows from it.
Where the difference is visible to patrons
| Zebra | Elasticsearch |
|---|---|
| Relevance ranking is basic. Results are ordered in a way that is defensible and rarely what a patron expected. | Modern relevance ranking, and you can weight fields — title above notes, for example — from the staff interface. |
| Facets are limited and fixed. | Facets are richer, and which fields produce them is configurable. |
| Typos find nothing. | Fuzzy matching finds the record anyway, which for patron-facing search is the single most noticeable improvement. |
| Non-Latin scripts and diacritics work, with limits that are hard to adjust. | Analyzers are configurable per language, which matters a great deal for some collections and not at all for others. |
| Fast on a small catalogue. Slows noticeably at scale. | Designed for scale; the difference shows on large catalogues and complex queries. |
The row that decides it for most libraries is the typo row. Patrons do not phrase queries the way cataloguers phrase records, and a search that returns nothing reads to them as "the library does not have it".
What Elasticsearch costs
Four things, and none of them are the licence — it is free.
Memory, and a real amount of it. Elasticsearch is a Java service that expects heap of its own. Adding it to a server that was comfortable running Zebra is the most common way a search "upgrade" makes the whole catalogue slower. If you are sizing this, how much server Koha actually needs covers what to add.
A new single point of failure. With Zebra, a search problem is a Koha problem. With Elasticsearch, an unreachable search host means searching stops while Koha and the database are entirely healthy. That is a new thing to monitor, and it needs to be monitored, because the catalogue does not announce it.
Version discipline. Each Koha release supports a particular range of Elasticsearch versions. Upgrading either one is now a question about the other, and an unsupported combination does not fail politely — it connects and returns wrong results.
A first index build. Reading every record and writing it into a new index is hours on a large catalogue, and it is heavy while it runs.
So who should actually switch?
Switch if your catalogue runs to hundreds of thousands of records and search feels slow; patrons regularly cannot find things you know you hold; you want to tune relevance or facets rather than accept them; or you run a union catalogue across several member libraries, where result quality across a large mixed corpus is exactly what Elasticsearch is good at.
Stay on Zebra if the catalogue is small and search is fast; nobody is complaining; your server is modest and you would be taking memory from the database to fund it; or — the honest one — there is nobody whose job it is to notice a stopped service at 8am. Zebra's great virtue is that it is one less thing that can be down.
The switch is reversible, which changes the risk
This is the part that should make the decision easier than it feels. Turning Elasticsearch on does not turn Zebra off: the setting is a single system preference, the records themselves are in the database and are not touched, and switching back is changing that preference back.
So the sensible approach is not a long evaluation. It is to build the index, switch, and give it a fortnight with real staff and real patrons — and if it is not better for your collection, switch back and lose nothing but the indexing time. The step-by-step procedure, including the index-name mistake that quietly merges two libraries' catalogues, is in switching Koha from Zebra to Elasticsearch.
One thing worth checking first
A surprising share of "our search is bad" reports are not about the search engine at all. If records can be opened directly but never appear in results, the index is simply stale — and that is true on either engine. Before changing anything architectural, rebuild the index you already have and see whether the complaint survives. Sometimes the answer is a scheduled job that stopped running months ago, and no amount of new infrastructure fixes that.