Matomo: self-hosted web analytics that keeps the raw data in your own MySQL

The problem Matomo solves: analytics data that stays in your database

Most hosted analytics products keep the visit log on the vendor's infrastructure. Matomo inverts that. The README describes it as "a full-featured PHP MySQL software program that you download and install on your own webserver," and the project's own summary of what makes it different is blunt: "You own your web analytics data: since Matomo is installed on your server, the data is stored in your own database." That single design decision drives everything else about the product, including its cost structure and its operational burden.

The audience is narrower than the marketing suggests. It fits teams that already run a webserver and a database and have a reason to keep the raw event stream on their own hardware: internal policy, a contract that forbids sending visitor data to a third party, or a need to query the raw tables directly rather than through a vendor's API. It fits less well for someone who wants a script tag and nothing else. Matomo hands you the whole stack, and the whole stack becomes your responsibility.

How Matomo works: a PHP application, a MySQL store and a JavaScript tag

The data flow has three visible pieces. First, the JavaScript tag that Matomo generates at the end of installation is pasted into the tracked pages; the README says you "Simply copy and paste this tag on websites you wish to track and access your analytics reports in real-time." Second, the tracking request lands on the PHP application, which writes the visit into MySQL. Third, the reporting interface reads back out of that same database.

The repository layout reflects a plugin architecture rather than a monolith. Top-level directories include core/, plugins/, libs/, lang/, config/, tests/ and js/, plus two pairs of entry files: index.php and console for the application and the command line, and matomo.php, matomo.js, piwik.js and piwik.php for tracking. The README states that "Matomo features are built inside plugins: you can add new features and remove the ones you don't need." That is the real extension model. A feature you do not enable is a plugin you do not activate, and custom work means writing a plugin rather than patching core.

The front end is a Vue 3 application. package.json pins "vue": "^3.2.6" and lists @vue/cli-service, jest and eslint tooling, with an engines field requiring Node ">=16.0.0 <17.0.0". That Node range is worth noticing: it is a hard ceiling, not a floor. Anyone building the JavaScript assets on a newer Node release is outside the range the project declares.

Installing Matomo on your own server

The README's install path is deliberately short: download Matomo, upload it to your webserver, point your browser at the directory, follow the steps, then add the generated JavaScript code to your pages. There is no package manager command in the README, so the download comes from matomo.org/download rather than from a distro repository.

The requirements are explicit. PHP 8.1.0 or greater, MySQL 8.0 or greater or MariaDB 10.6 or greater, and the pdo and pdo_mysql extensions or MySQLi. The README adds that Matomo is "OS / server independent," which is true of the application but not of the runtime: you still need that PHP and that database version.

If you want to experiment before pointing Matomo at real traffic, the README names one mechanism for generating data without visitors: "You may also generate fake data to experiment, by enabling the plugin VisitorGenerator." The plugin is named VisitorGenerator, and it is enabled as a plugin like any other in the plugins/ directory.

For development, the README points elsewhere and is specific about it: "When using Matomo for development you need to install Matomo from the Git repository," and that route "will also give you access to a DDEV environment you can use," documented in .ddev/README.md. The presence of a .ddev/ directory at the top level confirms that environment ships with the repository. If you are evaluating Matomo as a contributor rather than an operator, that DDEV setup is the path the project documents, not the download-and-upload route.

Where Matomo is the wrong tool

The README is silent on rollback. There is no documented procedure for reverting a bad upgrade, no mention of a downgrade path, and no statement about database schema compatibility across versions. For a self-hosted application that owns your analytics history, that silence is the largest operational risk in the documentation. A failed upgrade is not a broken dashboard; it is a database you may not be able to read with the previous code.

The release cadence compounds this. The recent releases listed for the repository are 5.14.0-alpha builds dated 2026-08-26, 2026-08-28 and 2026-08-29, on a default branch named 5.x-dev. Alpha builds on a development branch are not what you deploy to production, and the README does not walk an operator through the stable release channel. Anyone planning an upgrade needs to consult matomo.org/changelog and developer.matomo.org/changelog, both of which the README points to, rather than tracking the branch.

There is also a scale question the README does not answer. It states the software is used on more than 1,400,000 websites, which says nothing about the volume any single installation handles. If your traffic is large, the constraint is the MySQL instance you provide, and the README gives no sizing guidance at all. Treat capacity as something you measure on your own hardware, not something the documentation settles.

Matomo against Google Analytics, and against a log-based tool

The comparison the project itself makes is with Google Analytics, and the README frames it as "a Free software alternative to Google Analytics." The difference is not the report set. It is where the data lives and who can read it. With Matomo, the visit records are rows in a database you control, and the README notes you "can get all the statistics using the powerful Matomo Analytics API." With Google Analytics, the raw records are on Google's infrastructure and your access is through their interface and API.

That difference cuts the other way too. Google Analytics requires no server, no PHP version, no database upgrade and no capacity planning. Matomo requires all four. Choosing Matomo is choosing to operate a service, and the README's own framing supports that reading: it lists requirements, a five-minute installation and a JavaScript tag, and then everything after that is your infrastructure.

A second alternative worth naming is server-log analytics, which reads the access logs your webserver already writes. That approach needs no JavaScript tag and therefore captures requests from visitors who block scripts, but it also sees no client-side events, no JavaScript-disabled distinctions and nothing a browser would have reported. Matomo's tag-based collection sees the browser; log analysis sees the request. The two answer different questions.

Licence, support and the cost of staying current

Matomo is released under GPL v3 or later, and package.json records the licence as "GPL-3.0+". For most operators running Matomo as a service for their own sites, that is straightforward. It matters if you intend to redistribute a modified version or embed it in a product, because the GPL carries obligations that a permissive licence does not. That is a question for your own counsel, not for this article.

Support has two documented tiers. Free support is the community forum at forum.matomo.org. Paid support is an On-Premise Support Plan, linked from the README. There is also a hosted option, Matomo Cloud, which the README describes as a 21 day free trial for people who "do not have a server or don't want to host yourself." That is the honest escape hatch: if operating PHP and MySQL is the part you do not want, the project sells you the operated version.

Upgrade cost is the recurring expense that does not appear on a pricing page. You are responsible for PHP version currency, database version currency and the Matomo upgrade itself. The README documents the security process, noting a bug bounty program and a commitment to "validate, patch and release fixes as quickly as we can," with details at matomo.org/security and a HackerOne program. Security patches only help if you apply them, which brings the maintenance question back to whoever holds the server.

Editorial conclusion

Adopt Matomo if you need the raw visit log inside your own MySQL and can run PHP 8.1 with MySQL 8.0 or MariaDB 10.6. Do not adopt it if nobody on the team will own server upgrades, because the README gives no rollback path for a bad release. Before committing, verify the PHP and database versions on the target host and confirm you can run the console script at the repository root, since that is the entry point the project ships for command line work.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes