Appwrite API container v1.5.x compatibility with MariaDB schema migrated by v1.6.x migrations

Interoperability boundary

The self-hosted Appwrite stack pins its release through the _APP_VERSION variable in the generated .env file, while persistent state — especially the MariaDB data volume — survives container replacement. An upgrade runs docker compose exec appwrite migrate inside the new API container, which applies forward-only schema changes to that volume.

Unresolved behavior

Appwrite documents no downgrade migration path. If the upgrade fails after migrations have partially or fully altered the schema, the operator must decide whether to restore the MariaDB volume from a pre-upgrade backup or attempt to start the previous API container against the already-migrated schema. The project does not define whether an older API release can safely read or write a schema produced by a newer release, nor does it specify which metadata tables or columns the older code expects to be absent.

Goal

Establish whether a rollback to the prior Appwrite version is viable without a full volume restore, and what verification steps would confirm safe operation.

• Does the previous Appwrite API container start and serve requests against a MariaDB volume that has already been migrated by the newer release?
• If it starts, which functional areas (auth, databases, storage, functions) exhibit data-corruption risk or silent failures?
• Are there version-pair-specific constraints (e.g., v1.5.x → v1.6.x vs. v1.4.x → v1.6.x) that change the answer?