Home Assistant peut utiliser une base de données Recorder externe sans rendre chaque mise à niveau fragile, mais la base devient un service avec état distinct qui doit être en ligne, compatible, accessible en écriture, sauvegardé et récupérable lorsque Home Assistant effectue des opérations sur le schéma. Déplacer Recorder hors de l’hôte ne supprime pas les opérations sur la base de données ; cela vous en confie davantage.
Le modèle le plus sûr consiste à maintenir Home Assistant et la base de données selon des cycles de vie indépendants, mais coordonnés. Sauvegardez les deux, évitez les versions de base de données non prises en charge, conservez les autorisations nécessaires aux migrations de schéma et testez la restauration avant d’autoriser des mises à niveau sans surveillance des deux côtés simultanément.
Utilisez un backend Recorder réellement pris en charge par Home Assistant
Une base de données externe doit être configurée via Recorder plutôt que traitée comme un point d’accès SQL générique. MariaDB est une option courante, et l’application MariaDB maintenue par Home Assistant documente la base de données, l’utilisateur, les privilèges et la chaîne de connexion Recorder nécessaires au service.
La documentation actuelle de Recorder de Home Assistant répertorie MariaDB, MySQL, PostgreSQL et SQLite comme des backends pris en charge, tout en conservant SQLite comme base de données par défaut et recommandée. Une base de données externe est donc prise en charge, mais il s’agit d’un choix opérationnel et non d’un parcours de mise à niveau obligatoire.
Ne réduisez pas arbitrairement le compte Recorder à des autorisations de lecture et d’écriture uniquement si les migrations peuvent nécessiter la création d’index, la modification de tables ou la mise à jour d’objets de schéma. Utilisez plutôt un compte distinct en lecture seule pour les outils d’analyse.
Les mises à niveau de Home Assistant peuvent inclure des migrations du schéma Recorder
Un changement de version de Home Assistant peut nécessiter la migration du schéma de la base de données Recorder avant que l’historique et les statistiques redeviennent normaux. Pendant cette période, les performances de la base de données peuvent temporairement diminuer, et un redémarrage en cours de migration peut compliquer la récupération.
Recorder de Home Assistant peut devoir mettre à jour son schéma lors d’un changement de version, tandis que le serveur de base de données suit son propre cycle de mise à niveau. Les recommandations de mise à niveau de MariaDB pour 2026 préconisent d’effectuer une sauvegarde complète, d’examiner la version cible, d’exécuter les outils de mise à niveau de la base de données et de valider l’application après la modification du serveur.
Avant une mise à niveau majeure de Home Assistant, effectuez une sauvegarde cohérente de la base de données et vérifiez l’espace libre ainsi que son état. Si vous prévoyez également de mettre à niveau MariaDB, MySQL ou PostgreSQL, évitez de modifier les deux produits simultanément, sauf si votre plan de retour en arrière couvre les deux versions.
La disponibilité externe fait désormais partie de la fiabilité de Recorder
Une base de données externe ajoute le DNS, le réseau, l’authentification, le processus serveur, le stockage et la disponibilité de la base de données au parcours de Recorder. Home Assistant peut continuer à exécuter les automatisations locales alors que l’historique est défaillant ; une panne de base de données peut donc être moins évidente qu’une panne de Core.
Un problème Recorder récent datant de 2026 illustre ce risque opérationnel : dans l’environnement signalé, une connexion PostgreSQL perdue après un démarrage normal a empêché Recorder d’écrire jusqu’au redémarrage de Home Assistant.
Considérez cela comme un mode de défaillance observé sur le terrain, et non comme une garantie universelle pour chaque version. Surveillez les nouvelles écritures de Recorder et les erreurs de connexion afin qu’une brève panne de la base de données externe ne se transforme pas silencieusement en plusieurs heures d’historique manquant.
Les tests de restauration doivent inclure la version du serveur de base de données
Un dump SQL qui se restaure dans une version donnée de la base de données ne prouve pas qu’il se restaurera dans toutes les versions futures. Les moteurs de base de données possèdent leurs propres règles de schéma et changements de compatibilité, indépendamment de Home Assistant.
Le format de sauvegarde est également important. Les recommandations de sauvegarde de MariaDB distinguent les sauvegardes SQL logiques, relativement portables, des sauvegardes physiques, plus étroitement liées aux fichiers de la base de données et à l’environnement serveur. Testez la véritable cible de restauration au lieu de supposer que toutes les archives sont interchangeables entre les futures versions de la base de données.
Conservez ensemble, dans le dossier de récupération, la version de Home Assistant, le moteur de base de données, la version de la base de données, l’emplacement de la chaîne de connexion, la méthode de sauvegarde et la procédure de restauration.
Ne séparez la base de données que si cette frontière supplémentaire est justifiée
Une base de données externe peut être pertinente lorsque plusieurs services dépendent déjà d’une plateforme de base de données gérée, lorsque l’hôte Home Assistant est éphémère ou lorsque les règles de stockage et de sauvegarde de la base de données sont délibérément centralisées. Elle n’est pas automatiquement plus rapide ou plus sûre que SQLite en local.
L’article de ZimaSpace consacré à la séparation du stockage avec état et du calcul à charge variable propose le même critère architectural : ne séparez les rôles que lorsque leur cycle de vie indépendant, leur frontière de défaillance ou leur profil de ressources justifie la dépendance supplémentaire au réseau et à la récupération.
Si la base de données externe crée davantage de couplage lors des mises à niveau qu’elle n’en élimine, revenez à une architecture prise en charge plus simple plutôt que de la conserver uniquement parce que l’expression « base de données externe » semble plus évolutive.
FAQ
Ai-je besoin de MariaDB ou de PostgreSQL pour une installation Home Assistant de grande taille ?
Non. Le backend SQLite par défaut de Home Assistant reste un choix valide et recommandé. Passez à une base de données externe uniquement si vous avez une raison opérationnelle mesurée et si vous êtes prêt à prendre en charge le service supplémentaire.
Dois-je mettre à niveau Home Assistant et la base de données externe le même jour ?
Il est préférable de ne modifier qu’une seule couche avec état à la fois. Commencez par effectuer une sauvegarde, vérifiez la base de données dans sa version actuelle, mettez à niveau un composant, validez Recorder, puis envisagez seulement la seconde mise à niveau.
Assistance et conseils
Plus à lire

Signes indiquant qu’une base de données Home Assistant nécessite une maintenance ou un remplacement
Une grande base de données Home Assistant nécessite généralement une gestion de la rétention ou une purge ; des corruptions répétées ou des erreurs...

Combien d’utilisateurs simultanés Home Assistant peut-il gérer avant de ralentir ?
Home Assistant n’a pas de limite fixe d’utilisateurs réellement utile : testez les clients actifs avec de vrais tableaux de bord et des mises...

Comment vérifier si le DNS est à l’origine des échecs de connexion à Home Assistant
Prouvez une panne DNS de Home Assistant en testant le même nom d’hôte depuis le chemin affecté, en comparant l’accessibilité directe par IP et...

