What is a PMS Database?

If you work on superyachts, you have heard the term PMS thrown around constantly. But there is a surprising amount of confusion about what a PMS database actually is, what it contains, and why the quality of the data matters far more than the software it sits in.

This article is a straightforward explanation. Whether you are a Chief Engineer inheriting a vessel, a captain trying to understand what your engineering team needs, or a management company evaluating your fleet's maintenance infrastructure — this covers the fundamentals.

What PMS stands for

PMS stands for Planned Maintenance System. It is the system a vessel uses to schedule, track, and record all maintenance activities across every piece of equipment onboard.

The concept is simple: instead of waiting for things to break, you maintain them on a planned schedule based on manufacturer recommendations, class requirements, and operational experience. Every piece of equipment has defined maintenance tasks at defined intervals. The PMS tracks what is due, what has been done, and what is overdue.

This is not optional. The ISM Code (International Safety Management Code) requires every commercial vessel to have a planned maintenance system. Classification societies audit it. Flag state inspections check it. Port state control can detain a vessel over it.

For superyachts operating commercially under the Large Yacht Code or MCA regulations, a functioning PMS is a regulatory requirement, not a nice-to-have.

The difference between PMS software and PMS data

This is where the confusion starts. People use "PMS" to refer to two very different things:

PMS software is the application — the platform you log into, the interface you click through, the system that sends notifications and generates reports. There are many options on the market, from basic to sophisticated, cloud-based to locally installed.

PMS data is the actual content inside that software — the equipment records, the maintenance tasks, the spare parts catalogues, the intervals, the hierarchies. This is the database.

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

You can have the most expensive PMS software on the market, but if the data inside it is incomplete, inaccurate, or poorly structured, the system is worthless. Conversely, a well-built database will work effectively on almost any platform.

When we talk about building a PMS database, we are talking about the data — creating the complete, structured dataset that makes a planned maintenance system actually work.

What a PMS database contains

A complete PMS database has three core components that work together:

Equipment hierarchy

This is the structured register of every piece of equipment on the vessel. Not a flat list, but a logical hierarchy that reflects how the vessel is actually built.

A proper hierarchy follows a structure like: vessel > system > sub-system > equipment > component. The main engine sits under Propulsion. Its cooling system sits under the main engine. The coolant pump sits under the cooling system. Every piece of equipment has a defined place in the structure.

This hierarchy is the skeleton of the entire database. Everything else — tasks, spare parts, documentation — hangs off it.

For a 50-metre yacht, you might have 400 to 800 individual equipment entries. For a larger vessel with complex systems, that number can exceed 1,500.

Maintenance tasks

Every piece of equipment has defined maintenance tasks with specific intervals. These come directly from the manufacturer's operation and maintenance manuals.

Each task includes: - What to do — a clear description of the maintenance action - Which equipment — linked to the specific component, not just the system - How often — the interval, whether hours-based, calendar-based, or both - Who does it — the department or role responsible - What is needed — tools, consumables, or spare parts required

A typical yacht database contains between 2,000 and 6,000 individual maintenance tasks. The range depends on vessel size, complexity, and how granular the manufacturer documentation is.

The critical point: every task must be linked to a specific piece of equipment, not to a system. "Service the generator cooling system" is not a useful task. "Replace raw water impeller — Generator No.1 seawater cooling pump" is.

Spare parts catalogue

Every spare part is linked to the specific equipment it serves. Part numbers, descriptions, recommended quantities, and manufacturer references — all connected to the equipment hierarchy.

When the engineer opens the record for a specific pump, they see every spare part for that pump. No guessing, no cross-referencing a separate spreadsheet, no calling the supplier to confirm a part number.

This linkage between spare parts and equipment is what turns a simple inventory list into a functional maintenance tool.

Why it matters for superyachts specifically

Superyachts are not like other commercial vessels. They have unique characteristics that make PMS database quality particularly important.

Compliance pressure

Between ISM Code requirements, classification society rules, flag state regulations, and MCA Large Yacht Code compliance, superyachts face extensive maintenance documentation requirements. A well-structured PMS database is the foundation for meeting all of them.

During a class survey or flag state inspection, the surveyor will review your planned maintenance records. If your database is disorganised, incomplete, or does not match what is actually onboard, that creates findings. Findings create delays. Delays cost money — especially if the vessel is on a charter schedule.

Operational complexity

