Can Home Assistant Use an External Database Without Breaking Upgrades?
Home Assistant can use an external Recorder database without making every upgrade fragile, but the database becomes a separate stateful service that must be online, compatible, writable, backed up, and recoverable when Home Assistant performs schema work. Moving Recorder off-host does not remove database operations; it transfers more of them to you.
The safer model is to keep Home Assistant and the database on independent but coordinated lifecycles. Back up both, avoid unsupported database versions, preserve the permissions needed for schema migrations, and test the restore path before allowing unattended upgrades on both sides at the same time.
Use a Recorder Backend That Home Assistant Actually Supports
An external database should be configured through Recorder rather than treated as a generic SQL endpoint. MariaDB is one common option, and Home Assistant's maintained MariaDB app documents the database, user, privileges, and Recorder connection string required for the service.
Home Assistant's current Recorder documentation lists MariaDB, MySQL, PostgreSQL, and SQLite as supported backends, while explicitly keeping SQLite as the default and recommended database. An external database is therefore supported, but it is an operational choice rather than a required upgrade path.
Do not arbitrarily reduce the Recorder account to read/write-only permissions if migrations may need to create indexes, alter tables, or update schema objects. Use a separate read-only account for analytics tools instead.
Home Assistant Upgrades Can Include Recorder Schema Migrations
A Home Assistant version change can require Recorder to migrate the database schema before history and statistics return to normal. During that window, database performance can temporarily degrade and restarting mid-migration can make recovery harder.
Home Assistant Recorder may need to update its schema during a version change, while the database server has its own upgrade lifecycle. MariaDB's 2026 upgrade guidance recommends taking a full backup, reviewing the target release, running the database upgrade tooling, and validating the application after the server change.
Before a major Home Assistant upgrade, take a database-consistent backup and verify free space and database health. If you also plan to upgrade MariaDB, MySQL, or PostgreSQL, avoid changing both products simultaneously unless your rollback plan covers both versions.
External Availability Becomes Part of Recorder Reliability
An external database adds DNS, network, authentication, server process, storage, and database availability to the Recorder path. Home Assistant can keep running local automations while history is unhealthy, so a database outage may be less obvious than a Core outage.
A current 2026 Recorder issue demonstrates this operational risk: a PostgreSQL connection lost after normal startup caused Recorder to stop writing until Home Assistant was restarted in the reported environment.
Treat that as a field failure mode, not a universal promise about every version. Monitor new Recorder writes and connection errors so a short external database outage cannot silently become hours of missing history.
Restore Tests Must Include the Database Server Version
A SQL dump that restores into one database release is not proof that it restores into every future release. Database engines have their own schema rules and compatibility changes independent of Home Assistant.
Backup format matters too. MariaDB's backup guidance distinguishes logical SQL backups, which are comparatively portable, from physical backups that are more tightly coupled to the database files and server environment. Test the real restore target instead of assuming every archive is interchangeable across future database versions.
Keep the Home Assistant version, database engine, database version, connection string location, backup method, and restore procedure together in the recovery record.
Keep the Database Separate Only When the Extra Boundary Pays Off
An external database can make sense when several services already depend on a managed database platform, when the Home Assistant host is ephemeral, or when storage and database backup policy are deliberately centralized. It is not automatically faster or safer than local SQLite.
The ZimaSpace article on separating stateful storage from bursty compute provides the same architectural test: split roles only when the independent lifecycle, failure boundary, or resource profile justifies the extra network and recovery dependency.
If the external database creates more upgrade coupling than it removes, return to a simpler supported layout rather than keeping it solely because “external database” sounds more scalable.
FAQ
Do I need MariaDB or PostgreSQL for a large Home Assistant installation?
No. Home Assistant's default SQLite backend remains a valid and recommended choice. Move to an external database only when you have a measured operational reason and are prepared to own the additional service.
Should I upgrade Home Assistant and the external database on the same day?
Prefer changing one stateful layer at a time. Back up first, verify the database on its current version, upgrade one component, validate Recorder, and only then consider the other upgrade.
Recommended products
Support & Tips
More to Read
Signs That a Home Assistant Database Needs Maintenance or Replacement
A large Home Assistant database usually needs retention or purge work; repeated corruption or integrity errors are stronger replacement signals.
How Many Concurrent Users Can Home Assistant Handle Before It Slows Down?
Home Assistant has no fixed useful user limit: benchmark active clients with real dashboards and entity updates, then stop before repeatable latency appears.
How to Test Whether DNS Is Causing Home Assistant Connection Failures
Prove a Home Assistant DNS failure by testing the same hostname from the affected path, comparing direct IP reachability, and checking A/AAAA answers.
