Benchmarks de bases de datos: por qué te mienten

Los benchmarks de bases de datos son engañosos porque cada test premia un tipo de carga distinto: una base puede ganar en ingesta masiva y perder fea en queries analíticas. En junio de 2026, QuestDB publicó un análisis que lo deja claro con una analogía: el ganador no siempre es el más rápido, es el que mejor balancea velocidad contra reglas arbitrarias.

Un benchmark de base de datos es una prueba estandarizada que mide rendimiento (ingesta, latencia, throughput de queries) bajo un workload definido. El problema es que ese workload casi nunca coincide con el tuyo. Cuando comparás categorías distintas (series temporales contra documentos contra OLTP), el resultado depende más del test elegido que de la base en sí. No existe un benchmark neutral y completo.

¿Por qué un benchmark perfecto es como buscar un unicornio?

Todos aman los benchmarks. Ves un resultado, leés que “la base X es la más rápida” y listo, ya está decidido. Ya lo cubrimos antes en automatizar benchmarks en CI/CD.

El análisis de QuestDB arranca con una imagen buenísima. Imaginate unos Juegos Olímpicos donde el “Citius, Altius, Fortius” se aplica en serio. Te acercás a la pista y descubrís que la competencia es otra cosa: los atletas tienen que silbar “Yellow Submarine” afinados mientras corren. El más rápido puede salir último. Gana quien combina velocidad con una habilidad que no tiene nada que ver con correr.

Eso es exactamente lo que pasa cuando comparás benchmarks de bases de datos de categorías diferentes. Cada test mete una restricción (un tipo de query, un esquema, una métrica) y esa restricción cambia quién gana. Un benchmark perfecto, completamente justo, es como el unicornio: suerte buscándolo.

¿Cómo el tipo de workload determina el ganador?

Ponele que tenés que elegir base para una app de trading que ingesta millones de eventos por segundo. Mirás un benchmark de queries OLTP transaccionales y elegís la que ganó ahí. Mala idea: ese test no se parece en nada a tu carga.

Cada motor está optimizado para un caso. Una base de series temporales como QuestDB brilla en ingesta secuencial y agregaciones por tiempo. Una base de datos documental como MongoDB se mueve cómoda con datos flexibles y anidados. Una relacional como PostgreSQL es la referencia en transacciones con integridad fuerte. Ninguna es “mejor”: son distintas, y el benchmark que elijas va a coronar a una sobre las otras según lo que mida. Tema relacionado: al evaluar herramientas de orquestación.

El Time Series Benchmark Suite (TSBS) se volvió la vara de la industria para series temporales. Útil, sí. Pero mide un puñado de queries específicas. Si tu app hace algo distinto, el ranking de TSBS te orienta poco.

¿Cuál es la diferencia entre el laboratorio y la producción?

Acá viene lo bueno: el número del benchmark y lo que pasa en tu servidor real casi nunca coinciden.

El paper de Raasveldt y Mühleisen sobre testing de performance documenta los errores típicos que invalidan estas mediciones: no vaciar las cachés entre corridas, comparar contra una configuración por defecto sin tunear, ignorar el efecto del compilador y los flags, o reportar una sola corrida sin varianza. Cosas que cualquiera que haya benchmarkeado algo en serio se topó alguna vez.

Subís el motor, lo probás en local, anda bárbaro, lo mandás a producción y de repente todo se cae porque el dataset real era diez veces más grande, el patrón de acceso mezclaba datos calientes y fríos, había concurrencia que el test nunca simuló y el query planner eligió otro camino. ¿Alguien lo había verificado de forma independiente antes de migrar? Casi nunca. Te puede servir nuestra cobertura en guías técnicas multiidioma.

¿Qué variables ocultas sesgan los resultados?

Hay factores que no aparecen en el gráfico de barras y que deciden todo. Estos son los que más importan:

• Cardinalidad: según la comparativa de QuestDB, algunos motores de series temporales degradan fuerte cuando crece la cantidad de series únicas, mientras otros sostienen el throughput. El número que viste con 1.000 hosts no vale para 1 millón.
• Tamaño del dataset: un benchmark sobre datos que entran en RAM no te dice nada de cuando la base tiene que ir a disco.
• Datos calientes contra fríos: el patrón de acceso real mezcla ambos. El test suele tocar siempre lo mismo.
• Concurrencia: un cliente secuencial no estresa locks ni colas como cien clientes simultáneos.
• Modelo de consistencia: una base que afloja garantías va a “ganar” en velocidad contra una que las mantiene. No es la misma carrera.

¿Cómo evaluar un benchmark de forma crítica?

Antes de creerle a cualquier ranking, pasalo por este filtro:

• ¿Qué workload mide exactamente? Ingesta, queries, mixto. Y si se parece al tuyo.
• ¿Quién lo financió y lo corrió? Ojo con el benchmark del propio fabricante. No lo descartes, pero leelo con pinzas.
• ¿Publicaron la metodología? Hardware, versiones, flags, scripts. Si no está, no es reproducible.
• ¿Incluye P99 y P999? El promedio esconde la latencia de cola, que es la que te arruina la experiencia.
• ¿Testea bajo falla o degradación? Un nodo caído, disco lleno, carga variable. Producción no es un día soleado.

