pgrust, el Postgres en Rust, supera 3x a ClickHouse

Qué es Gravity y por qué pgrust dice que es 3x más rápido que ClickHouse

Con la llegada de pgrust v0.4-beta, su nuevo motor de consultas Gravity es hasta 3x más rápido que ClickHouse en ClickBench, el benchmark que el propio equipo de ClickHouse diseñó para exhibir la velocidad de su base de datos. El detalle que lo vuelve interesante para un equipo de producto: Gravity logra ese rendimiento sin resignar el dialecto SQL completo de Postgres ni su sistema de tipos.

Para dimensionar el salto: según la documentación oficial de pgrust, la versión v0.2 con almacenamiento columnar ya era 18.5% más rápida que ClickHouse en la suite de ClickBench. Pasar de 18.5% a 3x no es una mejora incremental del mismo motor, sino el resultado de reescribir la capa de ejecución desde cero.

El proyecto tampoco es un experimento anónimo. Según Better Stack, pgrust es una reescritura completa de PostgreSQL en Rust liderada por Malcolm Matis, ex CEO de Heap, apoyada en ocho agentes de IA de programación trabajando en paralelo. La v0.1 pasó las 46.066 consultas de la suite de regresión de PostgreSQL 18.3, y el repositorio es público en github.com/malisper/pgrust.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Cómo se construye un motor que apunta a la "velocidad de la luz"

La mayoría de los equipos optimiza de abajo hacia arriba: corren un benchmark, miran un flamegraph, encuentran el hotspot y rascan un 15% o 20%. El problema de ese método, según el propio equipo de pgrust, es que nunca sabes cuál es el techo: puedes estar a 20% del límite del hardware o a 100x de distancia.

Gravity se diseñó al revés. Primero midieron el límite físico: dejaron que Claude escribiera programas Rust altamente optimizados directamente contra sus crates de almacenamiento columnar, salteando por completo el ejecutor SQL. Esos programas corrieron las consultas analíticas del corpus aproximadamente 4x más rápido que bases de datos analíticas existentes como ClickHouse. Ese resultado se convirtió en la meta: para cualquier consulta SQL, compilar en tiempo de ejecución código máquina que quede dentro del 20% del Rust escrito a mano.

La arquitectura elegida para lograrlo es un pipeline de compilación en cuatro etapas que baja progresivamente el nivel de abstracción:

Plan de Postgres: Gravity no reemplaza el parser ni el planner de Postgres. El planner analiza estadísticas y produce un plan estándar.
Pipeline Graph: una representación intermedia que expresa cómo fluyen los datos y cómo se transforma cada fila durante la consulta.
Lisp IR: cada pipeline se compila a una función en un IR ensamblador basado en Lisp, donde se pueden fusionar scan, filtro, proyección y agregación en la estructura de loop que convenga.
Assembly: backends por arquitectura traducen ese IR a instrucciones de máquina.

El orden de construcción también fue deliberado: primero probaron los backends y el IR compilando programas escritos a mano que replicaban el Rust de referencia. El resultado fue que el Lisp IR compila en menos de un milisegundo y corre entre 10% y 20% del Rust compilado con rustc. Con eso validado, todo el trabajo restante se redujo a compilar SQL hacia ese IR.

Las tres optimizaciones que el planner de Postgres no puede expresar

Cuando compararon Gravity contra el Rust de referencia, encontraron consultas donde la diferencia no venía del loop compilado sino del algoritmo. El planner de Postgres no puede expresar tres algoritmos específicos de formato columnar, así que los agregaron como planes con costo estimado. La clave es que en una tabla columnar el orden físico de los datos suele agrupar valores similares: pgrcolumnar divide la tabla en lotes de 8.192 filas llamados granules, y cada granule guarda metadatos con sus valores mínimo y máximo.

ZoneWalk: para consultas ORDER BY ... LIMIT n, en lugar de escanear toda la tabla y ordenar, usa los límites min/max para leer los granules en orden y detenerse apenas se resuelven las n filas.
ZoneTopK: para GROUP BY ... LIMIT n, camina los granules ordenados por la clave de agrupación y corta el escaneo cuando ya tiene n grupos completos cuyo máximo posible queda por debajo del mínimo de todos los lotes restantes. El propio equipo señala que ClickHouse 26.10 tiene una optimización parecida, enable_group_by_top_k_dynamic_filtering, que también exige grupos completos.
TwoPass: para GROUP BY ... ORDER BY count(*) DESC LIMIT 10 con una columna de alta cardinalidad, primero calcula un límite superior del tamaño de cada grupo contando filas por clave y después recupera solo los grupos que podrían entrar en el top 10. El ahorro viene de leer una sola columna en la primera pasada.

