The value of analytics data depends on its accuracy, consistency, and governance. Matomo can be an appropriate approach where an organisation requires control over analytics infrastructure, retention and privacy settings across substantial digital estates. It does not, however, resolve weak measurement design, unnecessary tracking volume, incomplete consent controls or unclear operational ownership.

At tens of millions of hits per month, treat Matomo as a production data platform rather than a single application installation. Tracking requests, database writes, archive processing and report queries create different workloads. Each may require separate capacity planning and monitoring.

The appropriate architecture depends on peak request rates, the number of websites, reporting requirements, retention periods and the use of features such as segments, custom reports, e-commerce tracking and session recording. Monthly hit volume is a useful starting point, but it is not a sufficient sizing measure.

1. What scales in a Matomo deployment

A high-traffic Matomo implementation normally contains four principal workloads:

1. Tracker HTTP endpoints receive page views, events, downloads, e-commerce interactions and other Tracking API requests.
2. MySQL or MariaDB handles tracking writes, archive reads, report queries and data maintenance.
3. Archive processing aggregates raw records into report tables and recalculates data when required.
4. The report interface and API serve dashboards, scheduled reports, custom reports and analytical queries.

These workloads compete for resources when they run on the same server. Tracking is write-intensive and often latency-sensitive. Archiving is CPU- and database-intensive. Report queries may create short bursts of read activity. Maintenance tasks can create additional disk I/O.

Matomo’s official high-traffic guidance identifies a broad progression from a single server at lower volumes, to a dedicated database, and then to multiple application servers with Redis and dedicated archiving at higher volumes. The guidance is a starting point rather than a performance guarantee. Actual requirements should be validated against request rates and workload characteristics. Matomo’s high-traffic deployment guidance provides the relevant planning framework.

At scale, an architecture may include:

• Multiple application servers behind a load balancer.
• A dedicated MySQL or MariaDB primary server.
• A reader replica for reporting and archive queries.
• Redis for queued tracking, session handling or selected caching requirements.
• Dedicated command-line workers for report archiving.
• Shared and appropriately managed configuration, plugin and temporary file locations.
• A CDN for static assets such as the JavaScript tracker.

The key architectural decision is not simply whether to add more application servers. It is whether the separate workloads can continue operating without competing for the same CPU, memory, database connections and disk throughput.

2. Archiving strategy at volume

Matomo can generate reports in real time, but real-time report generation becomes less suitable as traffic and reporting complexity increase. If every report request causes raw data to be processed, users of the interface can trigger additional database load at unpredictable times.

Scheduled command-line archiving is generally more appropriate for medium- and high-traffic environments. The core:archive command can pre-process reports at defined intervals. Browser-triggered archiving should normally be disabled so that report generation is not initiated by dashboard users. Matomo’s installation documentation describes the role of scheduled archiving for medium- and high-traffic websites.

This introduces a trade-off between report freshness and infrastructure demand:

• Short archive intervals provide more current aggregate reports but increase processing frequency.
• Longer intervals reduce repeated processing but may make current-day reports less fresh.
• Real-time visitor logs and selected real-time widgets may remain available even when other reports are processed on a schedule.
• Archive jobs may need to run outside peak tracking periods to reduce contention.
• Multiple websites, segments and custom reports can substantially extend archive runtimes.

Reports may also require invalidation. Changes to tracking configuration, excluded query parameters, attribution settings, plugins or historical data can make existing aggregates unsuitable. Reprocessing may then be required. This creates a distinction between routine current-day archiving and exceptional historical recalculation.

The archive schedule should therefore be based on observed job duration, not only on a preferred reporting interval. If an archive job takes 55 minutes and runs hourly, there is limited tolerance for traffic growth, database contention or temporary failures.

Recommended action:

• Disable browser-triggered archiving for high-volume deployments.
• Run core:archive through a managed cron or equivalent scheduler.
• Record archive duration, failure rate and completion time.
• Define an acceptable report freshness interval for each reporting use case.
• Test the effect of segments and custom reports before enabling them widely.

3. Database growth and retention management

