Mattermost Upgrade Fails in staging environment due to Database Ownership and Migration Errors

Applies to:
Mattermost Self-Hosted • Customers testing upgrades in UAT/Staging environments using Production database copies • All supported upgrade paths

Summary

When testing a Mattermost upgrade in a Staging environment that uses a copy of the Production database, the upgrade may fail during server startup. This is often caused by a database ownership mismatch, where database objects copied from Production retain their original owner. If the staging Mattermost instance connects with a different PostgreSQL user, required upgrade migrations cannot be applied, and the server fails to start.

This article explains why this happens and how to resolve it before performing upgrade tests.

Problem

During an upgrade run in staging env, the Mattermost service may fail to start and show errors similar to:

failed to initialize platform: cannot create store:
failed to apply database migrations

Systemd and PostgreSQL logs typically show failed query execution, for example:

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_propertyvalues_create_at_id
ON PropertyValues(CreateAt, ID)

PostgreSQL logs clearly indicate the root cause:

ERROR: must be owner of table <table_name>

Why this happens:

• Production DB is copied into staging env.
• Table ownership remains assigned to the Production PostgreSQL user (for example: mmuser).
• The staging Mattermost service uses a different DB user (for example: mmstaging_user).
• When Mattermost attempts to run its database migrations (index creation, schema updates), PostgreSQL refuses the operation because the staging DB user does not own the table.

As a result, the upgrade cannot proceed and Mattermost does not start.

Solution

To allow the upgrade to complete successfully, database tables in staging env. must be owned by the same user Mattermost connects with in staging.

1. Identify the PostgreSQL user used by Mattermost in staging

Check:

• config.json
• system environment variables
• or System Console (if accessible)

Example:

mmstaging_user

2. Update ownership of all restored Production tables

Connect to PostgreSQL as a superuser (postgres) and reassign the objects to the staging DB user.

Recommended method (reassign everything at once):

REASSIGN OWNED BY <prod_user> TO <staging_user>;

To fix ownership for a specific table:

ALTER TABLE <table_name> OWNER TO <staging_user>;

3. Restart Mattermost

sudo systemctl restart mattermost

After ownership correction, Mattermost will successfully apply its database related steps and complete the upgrade.

Things to keep in mind before upgrading in staging

• This issue is common when organizations copy Production data into Staging/UAT for upgrade testing or troubleshooting.
• Mattermost database migrations require ownership privileges to create indexes, constraints, or schema updates.
• Ensuring proper table ownership before starting an upgrade prevents nearly all migration-related startup failures in staging env.