pg_clickhouse v0.10 de ClickHouse reduce el tiempo de ejecución de TPC-H Q17 884x

Why it matters

ClickHouse is using pg_clickhouse to make its analytical engine adoptable without a wholesale PostgreSQL migration. The 884x Q17 result shows the payoff when pushdown works, while the remaining query gaps define the engineering risk.

ClickHouse engineer Josh Ventura lanzó pg_clickhouse v0.10.0 el 11 de agosto, empujando más subconsultas de PostgreSQL hacia ClickHouse y reduciendo una consulta TPC-H probada por el proveedor de 32.7 segundos a 37 milisegundos.

La versión avanza la arquitectura que el cofundador y CTO de ClickHouse, Alexey Milovidov, comenzó a construir en 2009: mantener las consultas analíticas interactivas a medida que los datos subyacentes crecen. El sistema subyacente ClickHouse entró en producción en Yandex.Metrica en 2012 y se convirtió en un proyecto de código abierto en 2016. Los cofundadores Aaron Katz y Yury Izrailevsky después ayudaron a convertir esa base de datos en un negocio independiente, y pg_clickhouse extiende la misma apuesta por el rendimiento dentro de PostgreSQL en lugar de pedir a los desarrolladores que abandonen la interfaz que ya usan sus aplicaciones.

En un post técnico anunciando la v0.10.0, Ventura describió el objetivo inmediato de la versión como el empuje completo de consultas (query pushdown) a lo largo del benchmark TPC-H de 22 consultas. El proyecto pasó de 12 consultas completamente empujadas a 16, dejando seis sin resolver.

El resultado es más restringido de lo que sugiere la expresión “1000x más rápido”. ClickHouse midió una mejora de aproximadamente 884x para TPC-H Q17, una carga de trabajo específica de subconsultas correlacionadas a factor de escala 1. Las cifras son benchmarks del proveedor, y no establecen que las cargas de trabajo de PostgreSQL en general se vuelvan cientos de veces más rápidas tras instalar la extensión.

Sí muestran por qué importa la colocación de la ejecución.

Mover el trabajo en lugar de las filas

pg_clickhouse es una extensión de PostgreSQL y un foreign-data wrapper de código abierto. Permite que una sesión de PostgreSQL consulte tablas alojadas en ClickHouse mientras intenta enviar filtros, joins, agregaciones y otras operaciones compatibles a ClickHouse para ejecución remota.

Antes de la v0.10.0, ciertas subconsultas correlacionadas seguían como planes locales de PostgreSQL. pg_clickhouse podía terminar recuperando filas desde ClickHouse y evaluando la subconsulta contra cada fila externa. Ese diseño borraba la ventaja de poner los datos analíticos en una base de datos orientada a columnas porque la extensión movía grandes conjuntos de resultados a través del límite de la base de datos y repetía trabajo dentro de PostgreSQL.

El equipo de Ventura cambió el planner y el deparser para que las subconsultas de PostgreSQL compatibles se conviertan en subconsultas de ClickHouse dentro de la sentencia SQL remota. Ventura resumió el cambio de manera llana: "Ahora, las subconsultas en Postgres se vuelven subconsultas en ClickHouse."

Q17 ofrece el ejemplo más claro. La consulta calcula una cantidad promedio para cada parte mediante una subconsulta correlacionada sobre 6 millones de line items. ClickHouse informó que pg_clickhouse v0.3 tardó 32,709 milisegundos porque la operación se evaluó localmente. La versión 0.10 la completó en 37 milisegundos después de enviar la consulta completa a ClickHouse. PostgreSQL nativo tardó 2,107 milisegundos en la misma prueba publicada.

La tabla de benchmarks actual indica que las pruebas usaron el factor de escala 1 de TPC-H en un MacBook Pro con un procesador M4 Max y 36 GB de memoria. Q2 cayó de 3,446 milisegundos en pg_clickhouse v0.3 a 24 milisegundos en v0.10. Q22 bajó de 1,415 milisegundos a 45 milisegundos, aunque Q22 todavía utiliza múltiples escaneos remotos en lugar de un solo foreign scan.

Esas salvedades importan. TPC-H es un benchmark de soporte a decisiones controlado, y los números publicados cubren una máquina, una escala de datos y planes de consulta seleccionados. ClickHouse no ha publicado conteos de despliegues de pg_clickhouse, resultados de clientes en producción o ingresos atribuibles a la extensión.

