Home Assistant viene con SQLite, y eso está bien durante una semana. Luego los gráficos del panel de control comienzan a retrasarse, el panel de historial tarda diez segundos en abrirse, y la base de datos del grabador crece a varios gigabytes porque los sensores Zigbee escriben cada 30 segundos. Cambiar el backend del grabador lo arregla. Ejecutamos seis bases de datos contra la misma instancia (aproximadamente 140 entidades, retención de 30 días) para ver cuál realmente aceleró nuevamente el hogar inteligente.
Este resumen es para cualquiera cuya instalación de Home Assistant ha superado la base de datos predeterminada. Docker o bare-metal, cubrimos los compromisos que trae cada backend, qué se rompe durante la migración, y cuál elegir si también quieres dashboards de Grafana a largo plazo.
Qué buscar en un backend del grabador de Home Assistant
Algunas cosas importan más que los benchmarks sin procesar:
- Latencia en los paneles de historial y libro mayor una vez que la BD supera 5 GB
- Qué tan bien el backend maneja el patrón de escritura de Home Assistant (muchas inserciones pequeñas, consultas grandes ocasionales)
- Si puedes consultarlo directamente desde Grafana o Node-RED sin sobrecargar el grabador
- Controles de retención y reducción de muestreo, porque mantener resolución completa por siempre es un desperdicio
- La historia de copia de seguridad, especialmente si ejecutas todo en un SSD que te gustaría mantener vivo
- Ruta de migración desde SQLite (¿puedes mantener el historial?)
Comparación rápida
| Backend | Mejor para | Licencia | Modelo de almacenamiento | Se ejecuta en |
|---|---|---|---|---|
| PostgreSQL | La mayoría de instalaciones | PostgreSQL | Row-store, ACID | Linux, Windows, macOS |
| MariaDB | Reemplazo directo | GPL | Row-store, ACID | Linux, Windows, macOS |
| TimescaleDB | Historial de sensores a largo plazo | Apache 2.0 / TSL | Hypertables sobre Postgres | Linux, Docker |
| InfluxDB 2.x | Dashboards, reducción de muestreo | MIT (core) | Time-series columnar | Linux, Windows, macOS |
| MySQL | Infraestructura MySQL existente | GPL | Row-store, ACID | Linux, Windows, macOS |
| VictoriaMetrics | Métricas a escala | Apache 2.0 | Time-series columnar | Linux, Windows, macOS |
Los backends
1. PostgreSQL, el mejor reemplazo general del grabador
PostgreSQL es lo que debes elegir si no estás seguro. Home Assistant lo soporta nativamente, el controlador psycopg2 es estable, y la planificación de consultas se mantiene cuando la base de datos crece más de 10 GB. El panel de historial que tardaba ocho segundos en SQLite cae por debajo de un segundo en una modesta máquina de cuatro núcleos una vez que los índices se calientan. Agrega compresión TOAST en las tablas states y events y el uso de disco se mantiene razonable.
Dónde falla: tienes que ejecutar y hacer copia de seguridad de una base de datos real. Eso significa un cron pg_dump, un archivo WAL si te importa la recuperación point-in-time, y un plan para qué sucede cuando el disco se llena. Nada exótico, pero es más trabajo que un único archivo .db.
Precio: Gratis, código abierto bajo la licencia PostgreSQL. Sin nivel de pago.
Plataformas: Linux, Windows, macOS, Docker y cualquier NAS con paquete Postgres.
Descarga: postgresql.org
Conclusión: Elige PostgreSQL primero, y solo mira a otro lado si tienes una razón específica.
2. MariaDB, el fork que la mayoría de guías aún asumen
MariaDB es el backend que los documentos de Home Assistant predeterminan en su ejemplo, y sigue siendo una opción sólida para cualquiera que ya lo ejecute. La configuración está documentada hasta el bloque YAML recorder: exacto, y hay un complemento MariaDB en Home Assistant OS que maneja la instalación por ti. El rendimiento está en el mismo rango que Postgres para la carga de trabajo del grabador.
Dónde falla: las migraciones de esquema bajo carga de escritura pesada ocasionalmente bloquean la tabla states lo suficiente como para que el grabador registre advertencias de contrapresión. Nada catastrófico, pero lo ves. Las herramientas de sabor MySQL también se sienten más viejas que el ecosistema Postgres.
Precio: Gratis, código abierto bajo GPLv2.
Plataformas: Linux, Windows, macOS, Docker, complemento HAOS nativo.
Descarga: mariadb.org
Conclusión: La opción más segura si deseas una ruta compatible y documentada con las menores sorpresas.
3. TimescaleDB, Postgres sintonizado para historial de sensores
TimescaleDB funciona como una extensión de PostgreSQL y convierte tablas de series temporales en hypertables que se particionan automáticamente por tiempo. Para un hogar inteligente que registra miles de cambios de estado al día, eso significa que puedes mantener un año de datos y aún obtener consultas subsegundo. Los agregados continuos te permiten precomputar promedios diarios para que los paneles de Grafana no escaneen filas sin procesar.
Dónde falla: tienes que enrutar el grabador de Home Assistant a través de Postgres normalmente, luego convertir las tablas en hypertables con un comando SQL manual. No es difícil, pero no es una casilla. La Licencia Timescale (TSL) en algunas características empresariales no es completamente código abierto, aunque la edición comunitaria cubre todo lo que el grabador necesita.
Precio: Edición comunitaria gratuita; Timescale Cloud de pago comienza alrededor de $30/mes para instancias alojadas.
Plataformas: Linux, Docker, Timescale Cloud. Sin paquetes Windows o macOS nativos, aunque WSL funciona.
Descarga: timescale.com
Conclusión: La mejor historia de retención a largo plazo de las seis, si te sientes cómodo ejecutando una extensión encima de Postgres.
4. InfluxDB 2.x, dashboards más que grabador
InfluxDB no es realmente un reemplazo del grabador, es el emparejamiento clásico que vive al lado de Home Assistant. La integración influxdb transmite cambios de estado a InfluxDB en paralelo con cualquier backend SQL que use el grabador, y Grafana extrae de Influx para los dashboards bonitos. Las consultas Flux te permiten reducir la muestra sin cronjobs.
Dónde falla: el lenguaje de consulta Influx cambió entre 1.x, 2.x y 3.x, así que la mitad de los tutoriales que encuentras están desactualizados. Y porque no reemplaza el grabador, ejecutas dos bases de datos en lugar de una.
Precio: InfluxDB 2.x OSS de código abierto gratuito; InfluxDB Cloud tiene un nivel gratuito y precios de pago por uso por encima de eso.
Plataformas: Linux, Windows, macOS, Docker, complemento HAOS.
Descarga: influxdata.com
Conclusión: Úsalo junto a un grabador SQL cuando quieras dashboards de Grafana serios, no como reemplazo del grabador.
5. MySQL, solo si ya lo ejecutas
MySQL funciona con Home Assistant, y si ya tienes un servidor MySQL funcionando para otro servicio, agregar una base de datos del grabador a él es sencillo. El controlador mysqlclient está muy usado, y el grabador no lo presiona mucho.
Dónde falla: MariaDB es un fork de reemplazo directo que la mayoría de las guías de Home Assistant apuntan directamente, así que terminas traduciendo las instrucciones. Las licencias de Oracle alrededor de MySQL Enterprise agregan una complicación si alguna vez quisiste soporte pagado.
Precio: MySQL Community Edition gratuito; los niveles Enterprise pagados comienzan alrededor de $2,000/año.
Plataformas: Linux, Windows, macOS, Docker.
Descarga: mysql.com
Conclusión: Elige solo si ya tienes una instancia MySQL que deseas reutilizar.
6. VictoriaMetrics, cuando el grabador es el cuello de botella
VictoriaMetrics brilla cuando tienes cientos de entidades y el grabador mismo se convierte en la parte lenta. Ingiere a través de un endpoint compatible con Prometheus, así que la integración prometheus de Home Assistant lo alimenta directamente. El almacenamiento es aproximadamente 10 veces más compacto que InfluxDB para los mismos datos.
Dónde falla: es solo métricas. No obtienes historial de estado de la misma manera que el grabador te lo da, así que el panel de historial incorporado aún necesita un backend SQL. Esto es un suplemento, no un reemplazo.
Precio: Código abierto gratuito; VictoriaMetrics Enterprise para despliegues grandes tiene precios personalizados.
Plataformas: Linux, Windows, macOS, Docker.
Descarga: victoriametrics.com
Conclusión: El almacén de métricas al que recurrir cuando tus exportaciones de Prometheus se vuelven voluminosas e Influx comienza a sentirse pesado.
Cómo elegir el correcto
Si solo quieres que tu dashboard se sienta rápido: PostgreSQL, y deja de leer aquí.
Si sigues las guías de cerca y quieres la ruta documentada: MariaDB.
Si planeas mantener años de historial de sensores y consultarlo más tarde: TimescaleDB encima de PostgreSQL.
Si tu objetivo es realmente dashboards bonitos de Grafana con reducción de muestreo: mantén el grabador en Postgres o MariaDB, y agrega InfluxDB para la capa de métricas.
Si tu instalación de Home Assistant es genuinamente enorme (500+ entidades, millones+ cambios de estado al día): empareja PostgreSQL como grabador con VictoriaMetrics para métricas al estilo Prometheus.
Salta MySQL a menos que ya lo ejecutes para otra cosa.
Preguntas Frecuentes
¿PostgreSQL es más rápido que SQLite para Home Assistant?
Sí, una vez que tu base de datos supera unos pocos gigabytes. En instalaciones pequeñas SQLite es comparable, pero los paneles de historial y libro mayor son notablemente más rápidos en PostgreSQL a medida que crecen los datos, porque la planificación de consultas y las lecturas concurrentes se escalan mejor.
¿Puedo migrar mi historial de SQLite a PostgreSQL sin perder datos?
Sí, usando pgloader o un dump/restore manual, pero es complicado. La mayoría de los usuarios comienzan de nuevo con el nuevo backend y aceptan la pérdida del historial antiguo en lugar de luchar con la conversión de esquema.
¿Home Assistant soporta InfluxDB como reemplazo del grabador?
No. InfluxDB funciona junto con el grabador a través de la integración influxdb, transmitiendo cambios de estado en paralelo. El grabador en sí aún necesita SQLite, PostgreSQL, MariaDB o MySQL.
¿Cuál es el mejor backend para historial de Home Assistant a largo plazo?
TimescaleDB. Los agregados continuos y la partición basada en tiempo te permiten mantener un año o más de datos y aún obtener consultas rápidas. VictoriaMetrics está cerca si solo te importan las métricas numéricas.
¿Cambiar el backend del grabador romperá mis automatizaciones?
No. Las automatizaciones leen de la máquina de estado de Home Assistant, no de la base de datos del grabador. Cambiar el backend afecta el historial, las estadísticas y la retención a largo plazo, no el estado activo.