Sizing self-hosted web analytics for millions of pageviews

Sizing self-hosted web analytics for millions of pageviews starts with the traffic you will reach, not the traffic you have today

Sizing a self-hosted analytics platform depends on three things: the monthly pageviews you expect to reach, the platform you choose, and who will run the servers. A team that sizes only for today's traffic often finds its hardware underpowered within a single campaign cycle or redesign. This section gives you a sizing basis to take into procurement. It covers capacity only. It does not cover consent, lawful basis or other legal duties, which other pages in this group address. For Matomo, the requirements FAQ gives published points at 1 million and 10 million pageviews a month. At 1 million, a single server with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD is the stated baseline. At 10 million, Matomo recommends separate application and database servers, each with 8 CPUs and 16 GB of RAM. Plausible Community Edition adds ClickHouse to the stack, which requires a CPU with SSE 4.2 or NEON support and at least 2 GB of RAM as a floor. Umami uses PostgreSQL, which it supports from version 12.14. Each choice moves the operating load to a different place: database tuning, archiving, upgrades or event storage. Before you request a quote, ask your implementation partner for a sizing model that uses your projected pageviews for the next 12 to 24 months, names the platform version and the database each tier uses, and states who patches the operating system, database and application. Confirm those points with the vendor and in your own environment, because published figures describe a baseline, not your workload.

Which sizing requirements change at high traffic

This table compares the published sizing and runtime minimums for Matomo, Plausible and Umami, and what each one means for the build at high traffic. Use the figures as a floor, then confirm peak-hour load, archiving schedules and retention in your own environment before committing to hardware.

Requirement	Published figure	What it means for the build	What to confirm in your environment
Matomo single server (up to 1 million pageviews a month)	At least 4 CPUs, 8 GB of RAM and 250 GB of SSD	Workable for smaller estates, but app, database and archiving jobs compete for the same resources at peak	Peak-hour requests per second, archive run times and whether reports must refresh intraday
Matomo separated servers (up to 10 million pageviews a month)	App and database servers with 8 CPUs and 16 GB of RAM each	Splitting tiers separates web requests from database load and lets you scale the database independently	Database growth per month, disk IOPS, and backup and restore time for the full dataset
Matomo 6.0.0 beta runtime	PHP 8.1 or newer; MySQL 8.0 or newer or MariaDB 10.6 or newer	Newer minimums mean older PHP and database hosts may need upgrading before a production move	Whether your team will run a beta in production or wait for a stable 6.x release
Matomo 5.x runtime	PHP 8 with MySQL 5.5 or later or MariaDB, behind Apache, Nginx, IIS or LiteSpeed	Older database versions are still listed, but matching the current stable line reduces upgrade risk	Current stable version in your change process and your database support window
Plausible Community Edition hardware	Docker and Docker Compose, a CPU with SSE 4.2 or NEON, and at least 2 GB of RAM	ClickHouse, which Plausible uses for analytics storage, needs a compatible CPU instruction set; 2 GB is a floor, not a sizing for millions of views	Event volume per month, ClickHouse disk growth, and whether you need separate hosts for the database layer
Plausible operating effort	Operator manages installation, upgrades, capacity, uptime, backups and security; security fixes arrive only when the operator applies the release	At high volume, the operator carries the capacity and patching work that Plausible Cloud handles	Who applies releases, the patch window, and the on-call coverage for capacity alerts
Umami runtime	Node.js 18.18 or newer for a source install; PostgreSQL 12.14 or newer	Node and PostgreSQL versions set the upgrade path, and the bundled Docker Compose setup uses a bundled PostgreSQL database	Whether you run the bundled database or an existing managed PostgreSQL service, and its connection and backup limits
Umami event volume	Umami Cloud pricing lists event tiers; self-hosted use has no published event ceiling	Self-hosted capacity depends entirely on your hardware and database tuning, so load testing matters more than a published limit	Expected events per month, peak concurrent sessions, and a load test against your own traffic profile

