PostgresBench mide Postgres sin humo

Si alguna vez comparaste dos servicios de Postgres y terminaste más confundido que al inicio, no estás solo. Un proveedor te promete menos latencia, otro te muestra un gráfico bonito con una carga que nadie usa en producción, y al final tu decisión depende de una demo, una hoja de cálculo y mucha fe. El problema no es que falten números. El problema es que muchas veces los números no son comparables.

Ahí es donde entra PostgresBench, una propuesta de ClickHouse para medir servicios Postgres con un benchmark reproducible. La idea es simple: si el método cambia cada vez, la comparación pierde valor. Si el método se puede repetir, documentar y revisar, entonces sí puedes usarlo para hablar de costos, rendimiento y arquitectura con menos humo y más datos accionables.

Qué intenta resolver PostgresBench

PostgresBench nace para atacar una molestia bastante común en equipos de ingeniería: cada proveedor de Postgres presenta sus resultados a su manera. Uno habla de throughput, otro de consultas por segundo, otro de tiempos de respuesta bajo una carga muy específica. Si tú intentas comparar servicios administrados, réplicas, instancias dedicadas o despliegues propios, la conversación se vuelve un campo minado.

La propuesta del benchmark es crear un escenario repetible para que puedas medir servicios Postgres bajo condiciones conocidas. Eso significa que el dataset, la carga, la configuración y la metodología no deberían cambiar entre una prueba y otra sin que lo notes. Según la publicación de ClickHouse, la clave no es solo correr pruebas, sino poder repetirlas de forma consistente y comparar resultados con una base común.

Por qué la reproducibilidad importa

En bases de datos, reproducible no es una palabra de marketing. Es la diferencia entre una decisión técnica y una apuesta. Si tú ejecutas una prueba hoy en una instancia con 2 vCPU y mañana en otra con 4 vCPU, pero además cambias el tamaño del dataset, el caché o el patrón de acceso, ya no estás comparando el mismo experimento.

Cuando un benchmark es reproducible, puedes hacer tres cosas útiles:

1. Repetir la prueba cuando cambia el proveedor o la versión de PostgreSQL.
2. Validar si una optimización realmente mejora el rendimiento o solo mueve el cuello de botella.
3. Compartir resultados con tu equipo sin que la discusión se vaya a “sí, pero esa corrida estaba rara”.

Eso es especialmente útil si trabajas con presupuestos ajustados. En LatAm, muchas veces no eliges la opción más cara, sino la que da mejor relación entre costo, rendimiento y operación. Un benchmark consistente te ayuda a defender esa decisión con menos intuición y más evidencia.

Qué tipo de preguntas te ayuda a responder

PostgresBench no existe para decirte cuál proveedor es “el mejor” en abstracto. Sirve para preguntas concretas, por ejemplo:

• ¿Qué servicio aguanta mejor una mezcla realista de lecturas y escrituras?
• ¿Qué pasa si subes el tamaño del dataset y el working set ya no cabe en memoria?
• ¿Cómo cambia la latencia cuando agregas más concurrencia?
• ¿La diferencia de precio entre dos proveedores se justifica por el rendimiento real?

Ese enfoque es más útil que una tabla de marketing. Tú no compras una base de datos por una cifra aislada, sino por cómo se comporta bajo tu carga.

Cómo pensar un benchmark de Postgres sin caer en trampas

La mayoría de los benchmarks malos tienen el mismo problema: miden algo, pero no lo que te importa. Una prueba con datos sintéticos puede servir para un primer filtro, pero si el patrón de acceso no se parece a tu aplicación, el resultado tiene poco valor operativo. Lo mismo pasa si el benchmark favorece una sola operación, como lecturas secuenciales, y deja fuera la mezcla normal de tu sistema.

PostgresBench intenta reducir ese sesgo con una metodología más clara. No se trata de correr una sola vez y publicar una captura. Se trata de definir un entorno, documentar parámetros y comparar bajo reglas estables. Eso te deja una base más honesta para hablar de arquitectura.

