Home Assistantはアップグレードで問題を起こさずに外部データベースを利用できますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Can Home Assistant Use an External Database Without Breaking Upgrades?

Home Assistantは、すべてのアップグレードを不安定にすることなく、外部のRecorderデータベースを利用できます。ただし、データベースは独立したステートフルサービスとなるため、Home Assistantがスキーマ処理を行う際には、オンラインであり、互換性があり、書き込み可能で、バックアップ済みかつ復旧可能でなければなりません。Recorderをホスト外に移しても、データベース運用がなくなるわけではなく、その多くをあなたが担うことになります。

より安全なモデルは、Home Assistantとデータベースを、独立していながら連携したライフサイクルで運用することです。両方をバックアップし、サポート対象外のデータベースバージョンを避け、スキーマ移行に必要な権限を維持し、双方で同時に無人アップグレードを許可する前に復元手順をテストしてください。

Home Assistantが実際にサポートしているRecorderバックエンドを使用する

外部データベースは、汎用的なSQLエンドポイントとして扱うのではなく、Recorderを通じて設定してください。MariaDBは一般的な選択肢の一つで、Home Assistantの管理対象MariaDBアプリには、サービスに必要なデータベース、ユーザー、権限、Recorder接続文字列が記載されています。

Home Assistantの現在のRecorderドキュメントでは、サポート対象のバックエンドとしてMariaDB、MySQL、PostgreSQL、SQLiteを挙げています。一方で、SQLiteはデフォルトかつ推奨のデータベースとして明示されています。したがって外部データベースはサポートされていますが、必須のアップグレード経路ではなく、運用上の選択肢です。

移行でインデックスの作成、テーブルの変更、スキーマオブジェクトの更新が必要になる可能性がある場合、Recorderアカウントの権限を任意に読み書き専用へ制限しないでください。分析ツールには、別の読み取り専用アカウントを使用してください。

Home AssistantのアップグレードにはRecorderのスキーマ移行が含まれる場合がある

Home Assistantのバージョン変更では、履歴や統計情報が通常どおり利用できるようになる前に、Recorderによるデータベーススキーマの移行が必要になる場合があります。その間はデータベースのパフォーマンスが一時的に低下する可能性があり、移行途中で再起動すると復旧が難しくなることがあります。

Home Assistant Recorderはバージョン変更時にスキーマを更新する必要が生じる場合があり、データベースサーバーにも独自のアップグレードライフサイクルがあります。MariaDBの2026年のアップグレードガイダンスでは、完全バックアップを取得し、対象リリースを確認し、データベースのアップグレードツールを実行し、サーバー変更後にアプリケーションを検証することを推奨しています。

Home Assistantのメジャーアップグレード前には、データベースと整合性のあるバックアップを取得し、空き容量とデータベースの健全性を確認してください。MariaDB、MySQL、PostgreSQLもアップグレードする予定がある場合は、両方のバージョンを対象にしたロールバック計画がない限り、両製品を同時に変更することは避けてください。

外部の可用性がRecorderの信頼性の一部になる

外部データベースを使用すると、Recorderの経路にDNS、ネットワーク、認証、サーバープロセス、ストレージ、データベースの可用性が加わります。履歴に問題があってもHome Assistantはローカルオートメーションを実行し続けられるため、データベース障害はCore障害ほど明確に気づけない場合があります。

2026年のRecorderに関する現在の課題は、この運用上のリスクを示しています。報告された環境では、通常の起動後にPostgreSQL接続が失われた結果、Home Assistantを再起動するまでRecorderが書き込みを停止しました。

これは現場で起こり得る障害モードとして扱い、すべてのバージョンに共通する保証だとは考えないでください。新しいRecorder書き込みと接続エラーを監視し、短時間の外部データベース停止が、気づかないまま数時間分の履歴欠落につながらないようにしてください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

復元テストにはデータベースサーバーのバージョンも含める

あるデータベースリリースに復元できるSQLダンプだからといって、将来のすべてのリリースに復元できるとは限りません。データベースエンジンには、Home Assistantとは独立した固有のスキーマ規則と互換性の変更があります。

バックアップ形式も重要です。MariaDBのバックアップガイダンスでは、比較的移植性の高い論理SQLバックアップと、データベースファイルおよびサーバー環境との結び付きが強い物理バックアップを区別しています。すべてのアーカイブが将来のデータベースバージョン間で互換性があると想定せず、実際に復元する対象へテストしてください。

復旧記録には、Home Assistantのバージョン、データベースエンジン、データベースのバージョン、接続文字列の保存場所、バックアップ方法、復元手順をまとめて記録してください。

追加の境界にメリットがある場合にのみデータベースを分離する

複数のサービスがすでに管理されたデータベース基盤に依存している場合、Home Assistantホストが一時的な環境である場合、またはストレージとデータベースのバックアップポリシーを意図的に集中管理している場合は、外部データベースが適しています。ローカルSQLiteより自動的に高速または安全になるわけではありません。

ステートフルストレージとバースト性のあるコンピュートを分離することに関するZimaSpaceの記事でも、同じアーキテクチャ上の判断基準を示しています。独立したライフサイクル、障害境界、またはリソース特性によって、追加されるネットワーク依存と復旧依存が正当化される場合にのみ、役割を分割してください。

外部データベースによって、解消できる以上のアップグレード依存関係が生じるなら、「外部データベース」のほうがスケーラブルに聞こえるという理由だけで使い続けず、よりシンプルでサポート対象の構成に戻してください。