Which self-hosted platform fits which traffic level

Matomo, Plausible Community Edition and Umami take very different routes to high traffic, so the right choice depends on licence terms, how much operating work you will carry, and which features your analysts need. The cards below set out what each option asks of your team and the points to confirm with each vendor before you commit to a sizing plan.

Matomo On-Premise under GPLv3

Matomo's GitHub repository is licensed under GPLv3, and the On-Premise Community edition is listed as free with unlimited users and hits. Its requirements FAQ sizes one server for up to 1 million pageviews a month and recommends separate app and database servers for up to 10 million. Your team owns those servers, the archiving schedule and every upgrade. Confirm with Matomo whether your traffic profile fits the published tiers before you buy hardware.

Matomo's paid add-ons and consent limits

Heatmap and Session Recording is a premium plugin sold per user under the InnoCraft EULA, not the GPL, so it adds a licence cost that the free edition does not carry. Matomo's ePrivacy guidance also says that features such as User ID, heatmaps or session recordings can remove the consent exemption that some regulators allow for analytics. Check both points before you size for a high-traffic consumer site that wants session replay.

Plausible Community Edition under AGPLv3

Plausible Community Edition is licensed under AGPLv3 or later and runs on Docker and Docker Compose, with a CPU that supports SSE 4.2 or NEON and at least 2 GB of RAM as the stated minimum. Its ClickHouse database is the component that determines how the stack scales, so ask for a capacity test on your own pageview volume. Community support is the only support tier, which puts the sizing risk on your team.

Plausible's manual upgrade cycle

Community Edition is a long-term release published twice per year, and security fixes reach you only when your operator applies the release. Plausible Cloud ships updates several times per week. The most recent security release, v3.2.1, was published on May 15, 2026, so a high-traffic site needs a patch window and a tested rollback plan for ClickHouse. Also confirm which features you will not get, including funnels, ecommerce revenue goals, single sign-on and the Sites API.

Umami under MIT with PostgreSQL

Umami is licensed under MIT and publishes a Docker image plus a Compose file that starts Umami with a bundled PostgreSQL database. A source install needs Node.js 18.18 or newer, and PostgreSQL is supported from version 12.14. This is the lightest stack of the three, but you should load-test the database at your target event rate, since Umami's published capacity limits are only Cloud reference tiers. Confirm the self-hosted ceiling with the Umami documentation before you commit.

Cloud reference points for planning

Matomo Cloud starts at 29 per month (excluding tax) for tiers up to 10 million hits, and Umami Cloud Business lists 10 million events at $200 per month with five years of retention. These published tiers are reference points for comparing the cost of running your own infrastructure, not capacity guarantees for a self-hosted install. Use them to frame the build versus SaaS decision, then ask each vendor to document the capacity your traffic requires.

How the server layout changes at each traffic tier

Matomo's requirements FAQ sizes one server for up to 1 million pageviews a month with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD. The application, web server and database share the same machine, so one host carries the web requests, the tracking endpoint, the scheduled archiving and the MySQL or MariaDB workload at the same time. That keeps the moving parts small, but it also means a heavy report or a long archive run competes with live tracking on the same CPU and disk.

Hardware: At least 4 CPUs, 8 GB of RAM and 250 GB of SSD, per Matomo's published figures.
Upgrades: One host to patch, reboot and test for each Matomo release, including the PHP and database version steps listed in the requirements.
Backups: One nightly database dump and file backup, tested by restoring to a separate host.
Archiving: Scheduled archiving runs on the same machine, so the team should watch for jobs that overlap with peak traffic.
Monitoring: Disk growth is the first alarm to set, since the stored data grows every day.

Confirm by testing with a copy of your real tracking volume, measuring CPU and disk during the busiest hour and during an archive run, and checking that report pages load within your own acceptable time.

What archiving jobs and ClickHouse add to the operating load