Variables que sí debes controlar

Si tú vas a usar un benchmark para comparar servicios Postgres, estas variables no pueden quedar sueltas:

• Tamaño del dataset.
• Número de conexiones concurrentes.
• Tipo de carga: lectura, escritura o mezcla.
• Configuración de memoria y almacenamiento.
• Versión exacta de PostgreSQL.
• Región o zona donde corre la base.

Cualquier cambio en una de esas variables puede alterar el resultado. Por eso, cuando revises un informe, no te quedes solo con el número final. Mira el contexto completo.

Un ejemplo práctico de comparación

Imagina dos servicios administrados. El primero cuesta menos por hora, pero usa discos más lentos. El segundo cuesta 25% más, pero maneja mejor la concurrencia. Si tu app tiene picos de tráfico en horas laborales, el costo real no es solo el precio de la instancia. También cuenta cuánto tiempo pierdes en latencia, cuántas consultas se encolan y qué tanto margen te queda para crecer.

Un benchmark reproducible te permite poner eso sobre la mesa. No te dice qué comprar, pero sí te ayuda a cuantificar la diferencia. Y eso cambia la conversación con compras, con producto y con dirección técnica.

Qué mirar cuando comparas proveedores y arquitecturas

No todos los servicios Postgres compiten en el mismo terreno. Hay opciones administradas, despliegues en máquinas virtuales, contenedores con almacenamiento persistente y arquitecturas con réplicas para lectura. Si tú comparas todo con un solo número de throughput, vas a perder matices importantes.

La publicación de ClickHouse apunta a una idea útil: el benchmark debe servir para comparar servicios, no solo motores. Es decir, no basta con saber cómo responde PostgreSQL como software. También importa cómo se comporta el servicio completo, incluyendo almacenamiento, red, límites de conexión y políticas del proveedor.

Latencia, throughput y costo no cuentan lo mismo

Hay tres métricas que conviene mirar juntas:

• Latencia: cuánto tarda una consulta en responder.
• Throughput: cuántas operaciones soporta por unidad de tiempo.
• Costo: cuánto pagas por ese nivel de servicio.

Si solo miras throughput, puedes terminar con un sistema que aguanta mucho pero responde tarde. Si solo miras latencia, puedes pagar de más por una mejora que tu app ni nota. El punto está en cruzar las tres.

Arquitecturas que vale la pena comparar

No necesitas probar diez variantes para obtener una señal útil. Con tres escenarios bien definidos ya puedes aprender bastante:

1. Servicio administrado básico.
2. Instancia dedicada o con más recursos.
3. Despliegue propio con configuración ajustada.

Si tu equipo opera en Ecuador, Colombia, Perú o México, también conviene mirar la latencia de red hacia la región donde vive la base. A veces la diferencia entre dos proveedores no está en el motor, sino en la distancia y en la calidad de la ruta de red. Ese detalle puede mover mucho la experiencia de usuario.

Cómo usar un benchmark reproducible en tu equipo

La parte más valiosa de un benchmark no es el gráfico. Es el proceso. Si tu equipo adopta una forma consistente de medir, entonces puedes repetir pruebas antes de una migración, después de un cambio de versión o cuando aparece una factura demasiado alta.

PostgresBench encaja bien en equipos que necesitan una referencia clara para tomar decisiones técnicas. No reemplaza las pruebas con tu carga real, pero sí puede servir como filtro inicial y como lenguaje común entre ingeniería, DevOps y finanzas.

Flujo recomendado para evaluarlo

Te conviene seguir un proceso como este:

1. Define el objetivo: comparar costo, latencia o capacidad.
2. Fija el entorno: región, tamaño de instancia, versión y almacenamiento.
3. Ejecuta una corrida base con parámetros documentados.
4. Repite la prueba al menos tres veces para ver variación.
5. Registra resultados en una tabla con contexto, no solo números.
6. Compara contra tu carga real antes de decidir.

