Retention and Auto-Purge: Controlling Database Growth

SlimStat writes one row per pageview into wp_slim_stats, so the table grows with your traffic rather than with time. Two settings at Settings, Maintenance control what happens to old rows: Retention Period, which ships at 420 days, and Archive Mode, which decides whether expired rows are moved or destroyed. A cron job applies both, twice a day.

420 days is fourteen months. The plugin’s own help text recommends it as complying with the ePrivacy Directive and most GDPR interpretations, and warns that retaining longer may require additional legal justification under GDPR Article 5(1)(e). Treat that as the reason the default is what it is, not as legal advice about your site.

What the purge actually does

The job runs on the WordPress cron hook wp_slimstat_purge, scheduled twicedaily. On each run it computes a cutoff — now, minus the retention period in days — and acts on every row in wp_slim_stats and wp_slim_events older than it.

With Archive Mode on, rows are copied into wp_slim_stats_archive and wp_slim_events_archive with an INSERT ... SELECT, and only deleted from the live tables once the copy has succeeded. With Archive Mode off, they are deleted outright and cannot be recovered.

Either way, the job then runs OPTIMIZE TABLE on the stats, archive and events tables, which is what actually returns disk space to the filesystem after a large delete.

Two consequences follow, and both surprise people:

• Archiving is not deletion. The rows still exist, still contain whatever you collected, and — as the plugin’s own setting description says — still count as retained data for GDPR purposes. Archive Mode is a query-performance feature, not a compliance one. If your reason for setting a retention period is that you do not want to hold the data, switch Archive Mode off.
• WordPress cron only fires when someone visits. On a very quiet site the purge can run late. If timing matters, replace WP-Cron with a real system cron and the schedule becomes reliable.

Choosing a retention period

Pick the number from what you actually review, not from what feels safe. Analytics nobody opens after ninety days does not need three years of rows behind it.

1. Open SlimStat, then Settings, then the Maintenance tab.
2. Set Retention Period to the number of days you want to keep.
3. Decide Archive Mode: on to move old rows aside, off to remove them.
4. Click Save Changes.
5. Leave it a day and check your database size; the first purge on an old install can remove a great deal at once.

Setting Retention Period to 0 disables purging entirely. That is a real option for a low-traffic site that wants a complete history, and a poor one for a busy site, because nothing else bounds the table.

Estimating the growth

Row count is the whole story: one pageview, one row. A site taking 100,000 pageviews a month writes 100,000 rows a month, so at the default 420 days the live table settles at roughly 1.4 million rows and then stops growing, because purging removes as much as tracking adds.

The row width matters more than the count on a busy site. wp_slim_stats carries several VARCHAR(2048) columns — the referrer, the requested permalink, the search terms and the user agent — so real-world row sizes vary a great deal with your traffic mix. Measure rather than estimate:

SELECT table_name,
       table_rows,
       ROUND(data_length / 1024 / 1024) AS data_mb,
       ROUND(index_length / 1024 / 1024) AS index_mb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name LIKE '%slim_%';

If the archive tables turn out to be the larger half, that is Archive Mode doing exactly what it is set to do, and the fix is to switch it off and let the next purge clear them.

Related settings

Retention is not the only lever on table size. Excluding traffic you never want to count is cheaper than storing and then purging it — excluding your own visits, bots and specific traffic covers the fifteen exclusion settings, and bot filtering in particular removes rows that would otherwise be most of a small site’s table.

Settings, Maintenance also carries a Delete Records action for a one-off clear-out, and Delete Data on Uninstall, which is off by default — deleting the plugin leaves your stats and settings in place unless you turn it on first. The table structures the purge acts on are documented in SlimStat database tables and columns.