Planner · runs in your browser
Your database is enormous. Here is what to do about it
Recorder writes every state change of every entity, and a handful of them account for most of the file. This works out which, and gives you the config — but first it tells you which entities you must not exclude.
Read this before you exclude anything. There are two ways to shrink the database and they are not equivalent. purge_keep_days throws away raw history and keeps long-term statistics. exclude: stops recording the entity at all — and its statistics stop with it. Exclude an energy sensor and the Energy dashboard quietly stops filling in, with nothing in the log to tell you.
What you have now
The size is in Settings → System → Storage, or it is the home-assistant_v2.db file in your config folder. Your own numbers calibrate the estimate — published bytes-per-row figures are useless, they changed when the states table was split and they differ several times over between SQLite and MariaDB.
What is doing the writing
Roughly how many of each you have. You do not need to be exact — this works out proportions, not absolutes.
| Source | How many | Exclude |
|---|
If you already have a recorder: block, merge into it. Two recorder: keys in one file is a configuration error and Home Assistant will not start. Fold these keys into the block you have rather than pasting a second one.
The two knobs, and why only one of them is safe
| purge_keep_days | exclude: | |
|---|---|---|
| Raw history | Kept for N days | Never recorded |
| Long-term statistics | Kept, indefinitely | Stop being generated |
| Energy dashboard | Unaffected | Stops filling in |
| Reversible | Not really — history already purged is gone. What survives either way is the statistics | The gap stays a gap, forever |
Which is why the order matters. Cut the days first: it costs you nothing but raw history, and every statistic survives. Then exclude the rows marked history only — they have no state_class, so there were never any statistics there to lose. Only then think about the watt readings, and never about the kWh totals.
After you change it
Do not tick apply_filter. It sits right next to repack in the same dialog and the forums recommend it freely. It permanently deletes the history already recorded for everything your new filter excludes — the opposite of what you came here for. Leave it off and let the nightly purge work through it.
The setting only stops new data. Nothing already written goes away on its own, so the file stays the same size until the next nightly purge — and even then SQLite does not hand the space back to the disk unless it repacks. To make it happen now, go to Developer tools → Actions and run recorder.purge with repack: true. On a big database that takes a while and needs as much free disk as the file itself.
Questions people ask
Why is my database so big?
Almost always a few entities updating every few seconds: a power meter, a Bluetooth proxy, a system monitor. A sensor writing every 10 seconds produces 8,640 rows a day on its own — as much as sixty ordinary sensors put together.
Will excluding my power sensors break the Energy dashboard?
No. The Energy dashboard runs on the kWh totals, not on the watt readings, so excluding sensor.*_power leaves it working. What you do lose is the long-term graph of that sensor — you can still see the last few days, but not last month. It is the kWh sensors you must never exclude.
So what happens if I exclude a kWh sensor?
The Energy dashboard stops filling in. Excluding an entity stops the recorder generating its long-term statistics, and the dashboard is built on those. There is nothing in the log, and the missing days never come back, because those statistics are simply never written.
What is safe to exclude, then?
Anything with no state_class — device_tracker, automation, update, the time and date sensors. Those never had statistics to lose, so excluding them costs you history and logbook entries and nothing else.
How long do long-term statistics last?
They are not purged. A sensor with a state_class gets hourly statistics kept indefinitely, which is why you can run 7 days of raw history and still have a year of energy charts.
I changed the setting and the file is the same size.
The setting only affects new data. Old rows go at the next nightly purge, and SQLite does not return the freed space to the disk until it repacks. Run recorder.purge with repack: true from Developer tools → Actions.
Should I move to MariaDB?
It handles a large database better and repacks less painfully, but it does not write less. If a few entities are producing most of your rows, fix that first — otherwise you get the same problem on a different engine.