Home Assistant long-term storage: do you need any?

What Home Assistant already does

Two separate mechanisms, and confusing them is the source of most of the panic.

Home Assistant's own documentation is explicit about the second one: the long-term statistics table is never purged, because an hourly summary is only 24 rows a day per entity. That is genuinely forever, on your hardware, at no cost.

The three cases where it runs out

1. The entity has no state_class

Long-term statistics only cover sensors whose state_class is measurement, total or total_increasing. Everything else gets recorder history and nothing more — so it disappears after ten days.

This bites more often than people expect. Helper entities cannot have a state_class at all, and integrations ship sensors without one often enough that it is a recurring bug report. Check in Developer Tools → States: if the attribute is not there, that sensor has a ten-day memory.

Tag Historian does not care about state_class. It stores whatever numeric state it is sent.

2. You need full resolution older than the recorder window

Hourly min/max/mean is the right shape for trends and the wrong shape for incidents. “What exactly did the pressure do in the ninety seconds before the pump tripped, three months ago?” is not an hourly question, and no amount of statistics will answer it.

The free fix first: raise purge_keep_days. It costs nothing but disk.

recorder:
  purge_keep_days: 30
  # Everything not listed here is still purged after 30 days.
  # This grows the database. Watch the disk.

This works, and it works right up until the database is large enough to be a problem in its own right — which, on an SD card, arrives sooner than anyone expects. If your answer to “how big will it get?” is a shrug, this is a temporary fix.

For reference, Tag Historian keeps full resolution for 14 days on the free plan, 6 months on Pro (€9/month) and 2 years on Business.

3. The history is on the machine that might die

This is the case nobody frames properly, and it is the one that actually costs people years of data.

Your automations and your history live on the same box, on the same card. A corrupted database, a dead SD card, a failed restore that brings the config back but eats the energy dashboard — every one of those takes the history with it, and the standard advice (“buy an SSD”, “move the database to a NAS”) replaces one machine you own and can lose with another machine you own and can lose.

History that matters to you should not live only on the device that runs your automations. That is the whole argument, and it is the only one of the three that a second Raspberry Pi does not solve.

If you are in one of those cases, the options

The catch in the free hosted tiers

Both of the obvious hosted free tiers cap the exact thing you came for. Read from each vendor's own page on 2026-08-11:

Fourteen and thirty days. If the problem you are solving is “my history stops after ten days”, a free tier that stops after fourteen has not solved it.

What we are and are not better at

Plainly, because you can check every line of this.

• Not a differentiator: ten years of hourly summaries. We keep hourly min/max/average/count for ten years on every plan and it is a real feature — but Home Assistant keeps hourly min/max/mean forever, free, locally. Anyone who tells you the ten years is the reason to pay is hoping you have not read the Home Assistant docs.
• Differentiator: it works without a state_class. Helpers, template sensors, integrations that forgot the attribute — all stored the same way.
• Differentiator: full resolution, not hourly. 6 months on Pro, 2 years on Business, versus hourly-only past the recorder window.
• Differentiator: it is not on the SD card. Azure Sweden Central, with a nightly backup to a geo-redundant vault in the paired Swedish region. Both recovery point objectives are published on where your data lives, including the bad one.
• Worse: you cannot query it from Home Assistant. This is a one-way copy — your HA charts still come from HA's own database. Ours are in our app and in Grafana: the Infinity data source charts Tag Historian on any Grafana, Grafana Cloud's free tier included (see the Grafana guide). If the panels must live inside a Home Assistant dashboard specifically, a local InfluxDB is still the better fit.
• Worse: attributes are not stored. Only the numeric state. Getting an attribute in means making it a template sensor, which costs another tag.
• Worse: it costs money past 5 tags. A local InfluxDB does not.

If you decide to do it

The simplest path is Home Assistant's built-in influxdb integration — nothing to install, five lines of YAML and a restart, and there are four settings that decide whether it works properly. If you would rather click than write YAML, there is also an optional Tag Historian custom component installed through HACS. Both are on the Home Assistant guide.