La corrección de las consultas se volvió el problema más difícil

Enviar SQL a otro motor de base de datos crea una segunda obligación: la consulta remota debe devolver el resultado que PostgreSQL habría producido.

Ventura centró parte de la versión en las expresiones IN, NOT IN, ANY y ALL que involucran valores nulos. PostgreSQL usa lógica de tres valores, donde una expresión puede evaluarse como verdadero, falso o nulo. El comportamiento por defecto de ClickHouse para estas operaciones usa lógica de dos valores. Una traducción ingenua puede por lo tanto devolver filas que PostgreSQL habría filtrado.

La versión 0.10 añade salvaguardas basadas en cómo se consume una expresión y si pg_clickhouse puede probar que sus operandos no pueden ser nulos. Ese enfoque reduce el riesgo de que una consulta aparentemente exitosa produzca una respuesta sutilmente diferente.

La nueva ruta de subconsultas correlacionadas requiere ClickHouse 25.8 o posterior. pg_clickhouse verifica la versión del servidor durante la planificación y recurre a la evaluación local cuando el servidor ClickHouse conectado no puede manejar la consulta traducida.

Seis consultas TPC-H permanecen fuera del empuje completo: Q13, Q15, Q16, Q18, Q20 y Q21. Varias están bloqueadas porque PostgreSQL convierte sus subconsultas en anti- o semi-joins cuyos inputs contienen joins adicionales. El deparser de pg_clickhouse aún no puede atravesar árboles de joins en ambos lados de esa operación. ClickHouse identifica ese trabajo del planner como el siguiente gran paso.

La extensión se está convirtiendo en parte de la estrategia Postgres de ClickHouse

ClickHouse introdujo pg_clickhouse en diciembre de 2025 para reducir el trabajo de la aplicación requerido cuando los datos analíticos salen de PostgreSQL. La premisa era que mover datos mediante replicación se había vuelto más fácil, mientras que reescribir años de SQL incrustado en paneles, ORM y trabajos programados seguía siendo caro.

Desde entonces la extensión se ha convertido en un componente de Postgres managed by ClickHouse, que entró en beta pública en mayo de 2026. Ese servicio combina PostgreSQL para transacciones, captura de cambios en ClickHouse y pg_clickhouse como una capa de consultas que abarca ambos sistemas. El valor estratégico radica en preservar PostgreSQL como la interfaz orientada a la aplicación mientras ClickHouse captura la ejecución analítica más pesada.

La estrategia está dirigida a cuentas que ya dependen de PostgreSQL y que resistirían una migración completa de base de datos. También pone presión al equipo de ingeniería para soportar la larga cola del comportamiento de consultas de PostgreSQL, donde las fallas de compatibilidad pueden ser más difíciles de detectar que errores directos.

ClickHouse tiene el capital para seguir trabajando esa lista. En enero, ClickHouse recaudó $400 millones en una Serie D liderada por Dragoneer Investment Group, con participación de Bessemer Venture Partners, GIC, Index Ventures, Khosla Ventures, Lightspeed Venture Partners, cuentas asesoradas por T. Rowe Price y WCM Investment Management. ClickHouse dijo en mayo que había superado 4,000 clientes y $250 millones en ingresos anualizados.

La versión 0.10 también reconstruye el driver binario en torno a la biblioteca cliente en C puro de ClickHouse, transmite grandes resultados en bloques, añade controles de compresión y TLS, y da a los foreign scans concurrentes conexiones separadas. Este último cambio aborda bugs de concurrencia en el driver. ClickHouse también amplió el soporte de pushdown para agregados estadísticos, agregados de conjunto ordenado, agregación por particiones, operaciones de fecha y funciones de cadena.

La mejora del benchmark atraerá atención, pero la prueba mayor de pg_clickhouse es la compatibilidad. Milovidov construyó ClickHouse alrededor de la ejecución analítica rápida. La empresa ahora apuesta a que ClickHouse puede vender ese motor detrás de la interfaz PostgreSQL que los desarrolladores ya confían. El trabajo de Ventura sobre subconsultas cierra varias de las brechas más costosas, con seis consultas del benchmark y un universo mucho mayor de SQL de producción aún por delante.