When Home Automation Becomes Infrastructure
There's a moment in most home automation projects when the framing shifts. It doesn't announce itself. One day you're automating a light, the next you're thinking about database backend selection, container isolation boundaries, and whether your remote access method is actually secure or just apparently secure. The project didn't change — your relationship to it did.
The stack that signals this shift looks roughly like: Home Assistant running in Docker, Z-Wave as the primary device protocol, MariaDB replacing the default SQLite recorder. These three choices, taken together, say something specific about how someone thinks about infrastructure. They're not arbitrary. They're not the path of least resistance. They're the choices of someone who has decided to run their home like a system.
The Platform Decision Space
Home Assistant ships in several installation modes, and the choice between them is not primarily about features. It's about who manages what.
Home Assistant OS (HAOS) is the managed path. It controls the entire host, handles updates, manages add-ons through a curated supervisor. Z-Wave integration is an add-on. Database management happens quietly in the background. You trade host-level control for operational simplicity. For a large portion of HA's user base — enthusiasts who want automation without systems administration — HAOS is the right answer. The platform absorbs the complexity so you don't have to.
Docker Core is the explicit path. You own the host, the container orchestration, the service topology. Z-Wave requires a separate container with direct USB device access. MariaDB is a separate container with its own volume management. Updates are your responsibility to coordinate. The platform exposes complexity rather than absorbing it, on the premise that you can make better decisions about it than a managed layer can.
This is a real tradeoff, not a hierarchy. HAOS is not the beginner version of what Docker is doing. They represent different answers to the same question: how much operational control do you want, and how much operational burden are you willing to carry?
The answer shifts as your requirements shift. A single-node HA instance automating lights and a thermostat is well-served by HAOS. An instance integrated into a Proxmox cluster with shared storage, handling presence detection for a family of five, backing up to network storage, feeding data into a home monitoring stack — that instance has requirements that start to look like production service requirements. Docker becomes reasonable not because it's inherently better, but because the requirements justify the overhead.
Z-Wave as an Infrastructure Bet
Z-Wave persists in home automation despite having real friction costs. USB passthrough in Docker is a multi-year community pain point with no single canonical resolution. The Z-Wave stick must be passed through to a dedicated container — not HA itself — requiring explicit device path management, group permissions, and careful coordination so nothing else claims the serial port. It's not insurmountable. It is genuinely annoying in a way that Zigbee USB passthrough often isn't, and in a way that cloud-based protocols sidestep entirely.
So why does Z-Wave keep getting chosen?
The answer sits in Z-Wave's design constraints. The protocol operates in the 900 MHz band, below WiFi and Zigbee's 2.4 GHz congestion. Devices must be certified before they can use the Z-Wave label, which means the interoperability surface is tighter than Zigbee's more open ecosystem. The mesh is local — no cloud, no internet dependency, no vendor account required for the device to function. And the devices themselves are built to the protocol's specification rather than around it.
For someone building home automation that they intend to operate for years, these properties matter. The friction of initial USB setup is a one-time cost. The operational characteristics of the protocol — reliability, range, local operation — are a long-term return. Choosing Z-Wave is, in part, choosing to absorb upfront complexity in exchange for downstream stability. It's the same calculation that leads to choosing MariaDB.
What the Database Choice Signals
Home Assistant defaults to SQLite for its recorder database. SQLite works. For a small installation with modest history retention, it works fine. The friction appears gradually: as device count grows, as history retention extends, as the database file accumulates years of state changes. HA's UI latency climbs. Queries slow. The default that served well at day one starts showing strain.
The standard resolution is to migrate to MariaDB or PostgreSQL. Both handle the recorder's write patterns and query load significantly better than SQLite at scale. The migration itself is not clean — there is no in-place path from SQLite to MariaDB. History must be purged and rebuilt from zero. This is a real cost: losing historical data to improve future performance. Most operators who make this switch have already hit the wall hard enough to accept it.
What's interesting is not the migration itself but what it reveals about the decision already made. Choosing MariaDB from the start — before SQLite degrades, before the wall is hit — is a form of infrastructure planning. It's applying production database thinking to a home system: external database with its own container, its own volume, its own backup concern. This is how you'd set up a production service. It's not how most people set up a home automation system.
The choice signals something about how the operator models their installation. Not as a consumer product that manages itself, but as a system with components that require deliberate design.
The Complexity Ceiling and Where It Sits
The Docker + MariaDB + Z-Wave stack carries a real operational burden. USB device management. Database container maintenance. Container version coordination. Backup strategy across multiple services. When something breaks — and something will break — the failure domain is wider. There's no Supervisor to catch problems. Diagnosis happens at the container level, the host level, the application level, sometimes all three simultaneously.
This is worth naming directly because it tends to be underestimated. The complexity is not a bug in the approach — it's a feature that comes with a cost. The feature is control. The cost is the hours required to maintain that control. People who come from HAOS or from a Raspberry Pi running HASSIO frequently hit the Z-Wave USB problem first and spend more time on it than expected. Not because the problem is hard, but because the problem surface is wider than they anticipated when they decided to move to Docker.
The honest ceiling for this approach is operator capacity. How much time can you spend on the platform versus on what the platform does? For someone who works in infrastructure professionally, the Docker stack doesn't feel like overhead — it feels like Tuesday. For someone who wants to automate their house and go back to their actual job, the managed path is probably the right call even if the infrastructure instincts pull toward control.
Neither answer is wrong. The architecture question is which model matches your operational reality, not which model is objectively better.
The Question That Stays Open
Home automation platforms are converging. Matter and Thread are attempting to do at the protocol layer what HAOS attempted at the platform layer: abstract the complexity, standardise the interoperability surface, remove the need for per-protocol containers and integration maintenance. If that convergence delivers on its promise, some of what makes Z-Wave a deliberate choice — local operation, no cloud dependency, certification-backed interoperability — becomes table stakes rather than a differentiator.
What doesn't converge is the managed-versus-explicit question. That sits below the protocol layer, at the level of how you want to operate the system. HAOS with Matter support is still the managed path. Docker Core with Matter support is still the explicit path. The protocol evolution doesn't resolve the operational philosophy decision.
What's less clear is where the line between home automation and home infrastructure is going. The stack described here treats home automation as infrastructure. That framing has costs — complexity, maintenance burden, operational overhead. It also has a return: durability, control, and a system that behaves like a system rather than a product. Whether that return justifies those costs depends on who's operating it and what they expect from the operation.
That's not a question with a universal answer. It's a question worth asking before you choose your stack, not after.
