The database cannot read data written by another version

PostgreSQL Database directory appears to contain a database; Skipping initialization

2026-11-03 07:41:09.519 UTC [1] FATAL:  database files are incompatible with server
2026-11-03 07:41:09.519 UTC [1] DETAIL:  The data directory was initialized by PostgreSQL version 16, which is not compatible with this version 17.6 (Debian 17.6-1.pgdg13+1).

What it means

A database keeps its data in files whose layout belongs to one version. MySQL and PostgreSQL check that layout when they start, and stop when they find data they cannot read safely. The database does not start at all, so every plugin or mod that stores its data there (permissions, economy, logs, claims) fails to connect.

The data is usually fine. It is the wrong version of the database that is trying to open it.

Why it happens

• A downgrade (downgrade). The data was written by a newer version and an older one was started on it. MySQL only allows a downgrade between patch releases of the same series; PostgreSQL never opens data of a newer major version.
• An upgrade it cannot make (unsupported_upgrade).
  • PostgreSQL never upgrades its data across major versions by itself (16 to 17, for example): that takes pg_upgrade or a dump and restore.
  • MySQL upgrades in place from the previous series only. Data from 5.7 must go through 8.0 before 8.4 or later can open it.
• A moving image tag. On Docker, an image such as mysql:latest or postgres:latest jumps to a new major version when a new one is released. The next time the container is recreated with a freshly pulled image, the new version meets the old data.
• PostgreSQL 18’s image. From version 18 the official image keeps its data in a version-named folder (/var/lib/postgresql/18/docker) and refuses to start when it finds a former image’s data in /var/lib/postgresql/data.

How to fix

1. Back up the data folder first, as it is now, before you change anything. Do not delete it to make the database start: that throws the data away.
2. The quickest way back is to run the version that wrote the data. Pin the image to that version (for example postgres:16 or mysql:8.4) instead of latest, and start the database again. The log line names both versions when it can.
3. To move to the newer version, follow the database’s own upgrade path:
   • PostgreSQL: with the old version still running, export everything with pg_dumpall, start the new version on an empty data folder and load the dump with psql. pg_upgrade does it in place when both versions’ programs are installed.
   • MySQL: upgrade one series at a time (5.7 to 8.0, then 8.0 to 8.4), starting each on the data and letting it finish before the next. A dump with mysqldump loaded into the new version also works.
4. If the data came from a newer version than you want to run, restore a backup or dump taken with the older version instead.

In Perland

A server’s database sidecar is a MySQL or PostgreSQL container next to the server, created on the mysql:latest or postgres:latest image with its data in a Docker volume. When the image moves to a new major version and the container is recreated, the new version can meet the old data and this issue appears in the sidecar’s diagnosis (the stack’s diagnosis with service mysql or postgres). With backups on, each backup holds a dump of the database that you can download and load by hand.

References

• PostgreSQL: upgrading a cluster
• PostgreSQL: pg_upgrade
• MySQL 8.4: upgrading MySQL