ADR-011: Victoria Metrics como base de datos de series temporales principal¶
Estado: aceptado Fecha: 2026-05-17
Contexto¶
SmallCountry genera datos de series temporales de múltiples fuentes: sensores de colmena, estaciones meteorológicas, sensores de suelo, RFID de gallinero, consumo eléctrico, logs de servicios. Se necesita una TSDB que escale con decenas de fuentes de datos, sea eficiente en recursos (servidor único sin cluster), y se integre con el stack de observabilidad existente (Grafana, Prometheus).
Decisión¶
Victoria Metrics como almacén principal de series temporales, reemplazando a InfluxDB. Compatible con PromQL sin necesidad de adaptar consultas.
Alternativas consideradas¶
| Opción | Por qué se descartó |
|---|---|
| InfluxDB | Arquitectura multi-componente más pesada. InfluxQL vs PromQL fragmenta el ecosistema. El referente Hiveeyes usaba InfluxDB pero la migración a Victoria Metrics es una mejora explícita |
| TimescaleDB | Extensión PostgreSQL. Bueno para datos relacionales, overkill para métricas puras |
| Prometheus solo | Prometheus está diseñado para sondeo (pull), no para ingesta desde sensores IoT que publican (push). Retención limitada |
| Graphite | Ecosistema legacy. Menor rendimiento de compresión |
Consecuencias¶
- ✅ Compatibilidad PromQL total: Grafana, Alloy y Prometheus hablan el mismo idioma
- ✅ Mejor compresión que InfluxDB (~3-5x menos espacio en disco)
- ✅ Binario único en Go: despliegue simple, bajo consumo de RAM
- ✅ Integración nativa con Grafana Alloy vía OpenTelemetry
- ❌ Comunidad más pequeña que InfluxDB. Documentación a veces menos madura