How Do Botanical Garden Collection Management Databases Differ in Scope and Approach?
Collection management databases for botanical gardens and arboreta are not all built for the same job. The biggest divide is between systems designed specifically for living collections (plants in the ground, glasshouse, or nursery) and systems built for preserved specimens (herbarium sheets, spirit collections, seed bank vouchers). A second divide runs between all-in-one platforms and modular or open-source tools that you assemble yourself. Which side of those divides you land on depends on what you actually need to record, who needs to see it, and how much internal technical capacity you have.
Start With the Record Types You Manage
Before comparing products, list what your garden actually tracks. Most living-collection systems are organised around a small set of interlocking records:
- Accession — the permanent number given when plant material enters the collection, usually with source, date, and material type (seed, cutting, division, wild-collected).
- Taxon / name — the scientific name, including synonyms and name changes as taxonomy is revised.
- Provenance — where the material came from: wild origin with locality data, another garden, a nursery, or unknown.
- Plant / individual — the specific plant or group of plants derived from an accession.
- Location — bed, grid reference, garden area, glasshouse bay, or map coordinates, plus a history of moves.
- Propagation and events — sowing, germination, potting on, deaths, deaccessions, and material sent to other institutions.
If your records are mostly herbarium sheets with label data and storage locations, a preserved-specimen database will fit better. If your records are mostly "this tree, in this bed, from this wild locality," you need a living-collection system. Many gardens run both, which is why integration between the two matters.
Living-Collection Platforms vs General-Purpose Databases
| Approach | Typical strengths | Typical limits |
|---|---|---|
| Living-collection-specific platform | Accession/plant/location model built in; mapping and label printing; public sharing features | Less flexible for non-plant records; may be tied to one vendor |
| General-purpose database (e.g. a relational database or collections CMS) | Highly customisable; can hold any record type | You build the plant model yourself; more maintenance and staff skill needed |
| Preserved-specimen / herbarium system | Strong taxonomic and specimen-label standards | Weak on living-plant locations, propagation, and garden mapping |
| Spreadsheets | Zero cost, familiar | No relational integrity, poor for public sharing, breaks down past a few thousand records |
The practical question is not "which is best" but "how much of the living-collection model do I want to build versus buy?" A platform that already understands accessions, individuals, and locations saves months of design work. A general-purpose tool gives you freedom but shifts the burden onto your staff.
How Public Sharing and Secure Access Shape the Choice
Gardens increasingly publish collection data — on websites, in plant-finding tools, or through biodiversity networks. This creates two requirements that a plain database often misses:
- A public-facing view that shows what you want shown (often taxon, general location, provenance summary) without exposing sensitive data such as exact coordinates of rare species.
- Role-based access so that curators, horticulturists, volunteers, and the public see different things.
When evaluating a system, ask specifically: can I mark fields as public or private? Can I publish a subset without exporting and re-importing? Can I restrict who edits versus who only views? Systems that treat public sharing as an afterthought usually mean manual exports and a second copy of your data to maintain.
Adaptability and Cost Structure
Cost and flexibility tend to trade off in predictable ways:
- Configuration-based platforms let you rename fields, add picklists, and adjust forms within the product. This is cheaper and faster, but you accept the vendor's underlying model.
- Custom development gives you exactly what you want, but you pay for it up front and again at every upgrade.
- Open-source tools remove licence fees but not costs — hosting, upgrades, security, and staff time are real expenses.
Be wary of comparing only licence prices. Total cost includes data migration, training, ongoing support, and the staff hours to keep records clean. Ask each vendor or project how upgrades are handled and whether your customisations survive them.
Practical Evaluation Criteria
Work through these before committing:
- Data migration — can you import existing records from spreadsheets or an old system, and who does the mapping?
- Staff skill level — will your team manage it, or do you need a database administrator?
- Long-term maintenance — who fixes problems in five years? Is there a user community or paid support?
- Standards — does it support accepted taxonomic and provenance conventions, and can it exchange data with other institutions?
- Public sharing — can you publish securely without duplicating data?
- Exit plan — can you export everything in a usable format if you switch?
A Reasonable Way to Decide
If your priority is getting living-collection records under control quickly with limited technical staff, a living-collection-focused platform is usually the lower-risk choice. If you have unusual record types, strong in-house technical capacity, or a mandate to integrate with a broader institutional database, a modular or general-purpose approach may serve you better. If you mainly hold preserved specimens, choose a specimen-oriented system and treat living plants as a separate concern.
Whichever route you take, pilot with a real subset of your data — a few hundred accessions, including messy provenance and a few name changes — before signing anything. The system that handles your messiest records gracefully is the one worth keeping.