Hacer Postgres 300x más rápido para analítica: batching, fusión de operadores y SIMD

Licencias, modelo de negocio y adopción

• El foco principal del hilo es la licencia AGPL. Muchos dicen que es un “dealbreaker”, especialmente en entornos corporativos donde AGPL está prohibida o fuertemente desaconsejada, y que bloquea la incorporación al núcleo de Postgres.
• Quienes la apoyan argumentan que AGPL (o una copyleft similar) ya es el estándar para bases de datos, para evitar que los proveedores en la nube moneticen trabajo con licencia permisiva sin devolver contribuciones.
• Varios sugieren licenciamiento dual (AGPL + comercial) y establecer acuerdos adecuados de contribución; algunos temen que solo la empresa principal se beneficie financieramente del trabajo comunitario.
• Hay confusión y desacuerdo sobre lo que exige AGPL; algunos afirman que los clientes normales de BD están a salvo, mientras otros subrayan que AGPL no ha sido bien probada legalmente y es arriesgada.
• Algunos señalan que, si la mejora de rendimiento es real, los grandes actores podrían re-implementar Postgres por su cuenta bajo términos permisivos, especialmente dado el aparente bajo costo con ayuda de IA.

Port generado por IA y preocupaciones de copyright

• El historial de commits del repositorio muestra miles de commits coautorados por IA durante un mes; algunos lo llaman “AI slop” o “vibecoded” y cuestionan la profundidad de la revisión humana.
• El proceso descrito: C→Rust mediante c2rust, luego una fuerte refactorización con LLM más pruebas. Los críticos sostienen que esto es claramente una obra derivada y moralmente (si no legalmente) dudosa para relicenciarla a AGPL.
• Hay debate sobre si el código generado por LLM es siquiera protegible por copyright; algunos sugieren que la licencia podría ser irrelevante, pero esto se marca como poco claro.

Afirmaciones de rendimiento y benchmarks

• La afirmación de marketing es ~300x más rápido que Postgres para analítica; varios comentaristas son escépticos.
• Los críticos señalan que una demo desactivó el paralelismo de Postgres, haciendo que las comparaciones parezcan peores; los mantenedores dicen que la cifra de 300x proviene de resultados de ClickBench con el paralelismo activado.
• Según se informa, un experto externo revisó ejecuciones de ClickBench y confirmó mejoras de velocidad importantes; otros advierten que las pruebas pueden reflejar cargas analíticas específicas residentes en memoria, no uso OLTP general.
• La discusión señala que muchas cargas de trabajo están limitadas por memoria y caché; la ejecución columnar y vectorizada puede producir legítimamente mejoras muy grandes en ciertas consultas analíticas.

Corrección, fiabilidad y longevidad

• El equipo del proyecto enfatiza la corrección: verificación formal de ~1000 funciones, fuzzing diferencial frente a Postgres y trabajos externos para pruebas de fallos y verificación.
• Informan haber encontrado ~100 bugs en pgrust y ~20 en Postgres, incluidos errores sutiles de coma flotante.
• Aun así, muchos siguen preocupados de que un sistema de bases de datos joven, generado por IA, no pueda igualar décadas de pruebas en combate de Postgres; son frecuentes las preocupaciones sobre corrupción de datos y mantenimiento a largo plazo.

Arquitectura, características y casos de uso

• pgrust añade almacenamiento columnar como método de acceso a tablas, planificación adaptativa, un nuevo programador de consultas con limitación de recursos y work stealing, y un “test mode” para acelerar la clonación de la base de datos.
• Puede integrarse embebido (incluido para Wasm) y podría admitir bases de datos efímeras por prueba, réplicas analíticas de solo lectura vía WAL y despliegues más ligeros.
• Algunos lo ven como un motor analítico compatible con Postgres prometedor; otros dudan que desplace a Postgres, pero creen que puede coexistir para cargas de trabajo específicas.