A preventive maintenance database is four tables whether it lives in a spreadsheet, a Microsoft Access file inherited from a predecessor, or a subscription product. Assets, tasks, schedules and completions. Sites that get the shape right can move between tools without losing anything; sites that get it wrong, usually by flattening tasks into assets or completions into schedules, end up with data that cannot answer the questions they built it for. This page is the shape, and it is worth reading before choosing any tool because it is what you will be loading into it.
Assets, one row per physical thing
With location, make, model, and what has to be isolated. The temptation is to add columns for the tasks it needs; resist it, because an asset with four task columns cannot have five tasks and the fifth ends up in a notes field where nothing can find it.
Tasks, one row per thing that gets done
Belonging to an asset, with an interval and a duration. Separating tasks from assets is the single structural decision that makes the rest work: it lets one asset have any number of tasks on different intervals, which is what real plant needs.
Schedules, generated, not typed
The next due date for each task, derived from the interval and the last completion. Typing due dates by hand is where drift enters, and it is what makes a spreadsheet unmaintainable at about a hundred tasks.
Completions, one row per job done, with findings
The table everything is actually for. Asset, task, date, person, hours, and what was found. On the worked example this site publishes, this table is where the 66 monthly hours and the reactive share both come from, and a database without it can schedule but can never learn.
Questions people ask about preventive maintenance database
Can a spreadsheet hold this shape?
Yes, with four sheets and lookups, and plenty of sites run it that way successfully. It stops scaling when several people need to write to it at once.
What about a Microsoft Access database?
Common and workable, and the usual risk is that one person built it and nobody else can change it. Document the shape, whatever the tool.
Do we need parts on this?
Only if you hold them. Adding a parts table without a stores process gives you a list that goes stale, which is worse than not having one.