Home Assistant vem com SQLite, e isso funciona bem por uma semana. Depois os gráficos do painel de controle começam a travar, o painel de histórico leva dez segundos para abrir, e o banco de dados do recorder cresce para vários gigabytes porque seus sensores Zigbee escrevem a cada 30 segundos. Trocar o backend do recorder resolve. Testamos seis bancos de dados contra a mesma instância (aproximadamente 140 entidades, retenção de 30 dias) para ver qual realmente acelerou novamente a casa inteligente.
Este resumo é para quem a instalação Home Assistant cresceu além do banco de dados padrão. Docker ou bare-metal, abordamos os trade-offs que cada backend traz, o que quebra durante a migração, e qual escolher se você também quer dashboards Grafana de longo prazo.
O que procurar em um backend Home Assistant recorder
Algumas coisas importam mais que benchmarks puros:
- Latência nos painéis de histórico e logbook quando a DB passa de 5 GB
- Quão bem o backend lida com o padrão de escrita do Home Assistant (muitas inserções pequenas, grandes consultas ocasionais)
- Se você pode consultá-lo direto do Grafana ou Node-RED sem sobrecarregar o recorder
- Controles de retenção e downsampling, porque guardar resolução completa para sempre é desperdício
- História de backup, especialmente se você executa tudo em um SSD que gostaria de manter vivo
- Caminho de migração do SQLite (você consegue manter o histórico?)
Comparação rápida
| Backend | Melhor para | Licença | Modelo de armazenamento | Executa em |
|---|---|---|---|---|
| PostgreSQL | Maioria das instalações | PostgreSQL | Row-store, ACID | Linux, Windows, macOS |
| MariaDB | Substituição direta | GPL | Row-store, ACID | Linux, Windows, macOS |
| TimescaleDB | Histórico de sensores de longo prazo | Apache 2.0 / TSL | Hypertables sobre Postgres | Linux, Docker |
| InfluxDB 2.x | Dashboards, downsampling | MIT (core) | Time-series columnar | Linux, Windows, macOS |
| MySQL | Infraestrutura MySQL existente | GPL | Row-store, ACID | Linux, Windows, macOS |
| VictoriaMetrics | Métricas em escala | Apache 2.0 | Time-series columnar | Linux, Windows, macOS |
Os backends
1. PostgreSQL, melhor substituição geral do recorder
PostgreSQL é o que escolher se não tiver certeza. Home Assistant o suporta nativamente, o driver psycopg2 é estável, e o planejamento de consultas aguenta bem quando o banco cresce além de 10 GB. O painel de histórico que levava oito segundos no SQLite cai para menos de um segundo numa máquina modesta de quatro núcleos quando os índices aquecem. Adicione compressão TOAST nas tabelas states e events e o uso de disco fica razoável.
Onde falha: você precisa executar e fazer backup de um banco de dados real. Isso significa um cron pg_dump, um arquivo WAL se você se importa com recuperação point-in-time, e um plano para quando o disco encher. Nada exótico, mas é mais trabalho que um único arquivo .db.
Preço: Grátis, open-source sob a licença PostgreSQL. Sem nível pago.
Plataformas: Linux, Windows, macOS, Docker, e qualquer NAS com pacote Postgres.
Download: postgresql.org
Conclusão: Escolha PostgreSQL primeiro, e só procure alternativas se tiver uma razão específica.
2. MariaDB, o fork que a maioria dos guias ainda assume
MariaDB é o backend que a documentação do Home Assistant usa por padrão no exemplo, e continua sendo uma escolha sólida para quem já o executa. A configuração é documentada até o bloco YAML recorder: exato, e há um complemento MariaDB no Home Assistant OS que trata da instalação para você. O desempenho está na mesma faixa que Postgres para a carga de trabalho do recorder.
Onde falha: migrações de schema sob carga de escrita pesada ocasionalmente travam a tabela states tempo suficiente para o recorder registrar advertências de contrapressão. Nada catastrófico, mas você vê. Ferramentas MySQL também parecem mais antigas que o ecossistema Postgres.
Preço: Grátis, open-source sob GPLv2.
Plataformas: Linux, Windows, macOS, Docker, complemento HAOS nativo.
Download: mariadb.org
Conclusão: A escolha mais segura se você quer um caminho suportado e documentado com o mínimo de surpresas.
3. TimescaleDB, Postgres sintonizado para histórico de sensores
TimescaleDB funciona como uma extensão PostgreSQL e transforma tabelas de séries temporais em hypertables que são automaticamente particionadas por tempo. Para uma casa inteligente que registra milhares de mudanças de estado por dia, isso significa que você pode manter um ano de dados e ainda obter consultas sub-segundo. Agregados contínuos permitem pré-calcular médias diárias para que painéis Grafana não scanneiem linhas brutas.
Onde falha: você precisa rotear o recorder do Home Assistant através do Postgres normalmente, depois converter as tabelas em hypertables com um comando SQL manual. Não é difícil, mas não é apenas marcar uma caixa. A Licença Timescale (TSL) em algumas funcionalidades empresariais não é totalmente open-source, mas a edição comunitária cobre tudo que o recorder precisa.
Preço: Edição comunitária grátis; Timescale Cloud pago começa em torno de $30/mês para instâncias hospedadas.
Plataformas: Linux, Docker, Timescale Cloud. Sem pacotes Windows ou macOS nativos, embora WSL funcione.
Download: timescale.com
Conclusão: Melhor história de retenção de longo prazo dos seis, se você se sente confortável executando uma extensão sobre Postgres.
4. InfluxDB 2.x, dashboards mais que recorder
InfluxDB não é realmente uma substituição do recorder, é o emparelhamento clássico que vive ao lado do Home Assistant. A integração influxdb transmite mudanças de estado para InfluxDB em paralelo com qualquer backend SQL que o recorder usa, e Grafana puxa de Influx para os dashboards bonitos. Consultas Flux permitem downsampling sem cronjobs.
Onde falha: a linguagem de consulta Influx mudou entre 1.x, 2.x e 3.x, então metade dos tutoriais que você encontra estão desatualizados. E porque não substitui o recorder, você executa dois bancos de dados em vez de um.
Preço: InfluxDB 2.x OSS open-source grátis; InfluxDB Cloud tem nível grátis e preço pré-pago acima.
Plataformas: Linux, Windows, macOS, Docker, complemento HAOS.
Download: influxdata.com
Conclusão: Use junto com um recorder SQL quando quiser dashboards Grafana sérios, não como substituição do recorder.
5. MySQL, apenas se você já o executa
MySQL funciona com Home Assistant, e se você já tem um servidor MySQL rodando para outro serviço, adicionar um banco de dados do recorder é simples. O driver mysqlclient é bem desgastado, e o recorder não o pressiona muito.
Onde falha: MariaDB é um fork de substituição direta que a maioria dos guias Home Assistant aponta diretamente, então você termina traduzindo instruções. O licenciamento Oracle em torno do MySQL Enterprise adiciona uma complicação se você alguma vez quisesse suporte pago.
Preço: MySQL Community Edition grátis; níveis Enterprise pagos começam em torno de $2.000/ano.
Plataformas: Linux, Windows, macOS, Docker.
Download: mysql.com
Conclusão: Escolha apenas se você já tem uma instância MySQL que quer reutilizar.
6. VictoriaMetrics, quando o recorder é o gargalo
VictoriaMetrics brilha quando você tem centenas de entidades e o recorder em si se torna a parte lenta. Ingere via um endpoint compatível com Prometheus, então a integração prometheus do Home Assistant o alimenta diretamente. Armazenamento é cerca de 10x mais compacto que InfluxDB para os mesmos dados.
Onde falha: é apenas métricas. Você não obtém histórico de estado da mesma forma que o recorder dá, então o painel de histórico built-in ainda precisa de um backend SQL. Isso é um suplemento, não uma substituição.
Preço: Open-source grátis; VictoriaMetrics Enterprise para grandes deployments tem preço customizado.
Plataformas: Linux, Windows, macOS, Docker.
Download: victoriametrics.com
Conclusão: O armazenamento de métricas a procurar quando suas exportações Prometheus ficam volumosas e Influx começa a parecer pesado.
Como escolher o certo
Se você só quer seu dashboard se sentir rápido: PostgreSQL, e pare de ler aqui.
Se você segue guias de perto e quer o caminho documentado: MariaDB.
Se você planeja manter anos de histórico de sensores e consultá-los depois: TimescaleDB sobre PostgreSQL.
Se seu objetivo é realmente dashboards Grafana bonitos com downsampling: mantenha o recorder em Postgres ou MariaDB, e adicione InfluxDB para a camada de métricas.
Se sua instalação Home Assistant é genuinamente enorme (500+ entidades, milhões+ de mudanças de estado por dia): emparelhe PostgreSQL como recorder com VictoriaMetrics para métricas estilo Prometheus.
Pule MySQL a menos que você já o execute para outra coisa.
Perguntas Frequentes
PostgreSQL é mais rápido que SQLite para Home Assistant?
Sim, uma vez que seu banco de dados passa de alguns gigabytes. Em instalações pequenas SQLite é comparável, mas os painéis de histórico e logbook são notavelmente mais rápidos em PostgreSQL conforme os dados crescem, porque o planejamento de consultas e leituras concorrentes escalam melhor.
Posso migrar meu histórico SQLite para PostgreSQL sem perder dados?
Sim, usando pgloader ou um dump/restore manual, mas é complicado. A maioria dos usuários começa do zero com o novo backend e aceita a perda de histórico antigo em vez de lutar com a conversão de schema.
Home Assistant suporta InfluxDB como substituição do recorder?
Não. InfluxDB funciona junto com o recorder através da integração influxdb, transmitindo mudanças de estado em paralelo. O recorder em si ainda precisa SQLite, PostgreSQL, MariaDB ou MySQL.
Qual é o melhor backend para histórico Home Assistant de longo prazo?
TimescaleDB. Agregados contínuos e particionamento baseado em tempo permitem manter um ano ou mais de dados e ainda obter consultas rápidas. VictoriaMetrics está próximo se você só se importa com métricas numéricas.
Mudar o backend do recorder quebrará minhas automações?
Não. Automações leem da máquina de estado Home Assistant, não do banco de dados do recorder. Trocar o backend afeta histórico, estatísticas e retenção de longo prazo, não o estado vivo.