When several libraries decide to share a catalog, they usually mean one of two quite different things — and the whole project follows from which one.
- A union catalog — one shared catalog that every member library works inside.
- Federated search — separate catalogs, with a search layer querying all of them.
These have different costs, different failure modes and a very different experience for patrons. Settle this before evaluating software — and before committing to a hosting arrangement, because a shared catalog changes what you need from it.
Union catalog versus federated search
| Union catalog | Federated search | |
|---|---|---|
| What patrons see | One catalog, all holdings | Results grouped by source, inconsistently |
| What staff maintain | One system | One system each, plus the search layer |
| Holds across members | Native | Manual, or not at all |
| Cataloging consistency | Enforced — shared records | Whatever each member does |
| Member autonomy | Reduced | Full |
| When a member is offline | Not applicable | Their holdings vanish from results |
| Total cost | Lower per member | Higher — every member runs a system |
Federated search preserves autonomy and is usually the politically easier sell. It is also more expensive and gives patrons a worse experience. Choose it because autonomy genuinely matters to your members, not because it avoids a difficult conversation.
Two kinds of sharing, often confused
Internal — one institution, several libraries
A university with a main library, a law library and a medical library; or a college with campus libraries. Each may have its own collection, its own patrons and its own branding, but they are one organisation with one policy-maker.
Koha handles this natively through branches, with per-branch circulation rules, holds with pickup locations and transfers.
External — independent institutions
Separate colleges or public library authorities choosing to share. Each has its own governance, budget and policies, and can leave. This is the harder case, and it is where most of the questions below apply.
One instance or many?
| One shared instance | One instance per member | |
|---|---|---|
| Cost per member | Low | High — every member pays for a full system |
| Cataloging consistency | Enforced | Divergent within a year |
| Patron experience | One catalog, one account | Separate catalogs and logins |
| Autonomy over settings | Negotiated | Total |
| Upgrade coordination | Once, for everyone | Every member separately |
| Lending between members | Native | Manual process |
| Leaving the group | Data extraction project | Straightforward |
The honest summary: one instance is cheaper and better for patrons; separate instances preserve independence and multiply every maintenance task by the number of members.
There is a third arrangement that avoids the worst of both: one shared catalog where each member keeps its own branded address and its own presence, with lending between members built into the system rather than bolted alongside it — so a borrowed item is a normal loan with normal fines and notices, and nobody runs a server. That is what consortium lending built in, not bolted on means in practice.
Shared authorities and cataloging standards
The unglamorous part that decides whether a union catalog is usable.
If members catalog to different standards, a shared catalog accumulates four versions of the same author and three of the same subject heading. Patrons find a third of what you hold.
Agree the standards before the first record is loaded: authority control, subject vocabulary, minimum record quality, who may edit shared records, and how disputes are settled. This is governance, not software, and no system will rescue a group that skips it.
Inter-library loans between members
The reason most groups form. A patron at one member requests an item held by another; it travels, gets issued, comes back.
What this needs from the system: a request record, transit tracking, a real loan against the borrowing patron, fines and notices behaving normally, and a return path.
Where the ILS does not support it natively, libraries fall back to spreadsheets and email — and the loan then exists in nobody's circulation record. Items go missing, nobody is charged, and the group quietly stops using the facility it formed to provide. See also our note on Koha for universities.
Holds and transfers across libraries
Decide in advance: which pickup locations a patron may choose, who pays for transport, how long an item may sit in transit before someone chases it, and who is liable if it is lost between members. That last question causes more consortium arguments than any technical issue.
Governance — settle this first
Most consortium failures are governance failures, not software failures. Agree in writing, before procurement:
- Who pays, and on what basis — per member, per patron, per item?
- Who decides shared settings when members disagree?
- Who catalogs, and to what standard?
- What happens to shared records if a member leaves?
- How does a member extract its own data?
- Who is liable for items lost in transit?
- How is a new member admitted?
Groups that answer these in advance succeed with almost any competent system. Groups that do not, fail with the best one available.
Is a union catalog right for your group?
- Do members genuinely want to lend to each other, or just to see each other's holdings? Seeing only is a much smaller project.
- Can members agree cataloging standards? If not, a shared catalog will disappoint everyone.
- Is there a body that can make binding decisions?
- Is transport between members funded?
- Are members willing to give up some autonomy for lower cost and a better patron experience?
Forming a consortium, or unhappy with an existing one? We implement union catalogs and consortium lending. Tell us how many members and how independent they need to be, and we will tell you what fits.