A 50-metre yacht has the mechanical complexity of a small industrial facility compressed into a hull. Main engines, generators, hydraulic systems, HVAC, watermakers, stabilisers, sewage treatment, fire suppression, safety equipment, navigation systems, AV systems — the list goes on. And every system needs maintaining.

Unlike a cargo vessel running the same route with the same engineering team for years, superyachts change crew regularly. The Chief Engineer who set up the maintenance programme may not be the one running it six months later. The database needs to be clear enough that any competent engineer can pick it up and understand immediately what needs doing.

The cost of downtime

When a superyacht misses a charter because of a mechanical failure that should have been prevented by routine maintenance, the cost is measured in tens or hundreds of thousands. When the wrong spare part is ordered because the database had incorrect part numbers, that is a week of downtime waiting for the right one.

A good PMS database does not just tick a compliance box. It directly prevents expensive operational failures.

Common problems with poorly built databases

We see the same problems repeatedly when reviewing existing PMS databases on yachts. These are the patterns that make a database unreliable:

System-level tasks instead of equipment-level

"Service engine room ventilation system" — which fans? Which filters? Which dampers? Tasks linked to systems instead of specific equipment are vague, unverifiable, and create gaps where individual components get missed.

Missing or guessed intervals

Maintenance intervals set to round numbers ("every 6 months" or "every 1,000 hours") instead of extracted from the manufacturer's manual. Or worse, no intervals at all — tasks that exist but never come due because nobody set the schedule.

Unlinked spare parts

A spare parts list that exists as a separate document with no connection to the equipment hierarchy. The engineer has to manually search through a spreadsheet to find the right part number for a specific pump, filter, or valve. This is slow, error-prone, and leads to wrong parts being ordered.

Inconsistent naming

The same equipment called different things in different parts of the database. "Main Engine Port", "ME1", "M/E No.1 Port" — all referring to the same engine. When naming is inconsistent, the crew cannot trust search results, reports are unreliable, and equipment gets duplicated.

Copy-paste from other vessels

Tasks and equipment copied from a sister vessel or a template without being verified against what is actually installed. This creates phantom equipment in the database that does not exist onboard, and misses equipment that was actually fitted but was not on the template.

How a professional database differs from a DIY one

Many Chief Engineers attempt to build the database themselves. This is understandable — they know the vessel, they know what needs maintaining, and they have access to the manuals.

The challenge is time and methodology. A Chief Engineer running a vessel has maintenance to manage, crew to supervise, surveys to prepare for, and often guests onboard. Building a comprehensive database requires hundreds of hours of focused data extraction and structuring work.

What typically happens: the engineer builds the critical systems first (main engines, generators), gets most of the way through the vessel, then runs out of time. The remaining systems get skeleton entries or get skipped entirely. Naming conventions drift as the project stretches over months. The spare parts linkage never gets completed because it is the most time-consuming part.

A professional database build follows a defined methodology from start to finish. The equipment hierarchy is established and locked before any tasks are created. Naming conventions are documented and applied consistently. Every task is extracted from manufacturer documentation with correct intervals. Spare parts are linked to specific equipment. The entire dataset goes through quality assurance before delivery.

The result is a complete, consistent, verified database — not a partially finished project that the next Chief Engineer inherits and does not trust.

When vessels typically need a PMS database

New build delivery

The vessel is delivered from the shipyard and needs a complete database built from scratch. This is the ideal scenario because all documentation is current and available. Starting during the build phase, rather than after delivery, produces the best results.

Refit or major equipment change

Significant equipment has been replaced or added during a yard period. The existing database needs updating to reflect what is actually onboard now, not what was onboard three years ago.

Existing vessel with poor data

The vessel has been operating with an incomplete or unreliable database. The crew does not trust it. Surveys have raised findings. The decision is made to rebuild it properly rather than continuing to patch a broken foundation.

Migration between platforms

The vessel is changing PMS software and needs the data migrated and restructured. This is often the trigger for a complete database rebuild — rather than importing poor data into a new system, it makes more sense to build clean data and import that instead.

What happens next

If your vessel needs a PMS database — whether it is a new build, a rebuild, or a migration — the starting point is always the same: a clear understanding of the vessel and its documentation.

We work with Chief Engineers, management companies, and build teams to develop databases that are complete, accurate, and genuinely useful for the people who use them daily. Every database is built from actual OEM documentation, structured to industry standards, and reviewed by the crew before delivery.

You can learn more about how we work on our [services page](/services), or [get in touch](/contact) to discuss your vessel's specific requirements.