What Makes a Good PMS Database for a Superyacht?

Most superyachts have a PMS database. Very few have a good one.

The difference between the two is not about which software platform you use. It is about the data inside it. A well-structured database on any platform will outperform a poorly built one on the most expensive system available.

So what separates a good PMS database from a bad one? After building databases for yachts from 30m to 80m+, here is what we have learned.

The hierarchy is everything

The equipment hierarchy is the skeleton of your entire database. Get this wrong and everything built on top of it — maintenance tasks, spare parts, scheduling — will be compromised.

A good hierarchy reflects how your vessel is actually built. It follows a logical structure: vessel > system > sub-system > equipment > component. Every piece of equipment sits in one place, in the right place.

A bad hierarchy is a flat list. Equipment dumped into vague categories. "Engine Room Equipment" containing everything from the main engines to a bilge pump float switch. No structure, no logic, no way to find anything quickly.

What good looks like

A structured hierarchy aligned to shipyard documentation or an industry standard like SFI coding. Main engines under Propulsion, not under "Machinery." The watermaker under Freshwater Systems, not under "Miscellaneous." Every component traceable to its parent system.

What bad looks like

Equipment grouped by who maintains it rather than what it is. Tasks copied from a sister vessel with different equipment. Components listed at system level ("check main engine") instead of linked to the specific engine.

Naming conventions matter more than you think

Open most yacht PMS databases and you will find "Main Engine Port", "ME1", "Main Engine #1", "M/E No.1 (Port)", and "Caterpillar 3516" all referring to the same piece of equipment — sometimes within the same database.

Inconsistent naming makes the database unreliable. The crew cannot trust what they are looking at. Spare parts get ordered for the wrong equipment. Tasks get missed because they are filed under a name nobody recognises.

A good database uses standardised naming conventions applied consistently across every entry. One format for equipment names, one format for task descriptions, one format for spare part descriptions. Documented, agreed with the crew, and applied without exception.

Every task must link to specific equipment

This is one of the most common mistakes we see: maintenance tasks linked to a system instead of to specific equipment.

"Service main engine cooling system" linked to "1100 — Main Engines" tells the engineer nothing. Which engine? Which cooling circuit — high temperature or low temperature? What specifically needs to be done?

Every task should be linked to the individual component it applies to. "Replace coolant — HT circuit" linked to "1110.03 — Cooling System (HT)" on Main Engine No.1. Clear, specific, unambiguous.

This level of precision means the crew knows exactly what equipment each task relates to, can verify it was done correctly, and can order the right spare parts.

Intervals must come from the manufacturer

We regularly see databases where maintenance intervals have been guessed, copied from another vessel, or set to round numbers because "it seemed about right."

The correct approach is simple: extract every interval directly from the OEM operation and maintenance manual. Hours-based, calendar-based, or "whichever comes first" — exactly as the manufacturer specifies.

If the Caterpillar manual says to replace the fuel filter every 500 hours or 6 months, whichever comes first, that is what goes in the database. Not "every 6 months" because someone decided to simplify it. Not "every 1000 hours" because a previous engineer thought the manufacturer was being conservative.

Manufacturer intervals exist for a reason. They are based on engineering analysis, testing, and real-world operational data. Overriding them creates risk and liability.

Spare parts must link to equipment, not float in a list

A spare parts catalog that is not linked to specific equipment is just an inventory list. It tells you what is onboard but not what it is for.

In a properly built database, every spare part is linked to the specific equipment it serves. When the engineer opens the record for Generator No.1, they see every spare part for that generator — part numbers, descriptions, and quantities. No guessing, no searching through a separate spreadsheet, no calling the manufacturer to confirm a part number.

This linkage is what makes the difference between a database that helps the engineer and one that creates extra work.

The database should belong to the vessel

One of the most overlooked aspects of PMS database quality is ownership and portability.

If your database is locked inside a proprietary software platform with no way to export it, you do not truly own it. If you change PMS providers, you start from scratch. If the software company changes their pricing, you are captive.

A well-built database should exist as a standalone, portable asset. The vessel should always have a complete master reference file — typically an Excel workbook — that contains all equipment, maintenance, and spare parts data in a format that works with any system.

This is not about being anti-software. It is about ensuring the data you paid to build is yours to keep, regardless of which platform you choose today or in the future.

The crew should be involved

No database should be built in isolation. The people who use it daily — the Chief Engineer, the ETOs, the bosuns — need to review and confirm at key milestones.

The crew knows things that are not in any manual. They know that a particular pump runs hotter than expected. They know that a certain filter needs changing more often in tropical waters. They know which equipment has been replaced since the last refit.

A good database development process includes structured crew review milestones where the team confirms the hierarchy, validates the naming conventions, and reviews the maintenance tasks against their operational experience.

Summary

A good PMS database is: - Structured — logical hierarchy aligned to the vessel's actual build - Consistent — standardised naming throughout - Specific — every task linked to individual equipment, not to systems - Accurate — intervals from OEM documentation, not guesswork - Linked — spare parts connected to the equipment they serve - Portable — your data, in standard formats, belonging to the vessel - Crew-reviewed — validated by the people who use it

The software platform is just the container. The data is what matters.