Las optimizaciones dentro del compilador

Además de los algoritmos, el equipo documenta más de 100 optimizaciones en la compilación de SQL a IR. Tres ejemplos concretos:

Inlining de funciones y agregados: en Postgres estándar, evaluar extract(minute FROM EventTime) o actualizar un agregado pasa por el function manager en cada fila. pgrust categorizó las funciones nativas y alinea directamente 238 funciones y agregados en su IR. En el caso de AVG, el loop bajó de 392 a 120 instrucciones por fila y la consulta quedó 2.56x más rápida.
Late materialization: las columnas de texto se guardan con codificación de diccionario. Las primeras versiones de Gravity decodificaban el string en cada fila; el Rust de referencia nunca tocaba strings dentro del loop. Ahora el compilador opera sobre el código de diccionario el mayor tiempo posible y materializa el texto al final. Para un filtro como url LIKE '%google%', corre el matcher una vez por entrada única del diccionario y genera un bitmap de códigos que coinciden. Ese bitmap queda en memoria del servidor y se reutiliza si la misma consulta vuelve sobre datos sin cambios.
Run collapse en registros: en tablas reales, los valores de columnas como UserID o timestamps suelen estar parcialmente agrupados en disco, así que aparecen rachas de filas consecutivas del mismo grupo. Gravity mantiene la clave del grupo anterior y solo consulta la tabla hash cuando aparece una clave nueva. En una tabla de 100 millones de filas, eso colapsó 100 millones de accesos a la tabla hash en 22 millones.

Qué significa esto para tu startup

El mensaje para un equipo que hoy pelea con latencia en analítica no es "migra ya", sino entender dónde está tu techo. Gravity es un recordatorio de que la mayoría de las decisiones de performance se toman sin saber cuál es el límite físico del hardware y del formato de datos que ya tienes.

Dos acciones concretas que puedes ejecutar esta semana:

Mide tu techo antes de optimizar. Toma tus tres consultas analíticas más costosas y escribe el loop más simple posible en el lenguaje que uses, leyendo directo de tu formato de almacenamiento y sin pasar por el motor SQL. Ese número es tu límite real. Si tu motor actual está a 3x de ese límite, el problema es el ejecutor; si está a 100x, el problema es el algoritmo.
Audita tus consultas por forma, no por tabla. Las optimizaciones de Gravity atacan patrones específicos: ORDER BY ... LIMIT, GROUP BY ... LIMIT y agregaciones sobre columnas de alta cardinalidad. Revisa cuántas de tus consultas de dashboard caen en esos moldes; son las que más se benefician de un motor columnar con metadatos por bloque, y también las que más caro te salen hoy en un motor de filas.

Si tu stack ya es Postgres y no quieres reescribir la capa de aplicación, la propuesta de pgrust es relevante por una razón práctica: es compatible a nivel de protocolo y dialecto, así que la migración no exige cambiar drivers ni consultas. Según la documentación del proyecto, en el benchmark sysbench OLTP read-only a escala de 300 GB pgrust entrega 30% más throughput que PostgreSQL 18.3, gracias a su modelo de concurrencia por hilos y a un ejecutor JIT vectorizado con tiempos de compilación de aproximadamente 5 microsegundos.

Los números son del propio fabricante: léelos con criterio

Conviene ser explícito en algo. Los resultados de ClickBench son reportados por el propio equipo de pgrust, y la comparación contra su ejecutor de filas (Volcano) es una medición interna: 102x más rápido en frío y 499x en caliente, y más de 1.000x mejor que PostgreSQL 17 en el score combinado sobre una máquina c6a.4xlarge, con 1.365x en corridas en frío. Son cifras de un solo proveedor sobre su propio benchmark.

También hay que mirar el contexto competitivo. Que ClickHouse 26.10 ya tenga una optimización equivalente a ZoneTopK sugiere que la ventaja puede estrecharse en las próximas versiones. Y el propio autor reconoce que su entrada previa de v0.4-preview en ClickBench generó discusión en Hacker News, un recordatorio de que en benchmarks de bases de datos la metodología pesa tanto como el resultado.

El otro punto es la madurez. Según Better Stack, pgrust no está listo para producción: la release actual es una demostración de compatibilidad y el ecosistema de extensiones sigue incompleto. Para un founder, eso significa que el valor hoy está en la arquitectura y en las ideas que puedes copiar —empezar por el límite físico, agregar algoritmos conscientes del formato columnar, medir con fuzzing en lugar de optimizar para una sola consulta— más que en mover tu base de datos de producción mañana.