Database age
Every WordPress site starts with a fresh database at installation. From then on, it travels with the site: through every update, every new plugin and theme, every move to another server. The database age is how long ago that was.
Why it matters
Section titled “Why it matters”An old database isn’t slow because of its age. But over the years, plugins and themes come and go, and many leave something behind: tables, settings that load on every page, scheduled tasks, extra data on posts and users. The older the database, the more of this has usually collected.
The age helps read the other values on the Database tab. Many autoloaded options, orphaned metadata or more tables than the active plugins explain are more likely leftovers in a database that’s ten years old than in one that’s ten months old.
What influences it
Section titled “What influences it”WordPress: The age goes with the database, not with the server or the files. A copy of the database, for a move or a staging site, keeps its age. A fresh installation into which the content is imported starts again at zero, and leaves the old leftovers behind.
In Permo
Section titled “In Permo”The Database created card is in System info, tab Database, under Database server. It shows how long ago the database was created, such as “7 years ago”, and in the notes the month and, when Permo can tell, the WordPress version it was created with, such as “March 2019” and “with WordPress 5.1”.
Permo takes the date from the oldest user account, because WordPress creates the first account at installation. If that account was deleted, the date is that of the oldest remaining one, so the database can be older than shown. The version comes from a value WordPress stores at installation and never changes afterwards. The value gives context; Permo doesn’t rate it.
If the date can’t be read, the card shows a dash and Can’t be read on this server.