The right plugin for WordPress analytics is one that never writes raw traffic data into your site's own database — because once a plugin starts logging every pageview into a custom table, that table grows faster than your content does and drags down backups, migrations, and even wp-admin itself. The real split in this category isn't free versus paid. It's plugins that store data on your server versus plugins that just display data stored somewhere else.
TL;DR:
- Plugins that log every hit into a custom database table will keep growing that table forever unless you manually prune it — deactivating the plugin doesn't delete it.
- Check Tools > Site Health > Info in wp-admin to see if a plugin created tables outside the normal WordPress schema.
- Cookieless, externally hosted analytics avoid the bloat entirely because the raw data never touches your site's database.
- Under the EU's ePrivacy framework, you only need a consent banner if a cookie stores or reads something on the visitor's device — no cookie, no banner requirement.
- Before switching plugins, export or screenshot your historical numbers; most stats tools don't let you import a competitor's data later.
Table of Contents
- Choosing a Plugin for WordPress Analytics Without the Database Bloat
- How to Tell If a Plugin Is Already Bloating Your Database
- Three Ways Analytics Plugins Store Your Data
- Side-by-Side: Popular Analytics Plugin Architectures Compared
- Cookies, Consent Banners, and the GDPR Test That Actually Matters
- Already Bloated? How to Clean Up an Old Stats Plugin Safely
- See Every Site's Traffic in WordPress Without Growing Your Database
- Frequently Asked Questions
- Sources
Choosing a Plugin for WordPress Analytics Without the Database Bloat
Most people searching for a plugin for WordPress analytics are really asking one of two questions: "which one is easiest to read" or "which one won't slow my site down." The second question matters more, and it's the one most comparison pages skip. A stats plugin that writes a new row to a custom table every time someone loads a page will, over a year of normal traffic, produce a table with hundreds of thousands or millions of rows — and that table gets backed up, migrated, and queried along with everything else in your database.
This isn't a hypothetical. Any plugin built on the classic "log every visit in a custom table" architecture — the model used by several of the oldest and most popular WordPress stats plugins — keeps that data forever unless you configure automatic pruning or do it yourself. If you never set a retention limit, the table just keeps growing.
How to Tell If a Plugin Is Already Bloating Your Database
You don't need to be a developer to check this. WordPress ships with a built-in diagnostic screen that lists every database table on your site.
- Open Site Health. In wp-admin, go to Tools > Site Health > Info, then expand the Database section. This shows table names and, on many hosts, approximate sizes.
- Look for plugin-prefixed tables. Anything named like
wp_statistics_visitor,wp_jetpack_*, or a custom prefix tied to a stats plugin is where raw hit data likely lives. - Check your backup size history. If your nightly backup has quietly tripled in size over six months and you haven't added much content, a logging plugin is a common culprit.
- Ask your host for a database size report. Most managed WordPress hosts, including WP Engine and Kinsta, expose this in their dashboards without needing phpMyAdmin.
Pro Tip: Deactivating a stats plugin almost never deletes its custom tables — only uninstalling it through the proper "Delete" action in the Plugins screen triggers cleanup, and even then, some plugins skip that step entirely. If you've swapped stats plugins more than once over the life of a site, check for orphaned tables from tools you stopped using years ago; they're still being backed up every night.
Three Ways Analytics Plugins Store Your Data
Every WordPress analytics option falls into one of three architectures, and the architecture determines almost everything else about the trade-off you're making.
Database-Resident Plugins
These write every pageview, visitor, and referrer directly into your WordPress database, usually in custom tables created on activation. You get full control and no external dependency, but the table grows without bound unless you manage retention yourself, and heavy traffic sites can see real slowdowns on dashboard widgets that query millions of rows.
Self-Hosted Server Plugins
Tools like Matomo (when self-hosted) run on a separate server or subdomain you control, with WordPress talking to it via a plugin bridge. Your site's own database stays clean, but you've taken on a second piece of software to patch, back up, and scale — which is a fair trade for some agencies and a headache for a solo site owner running five client sites.
Externally Hosted, Cookieless Plugins
The data is collected by a small script, sent to a server the vendor runs, and displayed inside wp-admin or a separate dashboard. Nothing is written to your WordPress database at all.
One line of code, 4.7 KB, deferred so it never blocks the first paint — that's the entire on-site footprint a plugin needs if it isn't writing to your database.
This third model is the one to pick if database size, backup speed, and page load are higher priorities than owning the raw data outright.
Side-by-Side: Popular Analytics Plugin Architectures Compared
| Approach | Where raw data lives | Typical setup | Database impact |
|---|---|---|---|
| Classic stats plugin (custom tables) | Your WordPress database | Install, activate | Grows indefinitely without manual pruning |
| GA4 via tag manager or plugin | Google's servers | Account setup, consent config | None on your DB, but requires a consent banner in most jurisdictions |
| Self-hosted Matomo | A server you run | Separate install, ongoing maintenance | None on WordPress DB, but you maintain a second system |
| Cookieless external service | Vendor's servers | Script tag or pre-connected plugin | None — nothing written to WordPress tables |
If you're running several sites across different platforms — a WordPress blog, a Shopify store, a Webflow landing page — the self-hosted route multiplies your maintenance burden by however many installs you're juggling. An externally hosted option is the only one of the four that scales cleanly across platforms without adding a server to babysit for each one.
Cookies, Consent Banners, and the GDPR Test That Actually Matters
A lot of buyers assume "cookieless" is a marketing word. It's actually the test that determines whether you need a consent banner at all. CNIL, France's data protection authority, has published detailed guidance on which tracking technologies require prior consent, and the dividing line isn't "is this analytics" — it's whether the tool stores or reads information on the visitor's device.
No cookie, no device storage, no consent requirement — that is the entire test under the EU's ePrivacy rules for whether a banner is needed.
This is why a plugin that drops a tracking cookie, even one used purely for first-party analytics, pushes you toward needing consent management, while a plugin that fingerprints traffic without storing anything client-side generally doesn't. The GDPR text itself governs personal data processing more broadly, but the cookie-specific question is usually resolved by the ePrivacy rules CNIL interprets. If you run sites for clients in the EU, UK, or California, picking an analytics tool that sidesteps this question from the start saves you from building and maintaining a banner you'd otherwise need.
Already Bloated? How to Clean Up an Old Stats Plugin Safely
If Site Health turned up a few gigabytes of orphaned tables from a plugin you stopped using, don't just delete tables by hand in phpMyAdmin without a plan.
- Back up first. A full database export before you touch anything is non-negotiable — table structures can have foreign dependencies you won't notice until something breaks.
- Confirm the plugin is truly inactive. Check the Plugins screen; if it's still listed (even deactivated), reinstall it briefly and use its proper uninstall routine if it has one.
- Drop orphaned tables manually if needed. If the plugin is long gone and the tables remain, a developer or your host's support team can drop them safely with a short SQL command.
- Set retention limits going forward. If you're keeping a database-resident plugin, most offer a setting to auto-delete raw logs older than 90 or 180 days — turn it on.
Pro Tip: Before you migrate hosts, run a database size check specifically excluding stats tables. Hosts that price by database size or charge extra for large backups will sometimes quote you based on a number that's 60% dead analytics data — worth knowing before you negotiate a new plan.
See Every Site's Traffic in WordPress Without Growing Your Database
Replastats is a cookieless analytics service built around the architecture this article has been describing: nothing gets written to your WordPress database, because the data lives on a separate server the moment it's collected. The WordPress plugin connects your dashboard inside wp-admin, you skip the consent banner because there's no cookie to disclose, and the free tier covers a single site if you just want to see visitors, sources, top pages, and live traffic without committing to anything.
If you run more than one site — a WordPress blog alongside a Shopify store or a Webflow page — the Pro and Agency plans add a multi-site board that puts every property on one screen, plus session replays and heatmaps starting on the Starter tier. The honest caveat: this is traffic and behavior analytics, not e-commerce order data or deep funnel reporting, so if you need granular revenue attribution baked into the same dashboard, check the spec sheet against what you actually need before switching.
Frequently Asked Questions
Will switching analytics plugins delete my historical traffic data?
Usually yes, in the sense that most tools don't import data from a competing plugin. Export or screenshot your key numbers before you deactivate an old plugin, since that history typically isn't portable once you move on.
Does a cookieless plugin still require a privacy policy update?
Most sites should mention any analytics tool in their privacy policy regardless of whether it uses cookies, since you're still processing some visitor data. A cookieless tool just removes the separate requirement for a consent banner under most EU and UK interpretations.
Can I run two analytics plugins at once to compare them before switching?
Yes, and it's a reasonable way to validate a new tool's numbers against an old one for a few weeks before fully committing. Just remember to remove the plugin you're abandoning afterward, including its database tables, rather than leaving both running indefinitely.
How much database size is "too much" for a stats plugin to be using?
There's no universal number, but if your stats-related tables exceed your actual content tables in size, that's a signal worth investigating. Check Tools > Site Health > Info periodically rather than waiting for a slow backup to force the question.
Does WordPress itself track visitors by default?
No. Core WordPress doesn't log pageviews or visitor data on its own — any analytics capability comes entirely from a plugin or an externally added script, which is why the choice of plugin matters so much.