Um ESP32 enviando temperatura a cada minuto não é um benchmark de banco de dados. A decisão real depende de onde as leituras chegam, quem as consulta, por quanto tempo são úteis e com o que precisam se relacionar: cadastro dos dispositivos, chamados de manutenção, clientes ou eventos de controle. PostgreSQL, InfluxDB e SQLite guardam observações com horário, mas atendem a formatos operacionais diferentes.
Documente taxa de ingestão, picos, eventos atrasados, janelas de consulta, faixas de retenção, limites entre clientes, tempo sem conexão e objetivo de recuperação. Estime bytes por linha incluindo índices e metadados, não só o payload do sensor. Mil dispositivos amostrando uma vez por minuto geram cerca de 1,44 milhão de pontos por dia antes de retries, métricas derivadas e índices. É uma estimativa para planejamento, não prova de que você precisa de um banco especializado.
| Opção | Onde funciona bem | O que exige atenção | Primeira escolha quando... |
|---|---|---|---|
| PostgreSQL, inclusive gerenciado pelo Supabase | Telemetria relacionada a clientes e dispositivos; SQL, transações, políticas de acesso e um banco para a aplicação. | Índices e consultas, crescimento do armazenamento, vacuum, retenção e manutenção de partições quando o volume justificar. | Contexto relacional e flexibilidade de SQL pesam mais que um fluxo especializado de séries temporais. |
| InfluxDB | Ingestão temporal, consultas por janelas e retenção organizada em buckets. | Disciplina de esquema e cardinalidade, modelo de consulta e migração conforme a versão. | Telemetria é a carga dominante e o modelo combina com a equipe e a implantação. |
| SQLite no gateway | Buffer local durável, equipamento offline, coletor de um host ou instalação pequena. | Um escritor por vez em WAL, acesso no mesmo host, checkpoints, backup e sincronização posterior. | O dado precisa sobreviver localmente à queda da internet e um processo pode controlar as gravações. |
Supabase é uma plataforma gerenciada de Postgres, não um mecanismo de séries temporais separado. O suporte a extensões depende da versão: atualmente, o Supabase informa que TimescaleDB está depreciado em projetos Postgres 17 e orienta quem usa hypertables a avaliar particionamento nativo gerenciado pelo pg_partman. Confirme a versão principal do projeto e a migração suportada antes de seguir tutoriais antigos.
Uma tabela comum costuma bastar para começar. Um esquema básico pode usar device_id, observed_at (timestamptz), received_at, sequence_no, metric, value, unit e schema_version, com chave única baseada em dispositivo, horário, sequência e métrica. Indexe dispositivo e horário descendente apenas se isso corresponder aos filtros reais do painel.
Mantenha separados horário do evento e recebimento no servidor, usando timestamps com fuso. Defina idempotência por sequência do dispositivo ou ID do evento. Em produção, valide pares métrica/unidade, limite payloads e aplique autorização por cliente na API ou no banco. Cada índice extra custa espaço e escrita. Particione por tempo só quando medições demonstrarem que poda, remoção de retenção em lote ou operação compensam a manutenção adicional. O PostgreSQL recomenda particionamento sobretudo para tabelas grandes e padrões de acesso compatíveis, não como botão automático de velocidade.
A vantagem relacional é prática: um gráfico associa a leitura ao local, cliente, calibração ou janela de manutenção sem repetir esses dados em cada ponto. Agregue na resolução necessária para o painel e não envie milhões de pontos brutos ao navegador esperando que a biblioteca resolva a arquitetura.
O InfluxDB distingue timestamp, measurement, tags e fields. Na documentação da versão 2.x, tags são indexadas e fields não. Tags ajudam a filtrar dimensões estáveis; valores muito únicos ou que mudam bastante não devem virar tags sem análise, pois a cardinalidade importa. ID do dispositivo pode funcionar como tag numa frota limitada, mas teste o crescimento previsto e as recomendações da versão implantada.
No InfluxDB 2.x, buckets agrupam dados e regras de retenção. InfluxDB 3 é a geração atual, com arquitetura e consultas diferentes. Não copie uma receita de bucket/Flux da versão 2 para a versão 3 sem verificar compatibilidade, edição, hospedagem, autenticação, backup/exportação, bibliotecas e atualização.
Num gateway que perde conexão, SQLite grava lotes localmente e os encaminha quando a rede volta. Write-Ahead Logging permite leitores e um escritor em paralelo, mas continua havendo apenas um escritor por vez. WAL depende de memória compartilhada no mesmo host e não foi projetado para sistema de arquivos de rede. Deixe um processo controlar a ingestão, agrupe registros em transações, monitore espaço, planeje checkpoints e backups e teste recuperação após perda de energia no hardware real. Use uma versão com as correções relevantes à implantação.
Na reconexão, o gateway pode reenviar eventos sem duplicá-los se o endpoint remoto for idempotente. Mantenha cursor ou confirmação local durável para que uma reinicialização não descarte um lote em silêncio. Defina o que acontece quando o disco enche: pausar coleta, descartar somente dados explicitamente menos importantes ou preservar resumos e alertar a operação. Sobrescrever silenciosamente não é política de retenção.
Guarde dados brutos de alta resolução apenas pelo período exigido por um caso real, regra aplicável ou investigação. Vibração bruta por dias, resumos horários por meses e resultados de manutenção por mais tempo são exemplos, não prazos universais. Preserve método de agregação, número de amostras, mínimo/máximo e unidades para que uma média não apague um alarme curto. Defina a janela de eventos atrasados e se leitura corrigida substitui a anterior ou gera revisão auditável.
Reproduza a mesma carga sintética ou autorizada nas opções candidatas. Mantenha hardware, rede, formato, retenção, índices, lote e consultas comparáveis. Meça atraso de ingestão, p95 do painel, crescimento de armazenamento, CPU/memória, recuperação após reinício, restauração de backup e esforço operacional. Inclua janelas recentes e antigas, agregações da frota, eventos fora de ordem e isolamento por cliente. Publique carga e esquema junto aos números: taxa isolada de escrita não é benchmark reutilizável.
Defina contrato estável por evento: ID lógico, métrica, unidade, versão do esquema, horário do evento e recebimento e chave idempotente. Assim, é possível gravar temporariamente nos dois lados, comparar totais e agregações por janelas delimitadas, validar retenção e acesso e trocar as leituras por feature flag. Defina prazo para encerrar a gravação dupla e critérios de rollback. Não deixe dois bancos virarem fontes concorrentes por acidente.
Escolha conforme fluxo e consultas: Postgres quando relações e SQL dominam; InfluxDB quando seu modelo temporal e ciclo operacional se encaixam; SQLite quando um host na borda precisa gravar com confiabilidade durante uma queda de conexão. Comece pelo sistema mais simples que atende aos requisitos medidos, explicite retenção e reenvio e reavalie com dados reais, não com folclore de marcas.