When Should Home Assistant Use a Separate Database or Storage Host?
Home Assistant should use a separate database or storage host only when that separation solves a measured capacity, retention, backup, or failure-domain problem. Moving state off the controller is not automatically an upgrade.
For many homes, a local SQLite Recorder database on reliable SSD storage is the simplest path because it removes network, authentication, DNS, and database-server startup dependencies. Before creating another host, first identify whether the real problem is excessive Recorder writes, long retention, slow history queries, limited local capacity, or the need to recover one service independently.
Tune Recorder Before You Add a Database Server
Recorder growth is driven by the entities and events being stored, how frequently they change, and how long history is retained. If noisy sensors or unnecessary domains dominate writes, moving the same workload to a larger database server relocates the problem instead of removing it.
A current Recorder tuning workflow shows how retention, include/exclude rules, and commit behavior affect the write workload before a database migration is considered. Measure database size, history query time, storage latency, and write activity after tuning.
Keep the database local when the tuned workload stays responsive, backups finish inside the maintenance window, and available SSD capacity remains comfortable. Separation should follow a failing requirement, not a generic belief that client-server databases are always faster.
Use an External Database When Its Operational Benefits Are Real
A separate MariaDB, MySQL, or PostgreSQL host can make sense when Home Assistant shares an already well-operated database platform, when long retention creates sustained query pressure, when the controller host must remain lightweight or replaceable, or when database backup and monitoring need an independent lifecycle.
A SQLite-to-MariaDB migration example illustrates the new pieces introduced by that choice: database service, credentials, network address, schema initialization, migration procedure, validation, and rollback. A larger real-world Home Assistant database migration case shows why long history and large data sets can justify the additional administration.
The ZimaSpace article on external database upgrade reliability provides the corresponding maintenance boundary: the database must be backed up, upgraded, and restored as its own service rather than treated as invisible infrastructure.
Do Not Put a Live SQLite Database on a Network Share by Default
A remote database server and a database file stored on SMB or NFS are different architectures. A client-server database performs locking and transactions inside the database service and sends requests over the network. SQLite performs database-file locking through the filesystem, so network filesystem semantics, mount availability, latency, and lock behavior become part of every transaction.
The broader SQLite locking analysis explains why network filesystems can produce lock behavior that differs from a local disk. A Home Assistant network-share failure case shows the practical risk when the live Recorder database depends on a remote mount.
Use a NAS freely for backup copies, exports, media, and other data designed for network storage. If the active Recorder state must live on another machine, prefer a supported client-server database rather than moving the SQLite file to a share.
Separate Bulk Storage From Active Home Assistant State
Not every growing Home Assistant directory belongs in the same storage tier. Configuration, integration state, the active Recorder database, media, camera clips, exports, and backups have different latency and recovery needs. Keep small, frequently updated state on low-latency local storage unless a separate service is deliberately managing it.
Move bulk media or backup generations to NAS capacity behind stable mount points. Document whether Home Assistant is allowed to boot without that mount. A missing photo archive should not prevent lighting automations from starting, while a missing active database should create an explicit degraded state rather than a silent fallback nobody notices.
| Data role | Default placement | Reason to separate |
|---|---|---|
| Configuration and active state | Local SSD | Low latency and simple recovery |
| Recorder SQLite | Local SSD | Avoid network-filesystem locking dependencies |
| External SQL database | Local or separate DB host | Independent scale, retention, backup, administration |
| Media and exports | Local or NAS | Capacity often matters more than latency |
| Backups | At least one off-host copy | Survive loss of the active host |
Prove Startup, Failure, and Restore Before Making the Split Permanent
Stage the new database or storage role without deleting the old recovery path. Reboot the database host before Home Assistant, reboot Home Assistant before the database is ready, interrupt the network, rotate credentials, fill the target filesystem near its reserve threshold, and restore the database onto a clean instance.
Measure p95 history-query time, automation latency during heavy Recorder activity, restart time, backup duration, and the recovery time after a database-host outage. If the split improves one metric but turns a thirty-second controller restart into a multi-service recovery runbook, include that operational cost in the decision.
Keep local storage when it already passes the target. Use a separate database host when client-server database operations and independent recovery are genuine advantages. Use a separate storage host for bulk data and backups, but do not make critical local control depend on a remote filesystem without a tested reason.
Recommended products
NAS & Server Setup
More to Read
A Local RAG Setup for Research Papers, Notes, and Private Documents
Keep original documents authoritative, make indexing repeatable, require citations, and separate replaceable models from private source data.
Why Are Developers Using a Gateway Node for Private DNS, VPN, and Test Apps?
A gateway node gives private apps one controlled name and access path, while compute nodes stay unexposed and replaceable.
How to Build a Reproducible App Stack With Compose Files, Secrets, and Persistent Data Separated
Keep Compose definitions portable, secrets protected, and app data independently backed up so the stack can be rebuilt on a clean host.
