---
title: "20.9 GiB in 14 Days: One Integration Wrote 57% of the Rows"
description: My Home Assistant database hit 20.9 GiB in 14 days. One churning integration made 57% of the rows, and a blanket exclude would have cost energy history.
image: https://willcurran.com/hubfs/will-curran-brand/recorder-database-bloat-featured.png
---

[Skip to content](https://willcurran.com/blog/recorder-database-bloat#main)

[Will Curran](https://willcurran.com/)

[Home](https://willcurran.com/) [Portfolio](https://willcurran.com/portfolio) [Press](https://willcurran.com/media) [Blog](https://willcurran.com/blog) [Favorites](https://willcurran.com/favorites) [Speaking](https://willcurran.com/speaking) [Consulting](https://willcurran.com/consult) 

[Hire Will](https://willcurran.com/hire)

[Writing](https://willcurran.com/blog) Home — 20.9 GiB in 14 Days: One Integration Wrote 57% of the Rows [Subscribe](https://willcurran.com/blog/subscribe)

Home

# 20.9 GiB in 14 Days: One Integration Wrote 57% of the Rows

My Home Assistant history database held only 14 days and still reached 20.9 GiB, and about 57% of its rows came from one network integration rewriting device records for clients with randomized addresses. The post covers how to find your top writer without SQL, and why a blanket ...

![](https://willcurran.com/hs-fs/hubfs/will-curran-brand/will-curran-avatar.jpg?width=44&height=44&name=will-curran-avatar.jpg)

Will Curran Sep 5, 2026 · 5 min read

<https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwillcurran.com%2Fblog%2Frecorder-database-bloat>

On this page

![An abstract dark scene: a stack of thin horizontal bars, most of them marigold and a few grey, next to the title 20.9 GiB in 14 days.](https://willcurran.com/hs-fs/hubfs/will-curran-brand/recorder-database-bloat-featured.png?width=1600&height=900&name=recorder-database-bloat-featured.png)

In early September 2026 my Home Assistant history database was 20.9 GiB, and it held only 14 days. That works out to about 1.5 GiB a day. When I counted where the rows came from, about 57% traced back to a single integration, and those rows described no real change at all.

The cause was churn. A network integration kept rewriting the same device records for clients that use randomized network addresses. Each rewrite went into the history like a real change.

## The purge was doing its job

The recorder was set to keep 14 days, and it kept exactly 14 days.

The structural cause was in my own config. The recorder block had no include list and no exclude list, so every entity and every event type got written to the database. That is the default. With no filter, the database is only as quiet as the noisiest thing in the house.

## Count before you cut

The audit counted rows per table, per entity and per event type.

- **Events:** 97.9% of the events table was one event type, entity registry updates, produced by that one integration.
- **States:** 28% of the states table was the same integration's device tracker entities.
- **Attributes:** 58% of the attributes table was the text payload of a single sensor that carried a large blob in its attributes.
- **Energy:** the energy monitor's entities were also among the top writers by row count.

![Bar chart of how much of each database table came from the top source: 97.9% of the events table was one integration's entity registry updates, 28% of the states table was the same integration's device trackers, and 58% of the attributes table was one sensor's text payload.](https://willcurran.com/hs-fs/hubfs/will-curran-brand/recorder-database-bloat-where-rows-came-from.png?width=1440&height=656&name=recorder-database-bloat-where-rows-came-from.png)

The first line is the one that mattered. Almost the entire events table was one kind of bookkeeping event, coming from one source.

## What the churn looked like

Many phones and laptops present a different, randomized network address to each network they join, and some rotate it over time. The integration tracked those clients as devices. On those clients it kept flipping the link between the tracker entity and its device: set, then empty, then set again.

Each flip produced a registry update event and a fresh state row. Nothing about the device had changed, and the database recorded every flip anyway.

## The exclude that would have cost the energy history

The obvious move with a fat database is a big exclude list. The energy entities looked like an easy target, because they wrote a lot of rows.

That would have been a mistake. In Home Assistant, the long-term statistics behind the Energy dashboard were built from recorded states. Excluding an entity from the recorder also stopped its statistics from being generated. A blanket exclude would have saved space and quietly ended the energy history.

The same database showed why that history is worth keeping. The statistics had outlived the purge, as designed.

## The parts that were not magic

This was an audit, and that is all it was that day. I didn't purge, vacuum or change any config. The findings were a list of causes and an order of operations.

The order was the real result. Fix the integration's churn first, because that should remove more than half the rows at the source and clear a large number of junk entities out of the registry along with them. Only after that does it make sense to write an exclude list, and the list can then be short and deliberate.

The biggest writer was churn that described nothing. Counting rows was what found it.

## If you are about to try this

- **Do the size math first.** Database size divided by your keep days gives you a per-day rate. If the purge is keeping the right number of days, look for a noisy source.
- **Find the top writer before you exclude anything.** One misbehaving integration can outweigh everything else combined.
- **Look at events as well as states.** Registry and bookkeeping events can be most of the file and never show up on a history graph.
- **Check for long-term statistics before you exclude an entity.** Excluding it stops its statistics too, and energy history is the usual casualty.
- **Work on a copy.** Don't point outside database tools at the live file while Home Assistant is writing to it.

## Build it yourself

What it does: finds what is filling your Home Assistant history database, without writing any SQL. The steps:

1. **Get the rate.** Note the database size and your recorder's keep-days setting, and divide.
2. **Watch the stream.** In Developer Tools, under Events, listen to `state_changed` for a minute, then to `entity_registry_updated`. A steady stream of registry updates is churn. If the same few entities fill the state changes, those are your top writers.
3. **Check the statistics.** In Developer Tools, the Statistics tab lists which entities have long-term statistics. Treat those as off limits for an exclude until you decide you don't need their history.
4. **Fix the source.** If one integration is churning, look at its options and at the devices it creates before reaching for the recorder config.
5. **Then filter.** Write a short exclude list for whatever is left that you never use.

For exact counts per table and per entity, take a copy of the database with Home Assistant stopped, and hand the copy to an assistant or a database browser to tally.

Give this to your AIHelp me find out what is filling my Home Assistant recorder database. I will give you the database size, my recorder keep-days setting, and my recorder config. First, work out the per-day growth and tell me whether the purge looks healthy. Then walk me through Developer Tools step by step: listen to state change events and entity registry update events for a minute each, and help me read the results to find the top writers and any integration that is churning device records. If I give you a copy of the database (taken with Home Assistant stopped, never the live file), write and run the queries yourself and give me rows per table, per entity and per event type as percentages. Before you suggest any exclude, check whether that entity has long-term statistics, and warn me that excluding it stops them. Rank fixes with the noisy source first and recorder filters last, and do not change anything until I say so.

If your history database has a surprise top writer, I would like to hear which one.

Filed under [Home](https://willcurran.com/blog/tag/home)

![](https://willcurran.com/hs-fs/hubfs/will-curran-brand/will-curran-avatar.jpg?width=64&height=64&name=will-curran-avatar.jpg)

Will Curran

I spent sixteen years building one company, and I have been in the event industry since 2007. These days I write about the technology I actually use — trucks, radios, home infrastructure, and the tools that survive past the first invoice.

[All posts by Will →](https://willcurran.com/blog/author/will-curran)

Get the next one by email

One email per post. No digest, no sponsors.

[← Previous "Precise" Is Less Precise](https://willcurran.com/blog/precise-is-less-precise) [Next → Three Answers I Found in the Home Assistant iOS App's Source](https://willcurran.com/blog/three-answers-in-the-ios-app-source)

## Related reading

[Home The Heat Rating That Decides a Desert Garage Mini-Split 4 min read](https://willcurran.com/blog/desert-garage-mini-split-heat-rating) [Home Movie Mode Means the Robot Vacuum Waits 6 min read](https://willcurran.com/blog/movie-mode-vacuum) [Home A Holiday Color Engine with a Calendar Computed to 2099 7 min read](https://willcurran.com/blog/holiday-color-engine) [Home Party Mode: 49 Ramps Blocked, Zero During a Six-Hour Party 6 min read](https://willcurran.com/blog/party-mode)

[Will Curran](https://willcurran.com/)

[LinkedIn — 29,339+ followers](https://www.linkedin.com/in/willcurran) [GitHub](https://github.com/rancur) [YouTube](https://www.youtube.com/channel/UCJgscc27l4fpkWx1SeK05xg/) [Spotify](https://open.spotify.com/user/rancur) [SoundCloud DJ mixes](https://www.soundcloud.com/thewillsee) [Twitch](https://www.twitch.tv/thewillsee) [Last.fm](https://www.last.fm/user/default) [Trakt — movies & TV](https://trakt.tv/users/willcurran) [Goodreads](https://www.goodreads.com/user/show/55302838-will-curran) [Will See Music](https://www.thewillsee.com) [Arizona Meshtastic](https://azmsh.net) [Electric Forest Meshtastic](https://efmesh.com)

© 2026 Will Curran — All rights reserved. [RSS](https://willcurran.com/blog/rss.xml) [Back to top](https://willcurran.com/blog/recorder-database-bloat#main)

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Will Curran",
    "url" : "https://willcurran.com/blog/author/will-curran"
  },
  "dateModified" : "2026-10-22T23:26:40.471Z",
  "datePublished" : "2026-09-05T16:00:00.000Z",
  "headline" : "20.9 GiB in 14 Days: One Integration Wrote 57% of the Rows",
  "image" : [ "https://willcurran.com/hubfs/will-curran-brand/recorder-database-bloat-featured.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://willcurran.com/blog/recorder-database-bloat",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://willcurran.com/hubfs/image-1.png"
    },
    "name" : "Will Curran LLC"
  }
}
```