My own smart home system started acting sluggish — dashboards taking a beat too long to update, automations firing a little late. Nothing broken, just slower than it used to be. The cause wasn’t a bad device or a bug. It was success: the system had grown past what its default database could comfortably handle.
By the time I looked into it, my Home Assistant instance had grown to nearly 1,900 entities — sensors, switches, locks, presence trackers, the works. Every state change any of them ever makes gets logged. That’s a lot of writing to keep up with.
The default database is built for getting started, not for scale
Home Assistant, like a lot of self-hosted platforms, ships with a simple built-in database by default — SQLite. It’s a great choice for a new setup: no separate server to configure, no extra maintenance, everything just works out of the box. What it isn’t built for is one thing at a time. SQLite allows only a single writer at a time across the entire database. Every sensor update, every automation log entry, every state change has to wait its turn in line.
For a small setup — a few dozen devices — that queue clears so fast you’d never notice it exists. Past a certain point, with hundreds of devices all reporting in regularly, that single-writer line starts to actually back up, and everything downstream of it — dashboards, automations, the whole system’s responsiveness — starts to feel the drag.
Recognizing it’s a database problem, not a device problem
The tempting first response to a sluggish smart home is to start suspecting individual devices — a chatty sensor, a misbehaving integration, a WiFi problem. Worth checking, but in my case none of that was it. The system was slow everywhere, evenly, in a way that pointed at something structural rather than any one device. That’s the signature of a write-contention problem: not one thing going wrong, just too many things all needing the same resource at once.
The actual fix: outgrow the training-wheels database
The fix wasn’t tuning or trimming — it was moving the whole recorder database from SQLite to a proper database server (PostgreSQL) built to handle many things writing at once instead of one at a time. That’s a bigger step than a quick settings change, and it’s worth being honest about the tradeoff: unless you specifically migrate the old data along with it, you start your history fresh. I made that call deliberately — a clean start was worth more to me than preserving months of old sensor logs I was unlikely to ever look at again, but that’s a real decision to make consciously, not a side effect to be surprised by.
Once moved, the difference was immediate — the lag disappeared, because the system was no longer waiting in a single-file line for every routine write.
Worth checking if your own setup feels sluggish
- Roughly how many devices and sensors are actually reporting into your system? A lot of platforms handle the first few dozen fine on default settings, but not the next few hundred.
- Is the slowness general — everything a little laggy — or specific to one device? General slowness points at infrastructure, not a single misbehaving gadget.
- Do you know what database your smart home platform is actually running on, and whether it’s the default or something purpose-built for the size of what you’ve built?
A smart home that’s grown past its starting point deserves infrastructure that’s grown with it. The good news: the fix isn’t more hardware or fewer devices — just the right database for the job.