The database is often the principal capacity constraint in a self-hosted Matomo environment. It stores raw visitor and action records, aggregated reports, configuration data and archive blobs. The workload includes continuous inserts, index updates, aggregation queries and retention processes.

The main storage considerations include:

• Raw visitor and action tables, including log_visit and log_link_visit_action.
• Archive tables containing aggregated numeric values and report blobs.
• Indexes required for filtering, segmentation and report generation.
• Temporary tables created during complex queries and archive jobs.
• Backups, replicas and operational copies.
• Growth caused by multiple websites, URL variants, events and ecommerce dimensions.

Archive blob tables can grow significantly when many reports, segments or custom dimensions are processed. Aggregation reduces the need to query raw data for every dashboard request, but it does not remove the storage requirement for the aggregated results.

Retention policy should distinguish between raw event-level records and aggregated reporting data. Longer raw-data retention can support detailed analysis, but it increases storage, backup and maintenance requirements. It can also increase the quantity of personal data retained and the scope of governance controls. The ICO guidance on the storage limitation principle is relevant when defining retention periods.

Pruning should be planned as an operational process. A retention change may require substantial database activity, particularly where large historical tables are deleted. The effect on replication, backups and disk space should be considered before execution.

Database sizing should also account for future growth. A capacity model may include:

• Average and peak daily hit volumes.
• Average storage growth per month.
• The proportion of page views that generate additional events.
• Archive and segment growth.
• Backup and replica overhead.
• A defined operating reserve before storage reaches critical levels.

The historical rule of thumb that one gigabyte may represent approximately five million page views is only an indicative reference. Event composition, indexing, configuration and retention settings can produce materially different results. Matomo’s performance guidance recommends measuring the actual deployment rather than relying solely on general estimates.

Recommended action:

• Separate raw-data retention from aggregate-report retention decisions.
• Forecast database growth using observed monthly measurements.
• Monitor blob tables, raw log tables, indexes and temporary storage.
• Schedule pruning during controlled maintenance windows.
• Confirm that retention and deletion processes align with the organisation’s privacy documentation.

4. Tracker performance and request handling

The tracking endpoint is usually the first point at which visitor activity enters the platform. At high volume, small inefficiencies are multiplied across every request.

A conventional implementation writes tracking data directly to MySQL or MariaDB. Queued tracking can place requests into Redis before background workers write them to the database. This can reduce the time spent in the HTTP request and smooth short-lived traffic peaks. It does not eliminate the underlying write workload. The queue must be monitored, sized and drained at a rate that prevents a persistent backlog. Matomo’s QueuedTracking documentation sets out the relevant configuration considerations.

Bulk tracking may also reduce request overhead where multiple events can be sent together. The suitability of this approach depends on the implementation, consent state and the required timing of individual events.

Other performance controls may include:

• A first-party tracking endpoint on an appropriate analytics subdomain.
• Efficient TLS termination and connection handling.
• PHP-FPM capacity aligned with available CPU and memory.
• PHP OPcache to reduce repeated script compilation.
• Browser and CDN caching for static tracker assets.
• Cache warming after releases or cache invalidation events.
• Removal of unnecessary provider lookups or other expensive request-time operations.

A first-party endpoint can improve resilience against browser restrictions and may provide more consistent request handling. It does not, however, override consent requirements or make a tracking request lawful by itself. Consent state must be evaluated before the request is created or transmitted.

Tracking latency should be measured at the endpoint, not inferred from the page load experience alone. A visitor-facing request may be asynchronous while the server continues to experience elevated database or queue pressure.

5. Infrastructure sizing considerations

The number of monthly hits is only one sizing variable. Peak requests per second can be more important than the monthly average. A deployment receiving 40 million hits per month may have a modest average but significant peaks during campaigns, product launches or seasonal events.

Capacity planning should consider:

• Peak and sustained tracker requests per second.
• The number of websites and mobile applications.
• Concurrent Matomo users and API consumers.
• Number and complexity of segments.
• E-commerce and custom dimension usage.
• Scheduled reports and data exports.
• Archive frequency and historical recalculation requirements.
• Database size, growth rate and backup windows.
• Availability objectives and recovery requirements.