At low volume, Matomo's report archiving can run inside normal web requests, but at millions of pageviews it becomes a scheduled background job that must finish on time every day. Matomo pre-computes reports into archive tables so dashboards stay fast, and those tables are written continuously while visits are still arriving. The archiving schedule therefore sets how fresh a report is, and the job competes with the database for CPU, memory and I/O. Before go-live, the team should confirm how the archiver is triggered on their version, how long a full run takes on a copy of their own traffic, and whether the job overlaps with peak hours. Matomo's requirements FAQ, linked from the sizing guidance, is the starting point for the server profile these jobs will need. Each of those choices is a recurring decision, not a one-time setup step.

Plausible Community Edition takes a different route. Its event data is stored in ClickHouse, a second database engine that sits beside PostgreSQL in the same Docker Compose stack. ClickHouse is the component that answers queries over large volumes of events, so it is where capacity runs out first, and it has its own storage growth, memory needs and upgrade path. Someone on the team must patch it, back it up consistently with the application data and monitor disk and query latency separately. The repository requires a CPU with SSE 4.2 or NEON support for ClickHouse, which should be checked on every host before deployment. Skills needed are Linux operations, Docker and Compose, relational database administration and ClickHouse operations, plus a named owner for scheduled jobs and their alerts. Confirm that owner exists before choosing either platform.

How a high-traffic analytics rollout runs in phases

The sequence turns an unknown traffic profile into a sized, load-tested and monitored analytics platform, with a written record at each stage so the production build reflects measured demand rather than assumptions.

Establish the traffic and event baseline
The team measures current pageviews, peak hours, event volumes per visit and the number of sites or subdomains to be tracked, using existing logs or the current tool's reports. DeployOpen works with the client's web and analytics owners on this step. It closes with a sizing record that states monthly pageviews, peak-hour load, custom events, retention period and growth assumptions, each marked as measured or estimated. Ask the vendor or partner to show how each figure was derived.
Choose the platform against the sizing record
Using the sizing record, the team compares Matomo, Plausible Community Edition and Umami on the features it needs, the database each requires and the operating effort each adds. Matomo's published requirements, Plausible's ClickHouse dependency and Umami's PostgreSQL setup are checked against the client's standard stack and support model. The output is a short decision memo that names the platform, the edition and the features that were ruled out and why.
Build and load test in a non-production environment
DeployOpen deploys the chosen platform in a non-production environment that matches the planned production topology, including the web tier, database and any ClickHouse or PostgreSQL component. A replay or synthetic load run at the sized peak is executed, and ingestion lag, query response time, CPU, memory and disk growth are recorded. The step closes with a tested architecture document and a load test report that states where the platform reached its limits.
Build production with separated servers
Based on the load test results, the production build separates application and database servers where the sizing requires it, applies the operating system and container hardening agreed with the client, and configures TLS, network rules and monitoring agents. For Matomo, the published guidance for up to 10 million monthly pageviews recommends separate app and database servers, and this step confirms that choice against measured load. It closes with an as-built configuration record and a list of access roles.
Configure archiving, backups and retention
The team sets up scheduled archiving or aggregation jobs, database and disk backups, retention rules for raw and aggregated data, and restore procedures. Restore is tested on a separate host rather than assumed to work. Archiving frequency and retention period are set against the sizing record and the client's privacy policy. The output is a runbook covering job schedules, backup targets, restore steps and the test result, signed off by the client's operations owner.
Cut over traffic and confirm monitoring
Tracking is switched from the old tool or staged to the new platform in controlled steps, with historical imports handled according to the tool's documented import limits. Dashboards and alerts for ingestion errors, job failures, disk use and response time are checked against the runbook. The phase closes with an acceptance report that compares live figures with the sizing record, lists open issues and records who owns ongoing capacity reviews.

What capacity evidence the operations team should keep

This table lists the records a CIO, auditor or internal audit team usually asks for on capacity and availability, which component produces each one, and what a complete record looks like. Use it to check whether your operating routine would answer an assessor's questions without reconstructing history. DeployOpen can prepare this evidence as part of an engagement, but independent auditors and certification bodies issue any audit report.

