Why Can Home Assistant History Queries Slow as Recorder Data Grows?

Home Assistant does not have one universal “search” engine whose speed falls with every added entity. The clearer scaling problem is historical query work: the History panel, Logbook-like views, statistics, and other database-backed features must retrieve and organize retained Recorder data.

As that dataset grows, the cost of a request depends on how many rows match, which indexes can narrow them, whether attributes must be joined, how much data is already in memory, and how quickly storage can deliver missing pages. Database size matters, but query shape matters just as much.

History Reads From Recorder, Not From the Live State Machine Alone

Current device values live in Home Assistant's runtime state model, while the History integration reads stored observations from Recorder. A dashboard card showing the current temperature and a five-day History graph therefore use different data paths.

Home Assistant documents that History depends on Recorder and normally reads raw Recorder data inside the configured retention window. When the selected range extends beyond that window for eligible sensors, it can use hourly long-term statistics instead.

This is why a large historical database can make History feel slow while a local light automation still reacts instantly.

More Retained State Means More Rows, Metadata, and Index Work

Every recorded update adds information to the database. Home Assistant reduces duplication by separating entity identifiers and shared attributes into related tables, but a busy installation can still accumulate large numbers of state rows.

The current Home Assistant data model shows that recorded states reference entity metadata and shared attribute rows and include indexed timestamps and relationships used by historical queries. Fast-changing entities therefore increase more than the human-readable value count.

Retention length and update frequency multiply each other. A sensor that changes every second creates a very different working set from one that changes twice per day, even if both are “one entity.”

Indexes Reduce Search Work but Do Not Make Result Size Free

SQLite can use indexes to avoid scanning every row for common query constraints and ordering. That is essential for History, but an index does not eliminate the cost of returning a large matching range or joining associated data.

SQLite's query-planner documentation explains that indexes accelerate lookup and ordering, while large result sets, row lookups, and sorts still carry work proportional to the selected data and plan. The planner chooses among available paths based on estimated cost.

That means “the database has an index” and “this query stays constant-time forever” are not equivalent claims. Wider time ranges and noisier entities can still make more pages and rows relevant.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recorder Retention Is a Performance and Capacity Control

Home Assistant automatically purges Recorder data so detailed state does not grow indefinitely. Increasing retention gives more full-resolution history but also increases the live historical working set, backup size, and maintenance work.

The Recorder documentation explicitly warns that allowing the database to grow too large consumes disk space and can make Home Assistant slow. Its default purge and repack behavior exists partly to keep database growth bounded.

The right retention period is therefore a product requirement. Keep high-resolution data long enough to answer real household questions, not merely because the disk has room.

Storage and Cache Determine How Expensive the Same Query Feels

A repeated History request can be faster because database and filesystem pages are already resident in memory. The same query after restart or under memory pressure may need more physical reads. Another service writing heavily to the same SSD can also increase latency without changing the SQL request.

The ZimaSpace analysis of Home Assistant metadata and history growth explains the write-side causes. Query performance is the read-side consequence: more retained state matters most when the selected range or working set actually touches it.

Measure query time together with storage latency and memory pressure before moving databases or buying faster hardware.

Reduce Query Cost by Reducing Unnecessary Data, Not Useful History

• Exclude entities whose historical changes have no decision value.
• Reduce update frequency at the source when high-frequency changes are not useful.
• Keep raw retention aligned with the time range users actually inspect.
• Use long-term statistics for long horizons where hourly aggregates are sufficient.
• Keep Recorder on reliable low-latency storage with free-space headroom.
• Compare the same History range before and after each change.

The useful metric is not database size alone. It is how query latency changes as retained rows, requested time range, cache state, and storage conditions change.

FAQ

Does a larger Recorder database automatically make local automations slower?

No. Live device control and historical queries are separate paths. They can affect each other indirectly when Recorder work creates shared CPU, memory, or storage contention, but a slow History graph does not prove that the automation engine is slow.