Home Assistant est livré avec SQLite, ce qui va bien pendant une semaine. Ensuite, les graphiques du tableau de bord commencent à traîner, le volet d’historique prend dix secondes à s’ouvrir, et la base de données du recorder gonfle à plusieurs gigaoctets parce que vos capteurs Zigbee écrivent toutes les 30 secondes. Changer le backend du recorder le corrige. Nous avons exécuté six bases de données contre la même instance (environ 140 entités, rétention de 30 jours) pour voir lequel rendait vraiment la maison intelligente à nouveau réactive.
Ce tour d’horizon s’adresse à tous ceux dont l’installation Home Assistant a dépassé la base de données par défaut. Docker ou bare-metal, nous couvrons les compromis que chaque backend apporte, ce qui casse pendant la migration, et lequel choisir si vous voulez aussi des tableaux de bord Grafana à long terme.
Ce qu’il faut rechercher dans un backend Home Assistant recorder
Quelques éléments importent plus que les benchmarks bruts :
- La latence sur les volets d’historique et de journal une fois que la BD dépasse 5 GB
- La façon dont le backend gère le modèle d’écriture de Home Assistant (beaucoup de petites insertions, quelques grandes requêtes)
- Si vous pouvez le requêter directement depuis Grafana ou Node-RED sans surcharger le recorder
- Les contrôles de rétention et de sous-échantillonnage, car garder une résolution complète indéfiniment est un gaspillage
- L’histoire de la sauvegarde, surtout si vous exécutez tout sur un SSD que vous aimeriez garder en vie
- Le chemin de migration depuis SQLite (pouvez-vous conserver l’historique ?)
Comparaison rapide
| Backend | Meilleur pour | Licence | Modèle de stockage | S’exécute sur |
|---|---|---|---|---|
| PostgreSQL | La plupart des installations | PostgreSQL | Row-store, ACID | Linux, Windows, macOS |
| MariaDB | Remplacement de plug-and-play | GPL | Row-store, ACID | Linux, Windows, macOS |
| TimescaleDB | Historique des capteurs à long terme | Apache 2.0 / TSL | Hypertables sur Postgres | Linux, Docker |
| InfluxDB 2.x | Tableaux de bord, sous-échantillonnage | MIT (core) | Time-series columnar | Linux, Windows, macOS |
| MySQL | Infrastructure MySQL existante | GPL | Row-store, ACID | Linux, Windows, macOS |
| VictoriaMetrics | Métriques à grande échelle | Apache 2.0 | Time-series columnar | Linux, Windows, macOS |
Les backends
1. PostgreSQL, le meilleur remplacement global du recorder
PostgreSQL est celui à choisir si vous n’êtes pas sûr. Home Assistant le supporte en natif, le pilote psycopg2 est stable, et la planification des requêtes tient bon à mesure que la base de données dépasse 10 GB. Le volet d’historique qui prenait huit secondes sur SQLite tombe sous une seconde sur une modeste machine quatre-cœurs une fois que les index sont chauds. Ajoutez la compression TOAST sur les tables states et events et l’utilisation du disque reste raisonnable.
Où il échoue : vous devez exécuter et sauvegarder une véritable base de données. Cela signifie un cron pg_dump, une archive WAL si vous tenez à la récupération point-in-time, et un plan pour ce qui se passe quand le disque est plein. Rien d’exotique, mais c’est plus de travail qu’un simple fichier .db.
Prix : Gratuit, open-source sous la licence PostgreSQL. Pas de niveau payant.
Plateformes : Linux, Windows, macOS, Docker, et tout NAS avec un paquet Postgres.
Télécharger : postgresql.org
Conclusion : Choisissez PostgreSQL en premier, et ne regardez ailleurs que si vous avez une raison spécifique.
2. MariaDB, le fork que la plupart des guides supposent toujours
MariaDB est le backend que la documentation de Home Assistant utilise par défaut dans son exemple, et reste un choix solide pour quiconque l’exécute déjà. La configuration est documentée jusqu’au bloc YAML recorder: exact, et il y a un add-on MariaDB dans Home Assistant OS qui gère l’installation pour vous. Les performances sont dans le même ordre que Postgres pour la charge de travail du recorder.
Où il échoue : les migrations de schéma sous charge d’écriture lourde verrouillent parfois suffisamment longtemps la table states pour que le recorder enregistre des avertissements de contre-pression. Rien de catastrophique, mais vous le voyez. Les outils de style MySQL semblent aussi plus anciens que l’écosystème Postgres.
Prix : Gratuit, open-source sous GPLv2.
Plateformes : Linux, Windows, macOS, Docker, add-on HAOS natif.
Télécharger : mariadb.org
Conclusion : Le choix le plus sûr si vous voulez un chemin supporté et documenté avec le moins de surprises.
3. TimescaleDB, Postgres ajusté pour l’historique des capteurs
TimescaleDB s’exécute comme une extension PostgreSQL et convertit les tables de séries chronologiques en hypertables qui sont automatiquement partitionnées par temps. Pour une maison intelligente enregistrant des milliers de changements d’état par jour, cela signifie que vous pouvez conserver une année de données et obtenir quand même des requêtes sub-seconde. Les agrégats continus vous permettent de pré-calculer les moyennes quotidiennes afin que les panneaux Grafana ne scannent pas les lignes brutes.
Où il échoue : vous devez acheminer le recorder de Home Assistant via Postgres normalement, puis convertir les tables en hypertables avec une commande SQL manuelle. Pas difficile, mais ce n’est pas une simple case à cocher. La Licence Timescale (TSL) sur certaines fonctionnalités d’entreprise n’est pas entièrement open-source, bien que l’édition communautaire couvre tout ce dont le recorder a besoin.
Prix : Édition communautaire gratuite ; Timescale Cloud payant commence autour de $30/mois pour les instances hébergées.
Plateformes : Linux, Docker, Timescale Cloud. Pas de paquets Windows ou macOS natifs, bien que WSL fonctionne.
Télécharger : timescale.com
Conclusion : La meilleure histoire de rétention à long terme des six, si vous êtes à l’aise en exécutant une extension sur Postgres.
4. InfluxDB 2.x, tableaux de bord plus que recorder
InfluxDB n’est pas vraiment un remplacement du recorder, c’est l’appairage classique qui vit à côté de Home Assistant. L’intégration influxdb envoie les changements d’état à InfluxDB en parallèle avec n’importe quel backend SQL qu’utilise le recorder, et Grafana extrait d’Influx pour les jolis tableaux de bord. Les requêtes Flux vous permettent de sous-échantillonner sans cronjobs.
Où il échoue : le langage de requête Influx a changé entre 1.x, 2.x et 3.x, donc la moitié des tutoriels que vous trouvez sont obsolètes. Et comme il ne remplace pas le recorder, vous exécutez deux bases de données au lieu d’une.
Prix : InfluxDB 2.x OSS open-source gratuit ; InfluxDB Cloud a un niveau gratuit et la tarification au paiement à l’usage au-dessus.
Plateformes : Linux, Windows, macOS, Docker, add-on HAOS.
Télécharger : influxdata.com
Conclusion : Utilisez-le à côté d’un recorder SQL quand vous voulez de vrais tableaux de bord Grafana, pas comme remplacement du recorder.
5. MySQL, seulement si vous l’exécutez déjà
MySQL fonctionne avec Home Assistant, et si vous avez déjà un serveur MySQL fonctionnant pour un autre service, ajouter une base de données du recorder y est simple. Le pilote mysqlclient est bien rodé, et le recorder ne le pousse pas fort.
Où il échoue : MariaDB est un fork de remplacement direct que la plupart des guides Home Assistant ciblent directement, vous finissez donc par traduire les instructions. Les licences d’Oracle autour de MySQL Enterprise ajoutent une complication si vous aviez jamais voulu le support payant.
Prix : MySQL Community Edition gratuit ; les niveaux Enterprise payants commencent autour de $2 000/an.
Plateformes : Linux, Windows, macOS, Docker.
Télécharger : mysql.com
Conclusion : Choisissez-le uniquement si vous avez déjà une instance MySQL que vous voulez réutiliser.
6. VictoriaMetrics, quand le recorder est le goulot d’étranglement
VictoriaMetrics brille quand vous avez des centaines d’entités et le recorder lui-même devient la partie lente. Il ingère via un endpoint compatible avec Prometheus, l’intégration prometheus de Home Assistant l’alimente directement. Le stockage est environ 10 fois plus compact que InfluxDB pour les mêmes données.
Où il échoue : c’est métriques uniquement. Vous n’obtenez pas l’historique d’état de la même façon que le recorder vous le donne, le volet d’historique intégré a toujours besoin d’un backend SQL. C’est un supplément, pas un remplacement.
Prix : Open-source gratuit ; VictoriaMetrics Enterprise pour les déploiements importants a une tarification personnalisée.
Plateformes : Linux, Windows, macOS, Docker.
Télécharger : victoriametrics.com
Conclusion : Le magasin de métriques vers lequel se tourner quand vos exports Prometheus deviennent volumineux et Influx commence à sembler lourd.
Comment choisir le bon
Si vous voulez juste que votre tableau de bord se sente rapide : PostgreSQL, et arrêtez de lire ici.
Si vous suivez les guides de près et voulez le chemin documenté : MariaDB.
Si vous prévoyez de conserver des années d’historique de capteurs et de l’interroger plus tard : TimescaleDB sur PostgreSQL.
Si votre objectif est vraiment de jolis tableaux de bord Grafana avec sous-échantillonnage : gardez le recorder sur Postgres ou MariaDB, et ajoutez InfluxDB pour la couche de métriques.
Si votre installation Home Assistant est vraiment énorme (500+ entités, millions+ de changements d’état par jour) : associez PostgreSQL comme recorder avec VictoriaMetrics pour les métriques de style Prometheus.
Ignorez MySQL à moins que vous ne l’exécutiez déjà pour autre chose.
FAQ
PostgreSQL est-il plus rapide que SQLite pour Home Assistant ?
Oui, une fois que votre base de données dépasse quelques gigaoctets. Sur les petites installations, SQLite est comparable, mais les volets d’historique et de journal sont nettement plus rapides sur PostgreSQL à mesure que les données se développent, car la planification des requêtes et les lectures concurrentes se mettent à l’échelle mieux.
Puis-je migrer mon historique SQLite vers PostgreSQL sans perdre de données ?
Oui, en utilisant pgloader ou un dump/restore manuel, mais c’est compliqué. La plupart des utilisateurs recommencent avec le nouveau backend et acceptent la perte d’historique ancien plutôt que de lutter avec la conversion de schéma.
Home Assistant prend-il en charge InfluxDB comme remplacement du recorder ?
Non. InfluxDB fonctionne à côté du recorder via l’intégration influxdb, diffusant les changements d’état en parallèle. Le recorder lui-même a toujours besoin de SQLite, PostgreSQL, MariaDB ou MySQL.
Quel est le meilleur backend pour l’historique Home Assistant à long terme ?
TimescaleDB. Les agrégats continus et le partitionnement basé sur le temps vous permettent de conserver un an ou plus de données et d’obtenir quand même des requêtes rapides. VictoriaMetrics est proche si vous ne vous souciez que des métriques numériques.
Changer le backend du recorder cassera-t-il mes automatisations ?
Non. Les automatisations lisent la machine d’état de Home Assistant, pas la base de données du recorder. Le changement de backend affecte l’historique, les statistiques et la rétention à long terme, pas l’état actif.