Un buen punto de partida abierto es el repo db-benchmarks, que apuesta por metodologías reproducibles. Eso sí: ninguno te exime de probar con tus datos.

Criterios que importan más que un número

El throughput es una métrica entre varias. A la hora de elegir en serio, pesan más estas:

Criterio	Qué mirar	Por qué importa
Escalabilidad	¿Degrada con carga creciente?	Lo que vuela con 10 GB puede arrastrarse con 10 TB
Latencia P99/P999	Cola, no promedio	El 1% lento es el que ve tu usuario enojado
Consistencia	Garantías ante fallos	Velocidad sin datos correctos no sirve
Portabilidad	Soporte Parquet, SQL estándar	Evita vendor lock-in
Costo operativo	Infra, mantenimiento, soporte	El precio real es el de operarla un año
Comunidad	Docs, issues activos	Cuando algo se rompe a las 3 AM

Si manejás infraestructura web, cloud o servidores para alojar tu base, en Argentina podés ver las opciones de donweb.com para hosting y VPS.

Qué está confirmado y qué no

• Confirmado: QuestDB publicó el 18 de junio de 2026 el artículo “Lies, Damn Lies and Database Benchmarks” cuestionando la objetividad de los benchmarks públicos.
• Confirmado: el paper de Raasveldt y Mühleisen (DBTEST 2018) cataloga errores recurrentes en testing de performance de bases de datos.
• Pendiente de verificar: cifras concretas de degradación por cardinalidad o gaps porcentuales lab/prod varían según hardware y versión. Tomá cualquier número puntual como referencia, no como ley.
• Pendiente: tu caso. Ningún benchmark publicado reemplaza una prueba con tus datos reales.

Errores comunes al leer benchmarks

• Confiar en el promedio: un promedio bajo puede esconder picos de latencia brutales. Pedí siempre los percentiles altos.
• Ignorar la fuente: el benchmark “independiente” muchas veces lo corrió el fabricante que sale ganando. No lo tires, pero contrastalo.
• Extrapolar de un dataset chico: medir con datos que entran en memoria y asumir que escala. No escala igual cuando pega el disco.
• Comparar contra defaults: testear tu base tuneada contra la rival sin tunear. Eso no es una comparación, es trampa.

Preguntas Frecuentes

¿Por qué los benchmarks de bases de datos son engañosos?

Porque cada benchmark mide un workload específico que premia a cierto tipo de base. Cambiás el test y cambia el ganador. Comparar categorías distintas (series temporales contra OLTP) con un solo benchmark no refleja el rendimiento real en tu caso. Relacionado: analizar en ambientes locales controlados.

¿Cómo elegir una base de datos sin confiar solo en benchmarks?

Probá con tus datos reales y tu patrón de acceso antes de decidir. Definí tu workload (ingesta, queries, concurrencia), corré una prueba propia y mirá escalabilidad, latencia P99 y costo operativo, no solo el throughput máximo.

¿Qué diferencia hay entre un benchmark y el rendimiento en producción?

El benchmark corre en un entorno controlado con dataset acotado y carga predecible. Producción suma cardinalidad alta, concurrencia, datos fríos, fallos y configuraciones que el test no simula. Por eso una base que gana en el lab puede rendir distinto en tu servidor.

¿Cómo validar si un benchmark es confiable?

Revisá que publique metodología completa (hardware, versiones, flags, scripts), que sea reproducible, que incluya percentiles P99/P999 y no solo promedios, y que aclare quién lo financió. Si testea bajo falla y degradación, mejor todavía.

¿Qué es la latencia de cola y por qué importa?

La latencia de cola es el tiempo de respuesta del peor 1% o 0,1% de las operaciones (P99 y P999). Importa porque ese pequeño porcentaje lento es el que percibe el usuario, y el promedio lo oculta por completo.

Conclusión

El cambio que propone QuestDB no es técnico, es de actitud: dejar de leer benchmarks como veredictos y empezar a leerlos como lo que son, tests con reglas arbitrarias que favorecen a alguien. Importa porque una mala elección de base se paga durante años en infraestructura y dolores de cabeza.

Qué hacer: definí tu workload real, exigí metodología y percentiles a cualquier benchmark que mires, desconfiá del promedio y, sobre todo, corré tu propia prueba con tus datos antes de migrar. El benchmark más confiable es el que armás vos con tu caso.

Fuentes

• QuestDB – Lies, Damn Lies and Database Benchmarks (junio 2026)
• QuestDB – Comparativa de series temporales y cardinalidad
• Raasveldt & Mühleisen – Fair Benchmarking Considered Difficult (DBTEST 2018)
• db-benchmarks – Metodología abierta y reproducible
• arXiv – Estudio sobre prácticas de benchmarking de bases de datos