Most libraries over-buy CPU and under-buy memory. Koha is not a demanding application by modern standards — a catalogue of a few hundred thousand records is a small database — but the way it uses memory surprises people, and the number that matters is almost never the one in the quote.
This article is the sizing conversation we have before an installation, written down. It names starting points, and more usefully it names what makes them move.
What actually uses the memory
Four things share the RAM on a Koha server, and only one of them is Koha's own code.
| Consumer | What drives it |
|---|---|
| Plack workers | Koha stays loaded in memory between requests. Each worker holds a full copy of the application, and there are several. This is the single largest consumer and the one nobody expects. |
| The database | MariaDB caches as much of the working set as you let it. More memory here is the cheapest performance you can buy. |
| The search engine | Zebra is modest. Elasticsearch is a Java service with an appetite of its own, and adding it to a small server is how a search upgrade makes a catalogue slower. |
| Everything else | Apache, memcached, the background worker, the operating system. |
The consequence is worth stating plainly: a Koha server does not get slow gradually when it runs out of memory. It starts swapping, and then a page that took 300 milliseconds takes eleven seconds. That is the failure mode people describe as "Koha is slow", and it is nearly always this.
CPU matters less than the invoice suggests
A library catalogue is not a compute problem. Cataloguing, circulation and OPAC searching are database and disk work, and they are handled comfortably by a small number of cores. Two things are the exception, and both are occasional: a full reindex, and a large import.
Those are worth sizing for anyway — not because they need to be fast, but because a reindex that takes four hours instead of forty minutes has to be scheduled around opening hours rather than simply run. That is an operational cost that shows up every year.
The disk is not full of records
This is the most common misconception in the whole conversation. Bibliographic records are tiny. A quarter of a million of them, with their items, is a database measured in a couple of gigabytes. Libraries routinely buy storage for a catalogue that would fit on a phone.
What actually fills a disk:
- Cover images and uploaded files — digitised documents, patron photos, attachments. These are orders of magnitude larger than the records they belong to.
- The search index — comparable in size to the data it covers, and rewritten rather than patched during a full rebuild, so you need headroom, not just space.
- Logs — small until something is looping, at which point they are not.
- Backups, if you keep them on the same machine — which you should not, and which is the subject of its own article.
Whatever you size the disk at, make it an SSD. Nothing else on this page changes the feel of the staff interface as much.
Three starting points
These are starting points from installations we run and have run, not benchmarks. Treat them as the shape of the answer, then measure your own.
| Library | Starting point | Notes |
|---|---|---|
| Small — school or college, under ~50,000 records, a handful of staff, modest OPAC use | 2 vCPU · 4 GB RAM · 40 GB SSD | Comfortable. Koha runs on less; you will not enjoy it during an import. |
| Typical university or public library — 100,000–500,000 records, 20–40 staff, a public OPAC | 4 vCPU · 8 GB RAM · 100 GB SSD | The most common right answer. Room for Plack workers and a database cache that actually caches. |
| Large or consortium — a million records and up, several member libraries, Elasticsearch | 8 vCPU · 16–32 GB RAM · 250 GB+ SSD | At this size, put the database and the search engine on their own hosts rather than buying one larger machine. |
Two adjustments apply to all three. Add memory before you add cores, every time. And if you are running Elasticsearch rather than Zebra, size for it deliberately — it is a separate service, not a setting.
What the numbers do not cover
Three costs sit outside the specification and are usually larger than the difference between any two rows in that table.
Backups need somewhere else to live. A backup on the same disk as the catalogue is a copy, not a backup. Budget storage on another machine, and — the part that gets skipped — budget the time to restore one and confirm it works.
Somebody has to patch it. A library server is on the public internet for the life of the catalogue. Security updates, certificate renewals and major version upgrades are recurring work whatever the hardware.
Something has to notice when it breaks. Most Koha failures are quiet: a scheduled job that stopped, an index falling behind, a disk approaching full. None of them announce themselves, and none of them are solved by a bigger server.
Growing later is easier than guessing now
On a virtual machine, memory and disk are a resize and a reboot. That is the practical reason not to agonise: start at the middle row, watch it for a month, and adjust with evidence instead of estimating. The mistakes that are genuinely expensive are architectural — putting the database across a slow network link, running on an operating system the packages do not support, or having no backup you have restored — and none of them are fixed by buying a larger machine.
If the reason you are sizing a server at all is that somebody has to run one, that is worth weighing separately from the specification. What hosting Koha actually involves month to month puts numbers against the other side of the same decision.