Preparing for Matomo 6: Database changes, bot filters and recovery

Management Summary
The Matomo 6 beta outlines the preparation needed for the next major version change. For self-hosted installations, the main concerns are the server environment, a visits-table change and built-in filtering of unwanted traffic. A trial on a separate copy helps estimate duration and report effects. The beta supports preparation, but it does not automatically establish that a particular production installation is ready for the upgrade.
Contents
Preparation starts before the update
An analytics installation includes more than its interface. The database, extensions and archiving process need to work together. A major release is a useful opportunity for a contained trial with a recorded starting state.
The scope of this preview
This article covers the Matomo 6 beta released on 9 September 2026. Its requirements rise to PHP 8.1 and MySQL 8.0 or MariaDB 10.6. These are version minimums, not recommendations for an old patch level. Current security updates and compatibility of installed extensions still need checking before migration.
The visits table needs attention
The beta adds a consent column to log_visit in preparation for future consent-status tracking. This requires a table alteration; the column alone does not provide a finished consent feature. On a large installation, that operation can take time. A universal duration estimate would be unhelpful without knowing the data volume, database and hardware. A trial using a representative copy provides better evidence.

Filters can change the totals
According to the beta announcement, spam and bot filtering becomes built in and enabled by default. Different filtering can affect the visits included in reports. A before-and-after comparison therefore needs the configuration and change time recorded. A decline alone proves neither fewer genuine visits nor a fault.
A trial with a recovery path
Preparation includes a consistent database backup, configuration, application version and extensions. Restoration needs testing in a separate environment. The trial then covers the upgrade, archiving and selected reports. Simply restoring old application files is not a reliable recovery method after a database schema change.
What belongs in the record
Useful evidence includes database size, table inventory, schema-change duration, archiving outcome and selected report comparisons. Unexpected errors and plugin versions also belong in the record. Before treating a difference as a release defect, the review needs to establish whether data freshness, filtering or calculation changed.
Measurement Summary
The proposed checks measure schema-change and archiving duration and compare reports with recorded filter settings. Runtime depends on the installation. This is a documentation-based preparation guide for the beta, not an independently measured upgrade benchmark.
Questions and answers
Is Matomo 6 described here as a stable release?
No. This article explicitly covers the published beta. The current release status needs checking before a production upgrade.
Is a backup of application files enough?
A reliable recovery path also needs a consistent database backup and the corresponding configuration.
Does a traffic decline after upgrading mean an outage?
Not necessarily. Changed filtering can alter the visits included in reports. Data freshness and configuration require comparison first.
Tools and further reading
The backup planner helps with retention and transfer windows. Actual recoverability still needs a separate restoration test.
- Backup Retention & Transfer Window Planner
- Matomo vs. GA4 in Enterprise Environments: When to Choose Self-Hosted Analytics?
- Bot Detection: IP Lists and Cryptographic Signatures Compared


