Retention and Auto-Purge: Controlling Database Growth

SlimStat stores recorded pageviews and interactions in your analytics database. SlimStat → Settings → Maintenance controls how long live records remain and whether older records are archived or deleted.

Existing sites keep their settings. Choose a retention period from your reporting needs and privacy obligations; the default is not a legal determination for your site.

Archiving is not deletion

Archived rows still exist and may contain personal data. Disabling Archive Mode changes future purges; it does not empty existing archives. Delete Records also clears live records, not all archived history. Include archive tables and backups in any erasure or retention process.

Ecommerce and heatmap retention

Optional Ecommerce reporting follows the analytics retention period; 0 means no automatic expiry. Expired commerce data is excluded from reports while background cleanup removes it in bounded jobs. Removing a retained entry pageview also removes its order association, so attribution coverage can change.

Additional heatmap capture rows are purged with the site’s retention setting and participate in personal-data erasure. The element dictionary is not an age-based event archive. Delete heatmap data removes additional capture history while preserving ordinary link/button events. Turning recording off does not erase existing data.

Include these optional tables in backups and privacy procedures. Uninstall follows the same delete-data setting. Ecommerce setup and heatmap setup explain their separate storage.

What v6 changes

With archiving enabled, events are archived before their parent pageviews are deleted. The purge checks for archive collisions and copy failures before deleting through them. Pending schema migrations can affect which columns exist, so review maintenance notices rather than assuming every scheduled run succeeded.

OPTIMIZE TABLE no longer runs on all tables at every purge. It is limited to live stats/events after pageviews were removed and more than 30 days have passed since the last optimization. Table optimization can still rebuild and lock tables; a smaller logical dataset does not guarantee immediate disk-space recovery.

Configure and verify

1. Back up if changing a large existing dataset.
2. Set Retention Period under Settings → Maintenance.
3. Choose Archive Mode deliberately, then save.
4. Check that WordPress cron runs. The purge is scheduled twice daily, but WP-Cron depends on traffic unless your host runs it separately.
5. Review purge status and maintenance notices after the next run.

Measure growth

Database growth depends on recorded traffic, row contents, indexes, retention and archives. The following query estimates storage; TABLE_ROWS is an estimate for InnoDB, not an exact count:

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_%';

Run it against the configured analytics database. Use a deliberate COUNT(*) only when an exact count is needed, since counting a large table has a cost.

See database tables and excluding unwanted traffic.