The objection to self-hosted analytics is always the same: it puts the data in your database, and databases get slow, and backups get big. It is a reasonable worry and almost nobody attaches a number to it. Here is mine.
Two years to the day, 303,759 pageviews, every analytics table on the site: 56.4 MB. That is 3.8% of a 1.48 GB database, and less than the posts table.
Per 100,000 pageviews it works out at 18.6 MB. Scale that however you like. A site doing a million views a year lands somewhere near 190 MB annually, which is a rounding error against the media library.
The Biggest Table Is Not Your Traffic
The interesting part is where the 56 MB went.
One table holds 35.2 MB of it, 62% of the entire footprint, and it isn’t pageviews. It’s the 404 log: 27,547 distinct missing URLs, 152,836 requests.
None of that is readers. The top entry is /opoint_hashtag, requested 13,214 times by something that has never explained itself. Below it: /.well-known/traffic-advice, which is Chrome’s prefetch proxy asking permission. /ads.txt, asked for by ad-tech crawlers on a site with no ad inventory. /graphql, /api/graphql and /_next/image, probes for a stack I don’t run, from scanners working through a list.
Of those 152,836 requests, the ones that came from a link on my own site number 323. Two tenths of one percent.
So the largest table my analytics plugin maintains is a record of other people’s reconnaissance, and it costs more storage than everything I actually wanted to measure.
The 0.2% Is the Part Worth Reading
That 323 is not noise to be deleted, though. It’s the only genuinely actionable thing in the table: pages on my own site linking to URLs that no longer resolve. Every one of those is a link I broke, findable nowhere else, and fixable in a minute.
The rest splits into two piles. Scanner traffic, which tells you nothing and should be capped rather than stored. And stale external links, old category URLs and deleted reviews that other sites still point at, which are worth a redirect because someone out there is still sending people.
Sorting by referrer rather than by hit count is what separates them, and it is the first thing I would do with a 404 report on any site.
What Is Actually Eating Your Database
While measuring this I sorted the whole database by table size, which I recommend doing before worrying about any one plugin.
Analytics came seventh. Above it: a search plugin’s metrics table at 621.5 MB, on its own eleven times the size of every analytics table combined. An activity-log plugin holding 300 MB across two tables. A search index at 55.6 MB. A geo-targeting plugin’s event log at 41.3 MB.
Roughly a gigabyte of a 1.48 GB database is three plugins logging their own activity, and not one of them is the thing people warn you about. The fear attaches to analytics because recording events is visibly its job. A plugin that keeps an audit trail as a side effect gets no such scrutiny.
Run this and look at your own:
SELECT table_name, ROUND((data_length+index_length)/1024/1024,1) AS mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY (data_length+index_length) DESC LIMIT 20;Why It Stays Small
Self-hosted analytics can be enormous if it stores one row per pageview. Keep raw events and a decent month puts a million rows in a table you then have to query.
Rolling up at write time instead is what keeps the number in tens of megabytes. One row per day per page, per day per referrer, per day per country, incremented rather than appended. You lose the ability to ask questions you didn’t anticipate, because the raw events are gone. You gain a table that grows with how many distinct pages and sources you have rather than with how much traffic arrives.
For a site with 300 posts, a busy day and a quiet day cost nearly the same storage. That trade is the whole design, and it’s why the total above is 56 MB rather than several gigabytes.
The other lever is retention. Vireo Analytics purges rollup rows past a configurable age, and the 404 table is capped so a scanner flood can’t grow it without limit. Both are worth setting deliberately rather than leaving at whatever the default is, on any analytics plugin you run.
It also prints its own total next to that setting, which is where I’d start before reaching for SQL. Any plugin storing this much of your data should be willing to tell you how much, and most of them won’t.
The Honest Version
Self-hosted analytics does cost you database. On the numbers above, about 28 MB a year at 150,000 annual pageviews, most of it spent recording requests from people probing for a wp-config.php backup.
That is a real cost and a small one. If your database is uncomfortably large, measure it before you blame analytics, because the query above will probably point somewhere else entirely.
Related
Leave a Reply