Evidence	Produced by	What it should show
Sizing decision record	Change ticket and architecture document	The expected monthly pageviews, the chosen topology (single server or separate app and database servers), the Matomo sizing tier referenced, and who approved it
Load test results	Test tool output and Matomo request logs	Tracking request throughput at peak, response times for tracking and report pages, and the traffic pattern used as the test baseline
Database backups and restore tests	Database backup jobs and restore logs	Backup schedule, retention, encryption status, and a dated restore test showing the analytics database can be recovered and reports still load
Archiving job records	Scheduled task logs for Matomo archiving	Proof that archiving runs on schedule, how long each run takes, and alerts raised when runs fail or overlap
ClickHouse capacity metrics (Plausible)	ClickHouse server metrics and host monitoring	Disk growth, memory use and query latency over time, which show when storage or RAM needs expanding for Plausible Community Edition
Patch and upgrade records	Change tickets and release notes applied	Installed version of Matomo, Plausible or Umami, the release date applied, and the security fixes covered, since Plausible Community Edition receives security fixes only when the operator applies them
Monitoring alerts and incident records	Uptime monitor, host metrics and alerting tool	Alert thresholds for tracking endpoint availability, disk and CPU limits, and how each alert was acknowledged and closed
Ownership and access review	Access management records and admin logs	Named owners for the servers, databases and archiving jobs, and periodic review of who can change configuration or export visitor data

Questions buyers ask about sizing high-traffic analytics

Is one server enough for web analytics at one million pageviews a month?

Matomo's published requirements size a single server for up to 1 million pageviews a month with at least 4 CPUs, 8 GB of RAM and 250 GB of SSD storage. That is a starting point, not a guarantee for your site. Pageviews are only one input. Custom reports, segment use, the number of sites hosted on the instance, how many people log in at once, and how long you keep raw data all change the load. Ask the implementation partner to test the instance with a realistic copy of your traffic before you commit to a single-server design, and plan how you would move to a separate database server if the numbers grow.

What does separating app and database servers add to the setup?

Separating the application and database servers gives each tier its own resources and makes scaling and maintenance easier. Matomo's requirements FAQ recommends separate servers with 8 CPUs and 16 GB of RAM each for up to 10 million pageviews a month. The trade-off is more to run: two hosts to patch, a private network path between them, separate backups, monitoring for each tier, and a tested failover or restore path. Ask who owns each server, how database credentials are stored, and what the recovery time would be if one tier failed.

How much extra operating effort does Plausible's ClickHouse add?

Plausible Community Edition relies on ClickHouse for its event storage, so the stack is larger than a single web application with one database. The repository requires Docker and Docker Compose, a CPU with SSE 4.2 or NEON support (which ClickHouse needs), and at least 2 GB of RAM. Your team then owns container upgrades, ClickHouse disk growth, backups and capacity checks. Plausible's self-hosted page states that Community Edition operators manage installation, upgrades, capacity, uptime, backups and security themselves, and that security fixes arrive only when the operator applies a release. Budget staff time for those tasks from the first day.

Can our internal team size and run this without outside help?

Many teams with Linux, container and database experience can run a Matomo or Plausible instance, but sizing for millions of pageviews needs load testing, capacity data and clear ownership of upgrades. The questions to answer internally are whether someone can own patching and restores every month, whether there is a second person who can respond to an incident, and whether the team can read database and container metrics. If those answers are uncertain, an implementation partner can take on sizing, deployment and documentation under a written, fixed scope, and the internal team keeps the operating role.

How long does a sizing exercise take, and what drives the duration?

The duration depends on how much of your environment is already known. The main drivers are the number of sites and pageviews to model, whether you have historical traffic logs or only estimates, how many custom reports and segments staff use, whether the analytics server must sit inside a specific network or data center, and how many environments you need for testing. A sizing exercise with clean traffic data and a single hosting target is far shorter than one covering several sites, a load test and a separated database tier. Ask the partner to state the milestones and the assumptions behind the estimate in the written scope.