Ese flujo evita errores comunes. Por ejemplo, si una corrida aislada sale muy bien pero las siguientes no, ya sabes que no debes tomarla como verdad absoluta.

Qué debería salir del benchmark

Un buen benchmark no termina en “esta opción ganó”. Debería dejarte al menos estas salidas:

• Una comparación clara entre proveedores.
• Un rango de variación entre corridas.
• Una lectura de costo por unidad de trabajo.
• Una lista de límites o alertas que viste durante la prueba.

Con eso puedes preparar una propuesta más seria. Si vas a pedir cambio de proveedor o de arquitectura, tener esos datos te ahorra discusiones largas y poco productivas.

Qué no deberías hacer

También hay errores que conviene evitar:

• Probar solo con una carga artificial que no se parece a producción.
• Cambiar varias variables al mismo tiempo.
• Publicar solo el mejor resultado y esconder el resto.
• Ignorar la influencia de la red y del almacenamiento.
• Tomar decisiones con una sola corrida.

Si haces eso, el benchmark deja de servir como herramienta técnica y se convierte en material de presentación.

Lo que aporta frente a comparaciones tradicionales

Las comparaciones tradicionales de bases de datos suelen tener dos problemas. El primero es que mezclan demasiadas variables sin control. El segundo es que no dejan suficiente detalle para que otra persona repita la prueba. PostgresBench, según la propuesta de ClickHouse, apunta justamente a cerrar esa brecha.

Eso no significa que sea perfecto ni que resuelva todo. Significa que empuja la conversación hacia algo más útil para equipos técnicos: comparar bajo reglas claras. Y cuando eso pasa, las discusiones sobre rendimiento dejan de ser opiniones sueltas.

Cuando te conviene usarlo

Te puede servir especialmente si estás en alguno de estos casos:

• Evaluando migración entre proveedores de Postgres.
• Comparando una instancia administrada contra despliegue propio.
• Justificando una arquitectura con réplicas o más recursos.
• Revisando si una versión nueva mejora o empeora el rendimiento.
• Necesitando una base común para hablar con stakeholders no técnicos.

Si tu problema hoy es decidir rápido, un benchmark reproducible te ayuda a recortar opciones. Si tu problema es optimizar una base ya en producción, te da una referencia para validar cambios sin improvisar.

Dónde encaja en una estrategia real

En la práctica, tú no deberías depender de un solo benchmark. Lo sano es combinar tres capas:

• Benchmark reproducible para comparar opciones.
• Pruebas con datos parecidos a producción.
• Monitoreo real después del despliegue.

Esa combinación te da una foto más completa. El benchmark te orienta, la carga real te confirma y la observabilidad te dice si la decisión se sostuvo en el tiempo.

Para revisar más detalle técnico sobre la propuesta, puedes leer la publicación oficial de ClickHouse: https://clickhouse.com/blog/postgresbench. Si quieres profundizar en buenas prácticas de PostgreSQL, la documentación oficial de PostgreSQL también es una referencia útil: https://www.postgresql.org/docs/current/. Y si estás afinando el motor para producción, vale la pena revisar la guía de tuning y configuración del proveedor o distribución que uses.

Tabla resumen

En equipos que viven entre presión de negocio, presupuestos limitados y sistemas que no pueden caerse, un benchmark reproducible vale más que una demo bien armada. La gracia de PostgresBench está en que baja la conversación al terreno de los hechos: misma carga, mismas reglas, resultados comparables.

Si tú trabajas con Postgres y necesitas elegir proveedor, arquitectura o tamaño de instancia, esta clase de enfoque te ahorra tiempo. No te promete una respuesta mágica. Te da algo mejor: una forma más limpia de encontrar la respuesta correcta para tu caso.