Un análisis comparativo ejecutado durante seis días sobre un servidor Hetzner CCX13 de 16,49 dólares mensuales evalúa DuckDB frente a SQLite como motor de almacenamiento de telemetría dentro de Traceway, la herramienta OpenTelemetry del autor. Los resultados muestran que DuckDB, con su arquitectura columnar, multiplica por 100 el tamaño de tabla en el que los paneles de observabilidad siguen respondiendo en menos de cinco segundos: pasa de un millón a cien millones de filas en métricas, de cien mil a diez millones en spans y de cien mil a diez millones en logs, con latencias iguales o inferiores. En escritura, las métricas pasan de 61.712 a 254.242 puntos por segundo (4x), los spans de 30.508 a 95.737 (3x) y los logs saltan de 4.877 a 75.225 registros por segundo (15x), la señal donde la diferencia es más acusada. La prueba extrema consistió en ingerir mil millones de puntos métricos en menos de una hora, ocupando 10,8 GB de disco, una escala inalcanzable para SQLite. El autor detalla la metodología: misma máquina, mismo binario Traceway, generación de carga con OTLP sobre protobuf gzip en el centro de datos de Núremberg de Hetzner, y dos escenarios por señal —rampa de rendimiento y sonda de lectura hasta cinco mil millones de filas—. Reconoce que se trata de ejecuciones únicas, no de medias de tres repeticiones, y disclose tres cambios respecto al benchmark previo con SQLite: el generador de carga migra a un CCX23, se añade una puerta de espera para que DuckDB finalice los checkpoints antes de cada sonda, y solo se cuentan las filas confirmadas con respuesta 2xx. El autor también descubrió y corrigió un error en su propio ingest path, que carecía de control de admisión y provocaba caídas por agotamiento de memoria con DuckDB. La conclusión operativa es que, para autoalojar la pila OTel completa en un único servidor pequeño, la build con DuckDB amplía de forma muy significativa el volumen de datos manejable.
Noticias agregadas con IA