What does a high-traffic analytics platform cost to run each year?

The software licences are free for the open-source editions, so the cost sits in infrastructure, staff time and any outside work. Matomo's pricing page lists the On-Premise Community edition as free, while Matomo Cloud plans start at 29 (excluding tax) per month for tiers from 50,000 to 10 million hits a month. Those published figures are a reference point for comparing a self-hosted instance with a managed one. Your own cost will include servers or cloud instances, storage growth, backups, monitoring, upgrades and the hours your team spends. Ask any partner for a quote that separates one-time setup from recurring support and hosting.

What should the internal team provide before a sizing project starts?

A sizing project goes faster when the internal team supplies accurate inputs and makes decisions on time. Useful inputs include current monthly pageviews by site, peak traffic periods, the tags and events you plan to track, the retention periods your policy requires, and the hosting targets that are approved. The team should also name an owner for access control, a person who can approve changes to the production server, and an owner for backups and restores. Expect to test the results against your real traffic, so keep a staging environment or a plan to create one.

Which metrics should we watch after going live at high traffic?

Watch the metrics that show when the current design is running out of room. For a single-server Matomo instance, track CPU load, memory use, disk growth, database query time and archiving job duration. For Plausible, add ClickHouse disk use, container restarts and query latency on the dashboards. For all platforms, track how long reports take to load for the people who use them most and how far behind the archive is. Set alert thresholds from your own baseline during the first weeks of production, and review them after each upgrade or traffic change.

Questions to put to an implementation partner on capacity

Start by asking how the partner tests capacity against your own traffic profile rather than against a generic pageview figure. Matomo's requirements FAQ sizes a single server for up to 1 million pageviews a month and recommends separate app and database servers for up to 10 million, but those are starting points. Ask the partner to describe the load test they would run: which pages, how many concurrent visitors, how much of your traffic is ecommerce or campaign-heavy, and how peak hours and tracking-request bursts are simulated. Ask who owns the test data and whether the results are delivered in writing before the hardware order is placed.

Next, ask how the sizing basis is documented. A useful answer names the assumptions (monthly pageviews, number of sites, retention period, custom reports, number of concurrent report users), the version of the platform being sized, and the decision each number supports. Ask how archiving jobs are scheduled and monitored in Matomo, and how their runtime is measured as data grows. For Plausible Community Edition, ask how the partner sizes the ClickHouse data volume and memory, and what they will confirm against the current release notes and the hardware requirements before recommending a machine. Confirm that the sizing document is revised when traffic changes.

Finally, ask how support is scoped and how knowledge is handed over. Ask which capacity tasks fall under the fixed-scope implementation agreed in writing, and which move to a retainer for upgrades, ongoing tuning and incident response. Ask for a sample runbook covering archiving failures, database maintenance, backup and restore of ClickHouse or MySQL data, and scaling steps, and confirm who keeps it current after go-live. Request the escalation path, the named roles on both sides, and the acceptance tests your team will run before the platform is handed over. A partner that cannot show these artifacts should not be treated as ready to size your platform.

Which decisions to settle before a quote is requested

This sequence turns a rough traffic estimate into a written scope that an implementation partner can price. Each step produces one decision or input that feeds a specific line of the fixed-scope quote.

