Home Assistant ships with SQLite, and that is fine for a week. Then the dashboard graphs start lagging, the history panel takes ten seconds to open, and the recorder database grows to a few gigabytes because your Zigbee sensors write every 30 seconds. Swapping the recorder backend fixes it. We ran six databases against the same instance (roughly 140 entities, 30-day retention) to see which one actually made the smart home feel snappy again.
This roundup is for anyone whose Home Assistant install has outgrown the default database. Docker or bare-metal, we cover the trade-offs each backend brings, what breaks during migration, and which one to pick if you also want long-term Grafana dashboards.
What to look for in a Home Assistant recorder backend
A few things matter more than raw benchmarks:
- Latency on the history and logbook panels once the DB passes 5 GB
- How well the backend handles Home Assistant’s write pattern (lots of small inserts, occasional big queries)
- Whether you can query it directly from Grafana or Node-RED without hammering the recorder
- Retention and downsampling controls, because keeping full resolution forever is wasteful
- Backup story, especially if you run everything on an SSD you would like to keep alive
- Migration path from SQLite (do you get to keep the history?)
Quick comparison
| Backend | Best for | License | Storage model | Runs on |
|---|---|---|---|---|
| PostgreSQL | Most installs | PostgreSQL | Row-store, ACID | Linux, Windows, macOS |
| MariaDB | Drop-in replacement | GPL | Row-store, ACID | Linux, Windows, macOS |
| TimescaleDB | Long-term sensor history | Apache 2.0 / TSL | Hypertables on top of Postgres | Linux, Docker |
| InfluxDB 2.x | Dashboards, downsampling | MIT (core) | Time-series columnar | Linux, Windows, macOS |
| MySQL | Existing MySQL infra | GPL | Row-store, ACID | Linux, Windows, macOS |
| VictoriaMetrics | Metrics at scale | Apache 2.0 | Time-series columnar | Linux, Windows, macOS |
The backends
1. PostgreSQL, best overall recorder replacement
PostgreSQL is the one to pick if you are not sure. Home Assistant’s recorder integration supports it natively, the psycopg2 driver is stable, and query planning holds up as the database grows past 10 GB. The history panel that took eight seconds on SQLite drops under one second on a modest four-core box once the indexes warm up. Add TOAST compression on the states and events tables and disk usage stays sensible.
Where it falls short: you have to run and back up a real database. That means a pg_dump cron, a WAL archive if you care about point-in-time recovery, and a plan for what happens when the disk fills. None of it is exotic, but it is more work than a single .db file.
Pricing: Free, open-source under the PostgreSQL license. No paid tier.
Platforms: Linux, Windows, macOS, Docker, and every NAS with a Postgres package.
Download: postgresql.org
Bottom line: Pick PostgreSQL first, and only look elsewhere if you have a specific reason.
2. MariaDB, the fork most guides still assume
MariaDB is the backend Home Assistant’s docs default to in their example, and it stays a solid pick for anyone already running it. Setup is documented down to the exact recorder: YAML block, and there is a MariaDB add-on in Home Assistant OS that handles the install for you. Performance is in the same ballpark as Postgres for the recorder workload.
Where it falls short: schema migrations under heavy write load occasionally lock the states table long enough that the recorder logs backpressure warnings. Nothing catastrophic, but you see it. MySQL-flavored tooling also feels older than the Postgres ecosystem.
Pricing: Free, open-source under GPLv2.
Platforms: Linux, Windows, macOS, Docker, native HAOS add-on.
Download: mariadb.org
Bottom line: The safest choice if you want a supported, documented path with the least surprises.
3. TimescaleDB, Postgres tuned for sensor history
TimescaleDB runs as a PostgreSQL extension and turns time-series tables into hypertables that are automatically partitioned by time. For a smart home logging thousands of state changes a day, that means you can keep a year of data and still get sub-second range queries. Continuous aggregates let you pre-compute daily averages so Grafana panels do not scan raw rows.
Where it falls short: you have to route Home Assistant’s recorder through Postgres normally, then convert the tables to hypertables with a manual SQL command. Not hard, but not a checkbox. The Timescale License (TSL) on some enterprise features is not fully open source, though the community edition covers everything the recorder needs.
Pricing: Free community edition; paid Timescale Cloud starts at around $30/month for hosted instances.
Platforms: Linux, Docker, Timescale Cloud. No native Windows or macOS packages, though WSL works.
Download: timescale.com
Bottom line: Best long-term retention story of the six, if you are comfortable running an extension on top of Postgres.
4. InfluxDB 2.x, dashboards more than recorder
InfluxDB is not really a recorder replacement, it is the classic pairing that lives next to Home Assistant. The influxdb integration streams state changes into InfluxDB in parallel with whatever SQL backend the recorder is using, and Grafana pulls from Influx for the pretty dashboards. Flux queries let you downsample without cronjobs.
Where it falls short: the Influx query language changed between 1.x, 2.x, and 3.x, so half the tutorials you find are out of date. And because it does not replace the recorder, you are running two databases instead of one.
Pricing: Free open-source InfluxDB 2.x OSS; InfluxDB Cloud has a free tier and pay-as-you-go pricing above it.
Platforms: Linux, Windows, macOS, Docker, HAOS add-on.
Download: influxdata.com
Bottom line: Use it alongside a SQL recorder when you want serious Grafana dashboards, not as a recorder replacement.
5. MySQL, only if you already run it
MySQL works with Home Assistant, and if you already have a MySQL server humming along for another service, adding a recorder database to it is straightforward. The mysqlclient driver is well-worn, and the recorder does not push it hard.
Where it falls short: MariaDB is a drop-in fork that most Home Assistant guides target directly, so you end up translating instructions. Oracle’s licensing around MySQL Enterprise adds a wrinkle if you ever wanted paid support.
Pricing: Free MySQL Community Edition; paid Enterprise tiers start around $2,000/year.
Platforms: Linux, Windows, macOS, Docker.
Download: mysql.com
Bottom line: Pick it only if you already have a MySQL instance you want to reuse.
6. VictoriaMetrics, when the recorder is the bottleneck
VictoriaMetrics shines when you have hundreds of entities and the recorder itself becomes the slow part. It ingests via a Prometheus-compatible endpoint, so the Home Assistant prometheus integration feeds it directly. Storage is roughly 10x more compact than InfluxDB for the same data.
Where it falls short: it is metrics-only. You do not get state history the same way the recorder gives it to you, so the built-in history panel still needs a SQL backend. This is a supplement, not a replacement.
Pricing: Free open-source; VictoriaMetrics Enterprise for large deployments has custom pricing.
Platforms: Linux, Windows, macOS, Docker.
Download: victoriametrics.com
Bottom line: The metrics store to reach for when your Prometheus exports get chunky and Influx starts feeling heavy.
How to pick the right one
If you just want your dashboard to feel fast: PostgreSQL, and stop reading here.
If you follow guides closely and want the documented path: MariaDB.
If you plan to keep years of sensor history and query it later: TimescaleDB on top of PostgreSQL.
If your goal is really nice Grafana dashboards with downsampling: keep the recorder on Postgres or MariaDB, and add InfluxDB for the metrics layer.
If your Home Assistant install is genuinely huge (500+ entities, million-plus state changes a day): pair PostgreSQL as the recorder with VictoriaMetrics for Prometheus-style metrics.
Skip MySQL unless you already run it for something else.
FAQ
Is PostgreSQL faster than SQLite for Home Assistant?
Yes, once your database passes a few gigabytes. On small installs SQLite is comparable, but the history and logbook panels get noticeably faster on PostgreSQL as data grows, because query planning and concurrent reads scale better.
Can I migrate my SQLite history to PostgreSQL without losing data?
Yes, using pgloader or a manual dump/restore, but it is fiddly. Most users start fresh with the new backend and accept the loss of old history rather than fight the schema conversion.
Does Home Assistant support InfluxDB as a recorder replacement?
No. InfluxDB works alongside the recorder through the influxdb integration, streaming state changes to it in parallel. The recorder itself still needs SQLite, PostgreSQL, MariaDB, or MySQL.
What is the best backend for long-term Home Assistant history?
TimescaleDB. Continuous aggregates and time-based partitioning let you keep a year or more of data and still get fast queries. VictoriaMetrics is close if you only care about numeric metrics.
Will changing the recorder backend break my automations?
No. Automations read from Home Assistant’s state machine, not the recorder database. Swapping the backend affects history, statistics, and long-term retention, not live state.