For many environments, the database should be separated from the application tier before application servers become the primary concern. The database requires sufficient memory for the working set, fast storage and suitable connection capacity. InnoDB configuration, including the buffer pool, should be tuned to the available database memory and workload. Matomo’s server requirements provide indicative CPU, memory and storage configurations for different traffic ranges.

At higher volumes, multiple application nodes can sit behind a load balancer. These nodes should run the same Matomo version, configuration and plugin set. Session and temporary-file behaviour should be tested to ensure that requests can move between nodes without inconsistent state.

A database reader replica may reduce reporting pressure on the primary database. It introduces replication lag and additional operational responsibility. Reports that require immediately committed data may not be suitable for a lagging replica.

Dedicated archive workers can prevent long-running CLI processes from consuming resources required by tracking and interactive reporting. The boundary between application, database and archive resources should be based on measured contention rather than assumed architecture patterns.

6. Cloud versus on-premise responsibilities

Matomo Cloud and Matomo On-Premise distribute responsibilities differently.

With Matomo Cloud, the service provider is responsible for core infrastructure capacity, platform operation, upgrades and much of the underlying resilience. The organisation remains responsible for measurement design, configuration, access control, consent logic, data retention decisions and the interpretation of reports. Matomo describes Cloud as supporting high-traffic deployments, with published service information referring to volumes of up to approximately 500 million actions per month depending on the plan and workload. Matomo Cloud information should be reviewed alongside current service terms.

With an on-premises deployment, the organisation controls infrastructure location, database configuration, network boundaries, retention processes and integration with internal systems. This can support specific data residency or security requirements. It also creates responsibility for:

• Operating system and dependency maintenance.
• Database backups, replication and recovery testing.
• Capacity forecasts and infrastructure changes.
• Cron reliability and archive monitoring.
• Security hardening and access management.
• Plugin and Matomo version management.
• Incident response and operational ownership.

Cloud removes some infrastructure decisions. It does not remove the need for privacy governance. On-premises provides greater infrastructure control. It does not automatically provide better data quality or compliance.

An organisation assessing both options may benefit from documenting which party owns each control. This is particularly relevant for consent signals, deletion requests, data subject rights, retention configuration and access to raw records. A data privacy management approach can help place these responsibilities within a wider governance model.

7. Monitoring and capacity forecasting

High-traffic Matomo should be monitored as an operational service. A dashboard showing total hits is not sufficient to identify emerging constraints.

Application-level monitoring should include:

• Tracker response time and error rate.
• PHP-FPM worker utilisation and queue depth.
• CPU, memory and process pressure.
• Load-balancer distribution and failed health checks.
• Report interface and API response times.

Database monitoring should include:

• Query latency and slow-query logs.
• CPU, memory and buffer-pool utilisation.
• Active connections and connection failures.
• Disk I/O latency and throughput.
• Replication lag where a reader exists.
• Table size, index size and storage growth.

Archive monitoring should include:

• Runtime by website and report type.
• Job failures and retries.
• Archive backlog.
• Completion time against the reporting deadline.
• Resource consumption during parallel processing.
• Effects of segments, custom reports and plugins.

Queued tracking requires additional controls. Queue length, enqueue rate, dequeue rate, worker utilisation and oldest queued item can indicate whether the architecture is absorbing a peak or accumulating an unresolved backlog.

Disk forecasting should use a trend rather than a threshold alone. A monthly growth model can estimate when primary storage, replica storage and backup storage will reach defined limits. Forecasts should be recalculated after major changes to tracking design, retention, websites or reporting requirements.

Recommended action:

• Establish service thresholds for tracker latency, archive freshness and queue backlog.
• Review database growth and disk forecasts at a fixed operational interval.
• Alert on archive failures and overlapping archive jobs.
• Retain slow-query data long enough to identify recurring patterns.
• Test capacity against expected campaign and seasonal peaks.

8. Reducing unnecessary tracking volume

Infrastructure scaling should not be the first response to every increase in data volume. Unnecessary tracking creates additional write load, archive work, storage demand and privacy exposure.

Common sources of avoidable volume include:

