Every time someone visits your WordPress site, your analytics plugin quietly writes something to your database. A row here, a session there. On day one, it’s invisible. After a year, it’s a different story.
We wanted to know exactly how different. So we ran a benchmark.
We took three of the most popular free, privacy-focused WordPress analytics plugins (Burst Statistics, Independent Analytics, and WP Statistics) and simulated a full year of realistic traffic on each one. Then we measured what happened to the database: how much it grew, how heavy it got, and how that weight affected the speed of the analytics dashboard itself.
The results are worth knowing before you pick an analytics plugin for your site.
Why Database Size Matters
Your WordPress database is shared with everything your site needs to work. It’s the same place your posts, pages, comments, settings, and plugin data all live. When an analytics plugin grows that database, the effects are real:
- Backups get bigger. Most hosts back up your database daily or weekly. A 4 GB database takes longer to back up, longer to restore, and costs more in storage versus a lean 100 MB website.
- Your hosting plan has limits. Many shared hosting plans cap database size. Growing past that limit means upgrade time and an emptier wallet.
- Dashboard queries get slower. More data like analytics stats in your database means everything on your site gets slower with every single pageview. We benchmarked the exact queries. The results are a few sections down.
Traditional analytics plugins (the kind that store data inside your WordPress install) can’t escape this problem. More traffic always means more database weight.
The Benchmark
We tested Burst Statistics, Independent Analytics, and WP Statistics, all on their free versions with default settings, installed on clean WordPress sites.
The test environment was Local by Flywheel, a MySQL setup on a developer Mac that closely mirrors the kind of shared hosting where most WordPress sites actually live. Not a tuned server optimized for performance. A realistic environment.
We simulated two traffic levels, run for a full year:
| Scale | Pageviews per day | Pageviews per year | Real-world equivalent |
|---|---|---|---|
| Low traffic | 1,000 | 365,000 | Hobby blog, small business site |
| High traffic | 10,000 | 3,650,000 | Successful niche site, growing publication |
Traffic was generated with realistic patterns: a mix of new and returning visitors, realistic session lengths, varied pages and referrers. The end result is a database that looks exactly like one a real site would have after a year of that traffic.
The Results: How Big Did Each Database Get?
After one year at 10,000 pageviews per day:
| Plugin | Database size (1k pv/day) | Database size (10k pv/day) |
|---|---|---|
| Burst Statistics | 210 MB | 1.89 GB |
| WP Statistics | 220 MB | 1.98 GB |
| Independent Analytics | 463 MB | 4.26 GB |
All three grow roughly in proportion to traffic: 10x more pageviews produces about 9x more database weight. That’s expected. What isn’t expected is the total, or what some of these plugins say versus what they deliver.
Independent Analytics: The Numbers Don’t Match the Marketing
Independent Analytics’ own marketing says the plugin stores “about 200–300 MB per million sessions.”
We actually measured 1.9 GB per million sessions, between 6.5x and 9.7x higher than their published figure.
At 10,000 pageviews per day for one year, Independent Analytics accumulated 4.26 GB across 2.19 million sessions. If you’ve been sizing your hosting plan based on what IA’s documentation claims, you’re working from numbers that don’t reflect reality.
Burst Statistics: The Free Tier Has No Cleanup
Burst Statistics’ free tier includes no data archiving. There’s no option to automatically delete old data to keep the database manageable. That feature is locked behind Burst Pro.
What this means in practice: on the free tier, the database only ever grows. Install it today, and in two years you’ll have twice the footprint of the one-year numbers above, with no built-in way to trim it down.
WP Statistics: One Table Holds 76% of Everything
WP Statistics takes a different database design approach that produces some fast results (more on that shortly) but comes with a significant trade-off. The plugin stores 23 columns of data per visitor (browser, device, platform, city, region, country, user agent string, and more) all in a single wide table.
At medium scale, that one table consumes 1.5 GB (76% of the entire database footprint). Every report that breaks down your audience by browser, device, or country has to read through that entire table. It can’t be avoided.
The Part That Actually Slows Your Site: Dashboard Queries
Database size is the number you see in your hosting control panel. Query performance is what you feel every time you open your analytics, or what your visitor feels every time they view a page.
We benchmarked the exact database queries each plugin’s dashboard runs (the ones that power “top pages,” “top browsers,” “unique visitors,” and similar reports). Here’s what happened at 10,000 pageviews per day.
Independent Analytics
| Dashboard report | Small site | Medium site | Change |
|---|---|---|---|
| Top browsers | 29 ms | 16,215 ms (16 seconds) | 561× slower |
| Top platforms | 22 ms | 13,629 ms (13.6 seconds) | 614× slower |
| Top countries | 24 ms | 17,386 ms (cold) | — |
| Top pages | 36 ms | 2,480 ms | 69× slower |
At moderate traffic, Independent Analytics takes 16 seconds to generate the top browsers report. That’s the raw database query time. The actual dashboard load, with WordPress and PHP overhead on top, runs closer to 25-30 seconds.
Independent Analytics’ own documentation acknowledges performance problems above 100,000 views per month (~3,300 views per day). Our medium scale of 10,000 per day is three times that threshold.
Six of the plugin’s twelve dashboard queries cross the 500ms “slow query” threshold at medium scale. Four exceed two full seconds.
Burst Statistics
| Dashboard report | Small site | Medium site | Change |
|---|---|---|---|
| Avg. pageviews per session | 15 ms | 2,843 ms | 184× slower |
| Full year aggregate | 196 ms | 2,240 ms | 11× slower |
| Top browsers | 29 ms | 650 ms | 22.6× slower |
| Bounce rate | 19 ms | 479 ms | 25.3× slower |
Five of Burst’s eleven dashboard queries cross the slow-query threshold at medium scale. The worst (the average pageviews per session calculation) degrades 184 times between a small site and a medium one. At small scale it’s instant. At medium scale it takes nearly 3 seconds.
The cause is a known database behavior: when tables grow large enough, the database optimizer stops using its shortcuts (indexes) and resorts to scanning millions of rows one by one. Five of Burst’s queries hit this cliff between our two traffic levels. Once a query loses its index, more RAM and better caching won’t fix it. Only architectural changes would.
WP Statistics
WP Statistics tells two different stories depending on which report you’re looking at. Its pre-aggregated design means some queries are instant:
| Dashboard report | Small site | Medium site |
|---|---|---|
| Total pageviews | 1.8 ms | 2.0 ms |
| Top pages | 2.5 ms | 3.2 ms |
| Pageviews per day | 1.9 ms | 2.7 ms |
These stay fast because WP Statistics pre-calculates and stores certain summaries separately. Reading a pre-calculated total is always fast, regardless of how much traffic you have.
But every “who” report (who visited, where they came from, what browser they used) requires reading that 1.5 GB visitor table. There’s no shortcut:
| Dashboard report | Small site | Medium site |
|---|---|---|
| Top countries | 432 ms | 4,706 ms |
| Top browsers | 266 ms | 3,854 ms |
| Top platforms | 258 ms | 3,528 ms |
| Top devices | 170 ms | 2,196 ms |
These queries were already doing full table scans at small scale. The problem existed from the start, just over fewer rows. There’s no sudden cliff. The slowdown scales predictably and unavoidably with traffic.
One More Detail: What Happens When You Uninstall?
Independent Analytics does not remove its database tables when you uninstall the plugin.
Delete IA from your site, and the database stays exactly as it was: tables, rows, and all. Your 4+ GB of accumulated analytics data remains until you manually delete it or restore from a backup that predates the install. For long-running sites that want to switch analytics tools cleanly, this is worth knowing in advance.
Why SimpleStats Doesn’t Have This Problem
Everything measured above shares a root cause: all three plugins store your analytics data inside your WordPress database. Every pageview, session, and visitor event is written directly to your site’s MySQL install, alongside your posts, pages, and settings. More traffic always means more database weight.
SimpleStats works differently. It uses privacy-focused, server-side analytics, meaning your data lives on our servers, not yours.
There are no wp_simplestats_* tables accumulating rows in your database. Your site’s database doesn’t grow with traffic. A site with 100 pageviews per day and a site with 100,000 pageviews per day have the same local database footprint when they use SimpleStats.
This means:
- Your site stays fast. No slowdowns as your traffic grows
- Your visitors get faster page loads, keeping bounce rates low
- Your Core Web Vitals and SEO rankings stay protected
- Your hosting costs and backup sizes stay predictable, no matter how long you’ve been tracking
- Uninstalling SimpleStats leaves nothing behind
This isn’t a feature we built to outperform bloated plugins. It’s a consequence of how the architecture works: cloud-hosted analytics has nothing to bloat locally.
Try SimpleStats Free
If you want analytics that never touches your database, SimpleStats is free to get started. No credit card required. Install the plugin, connect your site, and your analytics live on our servers, not yours.
Summary
| Burst Statistics | WP Statistics | Independent Analytics | SimpleStats | |
|---|---|---|---|---|
| DB size after 1 year (10k pv/day) | 1.89 GB | 1.98 GB | 4.26 GB | 0 |
| Worst dashboard query (medium scale) | 2,843 ms | 4,706 ms | 16,215 ms | — |
| Slow queries at medium scale | 5 of 11 | 4 of 12 | 6 of 12 | — |
| Free-tier archiving | No (Pro only) | Yes | Yes | — |
| Tables removed on uninstall | Yes | Yes | No | — |
| Local DB impact | Heavy | Heavy | Very heavy | None |
Traditional analytics plugins have a shared problem: they store your data in your database, which means more traffic always means more weight. Some manage it better than others. None of them escape it.
SimpleStats does.
A Note on Our Methodology
Honest benchmarks come with honest caveats.
Our tests ran on Local by Flywheel, a MySQL environment on a developer Mac. This is comparable to shared hosting, not a performance-optimized production server. We chose it because it’s the environment most WordPress sites actually run on; a benchmark on a tuned dedicated server would be less useful to the typical user.
Traffic was generated via direct database inserts rather than live HTTP requests through each plugin’s tracker. The end-state databases are identical to what real tracking produces, but the method bypasses any rate-limiting or deduplication the live tracker performs. If anything, this makes our numbers conservative.
Query times are raw SQL execution times. Actual WordPress dashboard load times are typically 1.5–2× higher due to PHP and rendering overhead.
Finally: this is a one-year simulation. Real sites accumulate data over multiple years. A site that has run Independent Analytics for three years would show substantially larger numbers than what we measured here.