Measure monthly pageviews and event volumes
Pull the last 12 months of pageview counts from your current analytics tool, then add the custom events, ecommerce actions and campaign parameters you plan to record. Separate peak months, such as launches or seasonal campaigns, from the baseline. Matomo sizes its published tiers by monthly pageviews, so this number decides which sizing band applies. The step is done when you have a written baseline, a peak estimate and an event count per site, signed off by the marketing and web owners.
Count the sites and domains in scope
List every domain, subdomain and app that will send data, and mark which ones share a login, a reporting team or a data retention rule. Multi-site setups change the database load and the admin work, so the partner needs this list before estimating. Note any sites that must stay out of tracking, such as authenticated portals. The step is done when you have one inventory sheet that matches the sites your tag manager actually loads.
Choose the platform and edition
Select Matomo, Plausible Community Edition or Umami based on the features you need and the operating load you accept. Matomo's published requirements differ by version, and Plausible Community Edition depends on ClickHouse, which adds a component to run. Confirm whether you need features that exist only in paid or cloud editions, such as Matomo's heatmap plugin or Plausible's ecommerce revenue goals. The step is done when the chosen platform and edition are recorded in the requirements document.
Confirm the hosting location and data residency
Decide which cloud account, data center or private network will host the analytics servers, and which jurisdiction the data must stay in. Include CDN, tag manager and backup locations, since these can carry data outside the chosen region. Ask your legal and security teams to approve the location in writing. The step is done when the hosting site, region and backup target are named and approved.
Size the servers and the database tier
Using the baseline from the first step, decide whether one server or separate app and database servers fit the load. Matomo's requirements FAQ gives a single-server figure for up to 1 million pageviews a month and recommends separate servers for up to 10 million, so volumes above that band need a fresh capacity test. Ask the partner to propose sizing and to run a load test on a copy of your expected traffic. The step is done when the proposed server specifications and a test plan are documented.
Name the team that operates the servers
Assign named owners for installation, upgrades, backups, monitoring, security patches and on-call response. Plausible's self-hosted documentation states that operators manage installation, upgrades, capacity, uptime, backups and security themselves, so these duties must sit with a team, not an individual. Decide which duties stay internal and which go to a retainer. The step is done when the responsibility matrix is signed by the operating team lead and the business owner.
Define archiving, retention and migration needs
Decide how long raw and aggregated data must be kept, whether historical data must move from Google Analytics or another tool, and which reports the business must still receive. Note that Matomo's Google Analytics importer brings in aggregated reports only, and Plausible's import is daily aggregates with some limits. These choices affect storage size, archiving job schedules and the import task in the scope. The step is done when retention periods and the migration list are written down.
Send the written requirements for a fixed-scope quote
Combine the outputs of the previous steps into one requirements document covering volumes, sites, platform, hosting, operations and migration. Ask the partner to quote a fixed scope with deliverables, exclusions and acceptance checks. Ask the partner to state which parts depend on your inputs and what happens if volumes exceed the baseline. The step is done when the partner returns a written scope that matches the requirements document line by line.

How DeployOpen scopes and supports high-traffic analytics

DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted analytics platforms inside your own infrastructure, whether that is your cloud account, a data center or an isolated network. For a high-traffic deployment, the written scope should name each component the sizing decision produces: the application servers, the separate database servers, the archiving schedule for Matomo, the ClickHouse service behind a Plausible Community Edition deployment or the PostgreSQL database behind Umami, the reverse proxy and the backup target. Ask for each item to be listed with an owner, an acceptance test and a rollback path before any work starts. Most engagements are fixed-scope, so the agreed deliverables and timelines are written down first, and any change to the capacity assumptions is handled as a documented scope change rather than an informal adjustment.

Once the platform is live, the operating effort is what decides whether the sizing holds. DeployOpen can run ongoing support, upgrades and continuous testing under a retainer, which covers applying new releases, watching disk growth on the database tier, checking archiving jobs after traffic changes and restoring backups on a schedule. Confirm with any partner exactly which of these the retainer includes, how security updates are applied and how quickly, and who is on call for a capacity incident. Plausible notes that Community Edition operators manage upgrades, capacity, uptime, backups and security themselves, so the retainer terms should answer those responsibilities line by line.

DeployOpen also runs security testing across applications, APIs and infrastructure, so the analytics collection endpoints and the admin interface can be tested as part of the rollout and again after major changes. Ask for the test scope to name the tracking endpoint, the reporting API, the authentication flow and the server hardening baseline, and ask how findings are reported and retested. Testing does not replace the platform's own maintenance, but it gives your security team evidence on the same systems that will be sized and operated.

Sizing self-hosted web analytics for millions of pageviews