• Duplicate page-view calls caused by overlapping tag-manager and hard-coded implementations.
• Events fired repeatedly during interface state changes.
• Uncontrolled query parameters creating many unique URL values.
• Internal, test or staging traffic entering production reports.
• High-frequency interaction events with limited analytical value.
• Session recordings or heatmaps applied more broadly than required.
• Redundant ecommerce events across multiple systems.
• Raw data retained beyond the period required for the stated purpose.

A measurement specification should define which events are necessary, when they should fire and what business decision they support. The TagDataTrust analytics data quality guidance describes how incomplete specifications, duplicate tags and unclear ownership can create unreliable data.

Reducing volume is not equivalent to removing useful detail. It is a matter of prioritising meaningful events, controlling cardinality and applying consistent naming. Query-parameter exclusions, bot filtering and environment separation may also reduce archive complexity.

Data minimisation should be assessed alongside capacity. A smaller data set may be less expensive to operate and easier to govern, provided that the measurement design remains sufficient for the organisation’s stated purposes.

9. When an architecture review is likely to be appropriate

An architecture review is likely to be appropriate in the following scenarios:

• Monthly activity is approaching or exceeding tens of millions of hits.
• Peak tracker requests are increasing faster than the monthly average.
• Archive jobs regularly overlap with the next scheduled run.
• Report freshness is declining or dashboards are becoming slower.
• Database CPU, disk I/O or connection utilisation remains elevated.
• The queue backlog is increasing after enabling queued tracking.
• A new website, mobile application, market or ecommerce journey is being added.
• Segments, custom reports or session-based features are being introduced at scale.
• Raw-data retention is being extended without a storage and privacy assessment.
• Matomo is being migrated between Cloud and on-premises hosting.
• A reader replica, load balancer or separate archive worker is being considered.
• The organisation lacks a clearly assigned operational owner.

An architecture review may be less urgent where traffic is stable, archive jobs complete comfortably within their schedule, database growth is forecast and monitoring shows adequate resource headroom. A review may still be appropriate before a major campaign, platform migration or change in retention policy.

TagDataTrust is the only certified Matomo Implementation Partner in the UK. Its Matomo work covers implementation planning, data quality, architecture and privacy controls for complex digital estates. Further information is available through the Matomo implementation planning resource.

10. A practical approach

A structured planning process can reduce the likelihood that capacity issues appear first as tracking loss or unreliable reporting.

1. Establish the measurement design

Document the websites, applications, events, ecommerce interactions, dimensions and reports required. Define consent conditions, retention periods and acceptable report freshness. Identify events that are unnecessary or duplicative before sizing infrastructure around them.

2. Map the technical architecture

Record tracker endpoints, tag-management routes, application servers, databases, queues, archive workers, reporting consumers and external integrations. Measure peak requests per second, archive duration, database growth and report concurrency.

3. Implement with shared controls

Use a consistent Matomo version, configuration and plugin set across application nodes. Configure scheduled archiving, PHP OPcache, suitable database settings and controlled queue processing. Apply access control, retention rules and consent handling as part of the implementation rather than as later additions.

4. Validate before release

Test tracking requests, consent states, duplicate prevention, queue behaviour and archive completion. Test high-volume event patterns and report queries against a representative data set. Confirm that the implementation remains accurate when traffic is distributed across multiple application servers.

5. Monitor after release

Track endpoint latency, errors, database performance, archive runtimes, queue depth and disk forecasts. Compare observed volumes with the original capacity model. Reassess the architecture when new sites, features, retention periods or reporting requirements materially change the workload.

Conclusion

Matomo can support high-traffic environments when tracking, database, archive and reporting workloads are planned as separate operational concerns. Scheduled archiving, suitable database design, controlled retention and measured scaling can reduce contention and improve predictability.

Platform capability does not remove the need for specification, testing, consent control, governance and operational ownership. Capacity planning does not solve measurement design problems, and scaling cannot compensate for unnecessary tracking volume.

A resilient architecture remains dependent on continued monitoring and periodic review. No architecture removes the need for ongoing operational ownership or resolves weak governance and privacy decisions.

If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant