Postgres reescrito en Rust ahora pasa el 100% de las pruebas de regresión de Postgres

 (github.com/malisper)
1 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • pgrust es un proyecto de reescritura en Rust que apunta a ser compatible con Postgres 18.3, y coincide con la salida esperada de Postgres en más de 46,000 consultas de regresión
  • Cuenta con compatibilidad de disco que le permite arrancar desde un directorio de datos existente de Postgres 18.3, y toma las pruebas reales de Postgres como referencia de comportamiento
  • Actualmente no está listo para producción, aún no tiene optimización de rendimiento, y las extensiones existentes de Postgres y las extensiones de lenguajes procedurales como PL/Python, PL/Perl y PL/Tcl por lo general no son compatibles
  • Se puede probar con una demo en WebAssembly y con la imagen Docker malisper/pgrust:v0.1; latest actualmente apunta al mismo release, pero la imagen fija de ejecución es v0.1
  • La hoja de ruta incluye estructuras internas multihilo de Postgres, pooling de conexiones integrado, mejoras para cargas de trabajo centradas en JSON, experimentos de almacenamiento sin vacuum y guardrails en tiempo de ejecución para SQL generado por IA

Objetivos y compatibilidad de pgrust

  • pgrust es un proyecto para reescribir Postgres en Rust
  • Su objetivo es Postgres 18.3, y coincide con la salida esperada de Postgres en más de 46,000 consultas de regresión
  • Ofrece compatibilidad de disco que le permite arrancar desde un directorio de datos existente de Postgres 18.3
  • El objetivo del proyecto es facilitar cambios más profundos dentro de Postgres
    • Mantener el comportamiento con forma de Postgres
    • Usar las pruebas reales de Postgres como referencia
    • Explorar cambios más profundos del servidor con Rust y programación asistida por IA

Estado actual y limitaciones

  • pgrust todavía no está listo para producción
  • Aún no tiene optimización de rendimiento
  • Las extensiones existentes de Postgres y las extensiones de lenguajes procedurales por lo general aún no son compatibles
    • PL/Python
    • PL/Perl
    • PL/Tcl
  • Algunos módulos contrib incluidos ya fueron portados, y con el tiempo podría lograrse más compatibilidad

Cómo ejecutarlo

  • La demo en WebAssembly se puede probar en https://pgrust.com
  • Para ejecutarlo con Docker se usa la imagen malisper/pgrust:v0.1
    • Usa el cliente psql incluido dentro de la imagen
    • malisper/pgrust:latest actualmente apunta al mismo release
    • La imagen de release fija es v0.1
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1 && until docker exec -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres -c '\q' >/dev/null 2>&1; do sleep 1; done && docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres; docker rm -f pgrust

Compilación desde el código fuente y ejecución

  • En macOS se requieren icu4c, openssl@3 y libpq
brew install icu4c openssl@3 libpq

export LIBRARY_PATH="$(brew --prefix openssl@3)/lib:${LIBRARY_PATH:-}"
export PKG_CONFIG_PATH="$(brew --prefix openssl@3)/lib/pkgconfig:$(brew --prefix icu4c)/lib/pkgconfig:${PKG_CONFIG_PATH:-}"
export PATH="$(brew --prefix libpq)/bin:$PATH"
  • En Debian/Ubuntu se instalan las herramientas de compilación y los clientes de ICU, OpenSSL, LDAP, PAM y Postgres 18
sudo apt-get update
sudo apt-get install -y build-essential pkg-config libicu-dev libssl-dev libldap2-dev libpam0g-dev postgresql-client-18
  • La compilación se realiza con cargo build, especificando el directorio compartido vendored de Postgres 18.3
PGRUST_PGSHAREDIR="$PWD/vendor/postgres-18.3/share" \
cargo build --release --locked --bin postgres
  • El directorio de datos se crea con --initdb de pgrust
target/release/postgres --initdb \
  -D /tmp/pgrust-data \
  -L "$PWD/vendor/postgres-18.3/share" \
  --no-locale \
  --encoding UTF8 \
  -U postgres
  • Al ejecutarlo, se usan junto con la configuración de pila y de I/O síncrona
ulimit -s 65520

RUST_MIN_STACK=33554432 target/release/postgres \
  -D /tmp/pgrust-data \
  -F \
  -c listen_addresses= \
  -k /tmp \
  -p 5432 \
  -c io_method=sync \
  -c max_stack_depth=60000

Pruebas de regresión y resultados de validación

  • Las pruebas de regresión de Postgres se ejecutan con scripts/run-regression
PGRUST_BIN="$PWD/target/release/postgres" \
scripts/run-regression
  • El runner de pruebas usa el --initdb propio de pgrust y los archivos de prueba de Postgres 18.3 incluidos en el repositorio
  • Se necesita el cliente psql de Postgres 18 en el PATH
    • Si está en otra ubicación, configurar PGRUST_PSQL=/path/to/psql
  • El resultado validado del release es que pgrust coincidió con la salida esperada de Postgres en más de 46,000 consultas de regresión

Hoja de ruta e historial del proyecto

  • La hoja de ruta incluye los siguientes puntos

    • Estructuras internas multihilo de Postgres

      • Pooling de conexiones integrado
      • Mejor soporte para cargas de trabajo centradas en JSON
      • Flujos de trabajo rápidos de fork y branching
      • Experimentos de almacenamiento, incluido un diseño sin vacuum
      • Guardrails en tiempo de ejecución para consultas incorrectas y SQL generado por IA
      • Reducción de cambios repentinos a planes de ejecución malos
      • El repositorio actual contiene una implementación más nueva de pgrust que alcanzó el hito de pruebas de regresión
      • La implementación pública anterior está archivada en archive/pre-fabled-2026-06-23
      • Enlaces relacionados de contexto
      • Lanzamiento original de pgrust
      • Actualización de regresión al 67%
      • Hoja de ruta de Four Horsemen
      • La licencia es AGPL-3.0

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Opiniones de Hacker News

  • Soy el autor original. No esperaba que esto llegara aquí. En resumen, he estado experimentando con crear un Postgres mejor usando LLM, y como Postgres ya tiene 30 años, creo que en ese tiempo hemos aprendido mucho sobre bases de datos.
    Muchas de las técnicas útiles para una reescritura también sirven para un rediseño. La nueva versión de pgrust, que todavía no he publicado, actualmente pasa el 100% de las pruebas de regresión de Postgres, implementa un modelo de un hilo por conexión en lugar del modelo de Postgres de una conexión por proceso, y es 50% más rápida que Postgres en cargas transaccionales y unas 300 veces más rápida en cargas analíticas.
    Por ahora es 2 veces más lenta que ClickHouse en clickbench, pero creo que puede llegar a ser más rápida que ClickHouse. Si tienen preguntas, las respondo.

    • Un hilo por conexión casi siempre es la elección correcta desde el punto de vista del rendimiento, pero gracias a que Postgres eligió un proceso por conexión, se pueden cargar extensiones sospechosas con bastante libertad. En el peor de los casos, muere solo ese proceso, no toda la base de datos. Sería bueno tener un punto medio en el que, aunque una extensión provoque un error de segmentación, mueran solo algunas conexiones y no todo el sistema.
    • Una mejora del 50% en OLTP me resulta un poco sospechosa. No quiero acusar sin fundamento, y yo también hago afirmaciones de benchmarks con frecuencia, pero aunque sé que se usó un benchmark estándar, algo me hace ruido.
      Tal vez en algún lugar se haya roto MVCC con una concesión que no podría entrar en producción. Vi que pasa las pruebas de regresión. ¿Está activado fsync? Tengo entendido que las pruebas de regresión no detectan bien patrones de E/S malos. Aun así, parece un proyecto interesante.
    • Me da curiosidad el trasfondo real y la experiencia en Postgres y en bases de datos en general. Al final, quiero saber si sabe exactamente lo que está haciendo o si hay alguna enorme mina antipersona oculta que todavía no conoce.
    • Parece que era más un experimento que un lanzamiento de producto, y que alguien lo empujó bajo el reflector de HN. Me pregunto si esto es un experimento para ver hasta dónde se puede llegar programando con LLM, o si primero lo hicieron y luego están viendo cuánto del código escrito por el LLM se puede aceptar.
    • Que sea unas 300 veces más rápido que Postgres en cargas analíticas y 2 veces más lento que ClickHouse, ¿significa que almacena los datos en un formato orientado a columnas? ¿O usa tanto orientación a filas como a columnas?
      Estoy creando δx, algo parecido pero distinto. Es una extensión de Postgres que almacena datos comprimidos orientados a columnas dentro de tablas normales de Postgres, por lo que la replicación, la recuperación ante fallos, pg_dump, etc. siguen funcionando tal cual: https://github.com/xataio/deltax
      Actualmente, en un solo nodo, es 30–40% más lento que ClickHouse. Acaban de aceptar el PR para agregarlo a clickbench, así que aquí se puede ver la comparación: https://benchmark.clickhouse.com/#system=+liH|_etx|gQ|saB&ty...

  • No termino de entender este tipo de reescrituras. Normalmente las impulsa una sola persona, lo que tiende a convertirse en un punto único de falla, y se hacen en muy poco tiempo, así que es difícil creer que se haya adquirido la disciplina necesaria para construir el proyecto de forma sostenida.
    Tampoco parece muy probable que se mantenga a mediano o largo plazo. Quien quiera contribuir también tendría que pagar costos de tokens. Es porque mantener proyectos así sin IA se está volviendo cada vez más difícil. ¿Habrá alguien que quiera poner esto en producción? No tiene mucho sentido.

    • No es solo una reescritura simple; también hay mejoras. Hice algo parecido por diversión, porque quería ver si se podían mejorar partes del diseño antiguo y, en especial, cosas que la gente de PostgreSQL decía que “no se podían hacer de otra manera”. En realidad sí se pueden hacer de otra manera.
      No lo pondría en producción, pero aprendí mucho sobre las entrañas de las bases de datos. Incluso en la era de los LLM, para entretener la mente implementamos funcionalidades de base de datos sin LLM en nuestra base de datos de producción. Ahora estoy sufriendo con Flexible Paxos; probablemente sigamos usando el viejo, estable y simple Raft, pero de todos modos es interesante.
    • Lo veo como una prueba de concepto interesante. No solo se trata de reescribir PostgreSQL en Rust, sino también de probar las dependencias elegidas, el cambio de modelo de threading y la posibilidad de otros cambios de arquitectura.
      Los LLM son muy buenos para sacar prototipos rapidísimo, y un prototipo funcional puede cerrar muchas conjeturas. No usaría la reescritura de un proyecto enorme como este si no estuviera respaldada por el equipo original o por un grupo considerable equivalente, y si no hubiera una explicación creíble de que igualó o superó la calidad y mantenibilidad del código original.
      En general, creo que usar LLM para lavar licencias es difícil de defender, tanto legal como moralmente. Pero este caso es distinto porque eligieron una licencia más restrictiva. No soy abogado, pero entiendo que legalmente es posible descargar PostgreSQL, hacer s/MIT/AGPL/ y luego distribuirlo. La versión original con licencia MIT sigue existiendo, así que hasta que aparezcan funcionalidades nuevas convincentes, no hay mucha razón para preferir esa versión.
    • No es exactamente lo mismo, pero recrear un modelo 3D a partir de un conjunto de planos existente es mucho más rápido y fácil que crearlo desde cero, porque muchas decisiones ya están tomadas.
    • En un proyecto del tamaño de Postgres, mantenerlo sin IA es prácticamente casi imposible. Si no recuerdo mal, Postgres tiene más de un millón de líneas.

  • Creo que la mejor forma de probar esto sería poner un proxy como PgBouncer delante de una base de datos de producción con mucho tráfico y espejar las consultas simultáneamente al Postgres existente y a la versión en Rust.
    Así se podrían comparar la salida y el rendimiento bajo carga real. Después de dejarlo correr un tiempo, también se podrían comparar las tablas una por una con las de la instancia normal de Postgres.

  • ¿Cómo habría que revisar este tipo de código? Normalmente uno revisa el historial de commits para ver qué hizo la gente y cómo, pero si un LLM genera 7101 commits en menos de un mes, es imposible.
    Incluso mirar solo un día es demasiado [1]. De todos modos, puede que el contenido de los commits tampoco diga demasiado. También me pregunto si hay una forma sencilla de ir al primer commit de un repositorio en GitHub. Explorar el historial de commits se siente bastante engorroso.
    [1] - https://github.com/malisper/pgrust/commits/main/?since=2026-...

    • Estoy trabajando con malisper en pgrust. En proyectos como este, creo que el foco va a pasar de revisar cada commit a revisar las pruebas y el proceso de fuzzing.
      Hay que ir mucho más allá de las pruebas de regresión, aislamiento y fallas de Postgres. Artículo relacionado de danluu: https://danluu.com/ai-coding/
    • github cli tiene un comando para consultar commits con flags de orden ascendente/descendente: https://cli.github.com/manual/gh_search_commits
      La documentación de sintaxis como before x date está aquí: https://docs.github.com/en/search-github/searching-on-github...
      También existe la página de búsqueda avanzada, pero no admite commits con filtro de fecha: https://github.com/search/advanced
      También se puede hacer una búsqueda binaria de la fecha en el widget de búsqueda, y el primer día con commits está aquí: https://github.com/malisper/pgrust/commits/main/?since=2026-...
      Primer commit: https://github.com/malisper/pgrust/commit/22113dc36b02973060...
    • En términos generales, si no existe el historial de prompts y no se puede volver a ejecutar directamente la “compilación” del LLM, es ambiguo si esto es open source. Se siente más cercano a un proyecto de “código fuente publicado” donde se puede leer el código, pero no se tiene acceso al sistema de build.
      Por otro lado, salvo por los mensajes de commit, nunca hemos tenido acceso al proceso mental interno de los desarrolladores humanos, así que decir que un prompt secreto equivale a código fuente privado quizá tampoco sea exactamente lo mismo.
    • Para ir fácilmente al primer commit en GitHub, se puede usar la sintaxis github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2. Es algo como hacer -1, -1 por el commit más reciente y el último commit.
      Ejemplo: https://github.com/malisper/pgrust/commits/?after=3646a73515...
    • No se revisa. No queda otra que confiar en que pasar las pruebas de regresión significa que es totalmente compatible con el original.

  • Es impresionante, pero es un cambio de licencia: de la licencia de PostgreSQL [0] a AGPL [1].
    Me gusta AGPL y creo que es la mejor entre las licencias verdaderamente libres y open source, pero me preocupa si es compatible. Si se reescribió a partir del código fuente original, ¿no debería aplicarse la licencia original? Yo creo que sí. Ha habido una tendencia a reescribir software open source bajo licencias más restrictivas, como coretools en Rust. El hecho de que hayan elegido AGPL parece mucho más ético, pero ¿no habría sido más seguro no cambiarla en absoluto?
    [0] https://www.postgresql.org/about/licence/
    [1] https://github.com/malisper/pgrust?tab=AGPL-3.0-1-ov-file

    • Parece que estás entendiendo al revés la dirección de la restricción. uutils coreutils, que tiene licencia MIT, es menos restrictivo que GNU coreutils, que es GPL, y AGPL es más restrictiva que la licencia de PostgreSQL.
      Distribuir una reescritura con una licencia más restrictiva no viola la licencia de PostgreSQL. Justamente la razón por la que las licencias tipo MIT son menos restrictivas que GPL o AGPL es que permiten relicenciar con una licencia más restrictiva.
    • Si no te gusta la licencia, puedes hacer que un LLM lo “porte” durante unos días y luego ponerle la licencia que quieras. Apparently, parece que hoy en día se hace así.
    • La licencia de PostgreSQL es una variante de la licencia BSD, así que es compatible con (A)GPL.
      Se puede entender así: creas un proyecto (A)GPL vacío y traes la base de código BSD upstream. Los archivos originales upstream siguen bajo su licencia permisiva original, pero el proyecto completo queda regido por (A)GPL, incluyendo los requisitos de atribución de la licencia upstream. GPL permite esos requisitos. Luego puedes agregar tu propio código como AGPL y distribuir la obra combinada como AGPL.
      Si alguien toma solo las partes de tu código que escribiste tú, solo tiene que cumplir con AGPL. Pero si también incluye el código fuente upstream, debe seguir cumpliendo los requisitos de atribución de la licencia upstream.
    • La licencia de Postgres ya es totalmente compatible con AGPL. BSD/MIT es más permisiva.

  • Hay 2664 apariciones de unsafe { y 1835 de unsafe fn. Esto no es seguro en absoluto. No parece una reescritura hecha por alguien que entienda qué está pasando realmente ni cómo habría que rediseñar la arquitectura para aprovechar las ventajas de Rust
    Más bien parece una conversión generada por IA que usa punteros crudos de forma extensiva

    • La mayor parte de los unsafe está encerrada dentro del parser generado al pasar c2rust sobre el parser de Postgres. El parser de Postgres en sí también se genera con yacc/bison, así que se optó por portarlo mecánicamente en vez de llevarlo a Rust idiomático
      Si hay algún unsafe que consideres especialmente grave, estaría bueno que lo señales
    • Todos los proyectos con LLM escritos en Rust se configuran con unsafe=deny. No entiendo por qué nadie prevé este tipo de reacción
    • Bastaría con copiar tal cual este comentario de revisión en el prompt. Unas horas después probablemente dirá “¡corregido!”

  • Creo que hay que distinguir con fuerza entre una reescritura y una reescritura con IA

    • Por ejemplo, la reescritura de TypeScript en Go fue hecha mayormente por humanos y tardó un año en hacerse pública. Esa es la forma en que se reescribe software en el que la gente puede confiar
    • No parece tan simple. Casi el 100% de los proyectos nuevos y ambiciosos probablemente usarán IA en alguna medida. Conozco algunos proyectos con políticas estrictas de no IA, como Zig, pero creo que son una minoría muy pequeña
      Entonces, ¿cuánta IA tiene que usarse para que algo pase a ser una “reescritura con IA”?
    • La reescritura se siente como un área para la que los LLM encajan mejor que los humanos. En su mayoría es trabajo repetitivo simple, y los LLM encajan bien con tareas de traducción. Si no recuerdo mal, la arquitectura Transformer originalmente se inventó para traducción
    • Una reescritura humana sin mantenimiento no es más que un proyecto hobby. No sé para qué se estarían quemando tokens en una reescritura con IA
    • Ahora simplemente pasó a ser una etapa de build

  • Veo muchos de estos proyectos de reescritura que afirman funcionar apoyándose en los tests. Pero lo que hace confiable a software como Postgres o SQLite no son tanto los tests en sí, sino más bien las cicatrices acumuladas en entornos de producción
    La confiabilidad se acumula tras años funcionando en producción

    • Gran parte de una suite de tests enorme son precisamente cicatrices de producción. Porque cada vez que aparece un bug o una regresión, se escribe un test que verifica el comportamiento correcto
      SQLite es un buen ejemplo. Sus enormes tests privados suelen citarse como un factor que dificulta que otros hagan forks. Turso lo logró, pero para garantizar una diligencia equivalente hace falta una empresa. Y, por supuesto, también hacen falta años de operación
    • No es un juicio sobre esta reescritura en particular, pero los tests son una especificación de que el software se comporta correctamente. Si cierto comportamiento no está cubierto por ningún test automatizado, no se puede afirmar que un cambio específico no vaya a romperlo
      Es completamente razonable decir que algo funciona usando la suite de tests existente sin modificar. Cuanto más grande es el proyecto, más cierto me parece. Las cicatrices obtenidas en producción deben documentarse y protegerse en la suite de tests; de lo contrario, esa lección se pierde
      SQLite es famoso por su enorme suite de tests y su amplio fuzzing. Tiene 590 veces más código de tests y scripts que código normal. Fuente: https://sqlite.org/testing.html
    • Entonces habría que hacer que sea fácil devolver esa confiabilidad upstream
      Lo más útil que se puede hacer ahora con una versión convertida por LLM como esta, si pasa todos los tests originales, es ejecutar encima mi suite de tests de aplicación para detectar falta de cobertura de tests en el original
      Si la versión convertida se cae o muestra un mal comportamiento observable, significa que al proyecto real le faltaba algún test de regresión. Si este tipo de proyecto de conversión pudiera ejecutarse de forma segura y sencilla como una línea más en la matriz de integración continua cotidiana, ayudaría mucho más a evitar que upstream rompa algo accidentalmente en futuras actualizaciones
    • Estoy de acuerdo. También estoy de acuerdo con el comentario lateral de que cada vez que aparece un bug o una regresión se escribe un test que verifica el comportamiento correcto
      Pero lo que no se ve en estas reescrituras es qué pasa con los bugs nuevos introducidos por la propia reescritura. Al final, ¿no tienen que pasar por desafíos propios en escenarios del mundo real?
    • También hay otras formas de validar una reescritura. Basta con ejecutar pgrust y postgres juntos y comparar las salidas
      Si conoces casos límite, también los ejecutas; si no, usas un fuzzer o herramientas automatizadas para encontrar entradas interesantes. Cuando encuentras una discrepancia, ese par de entrada/salida se convierte en un caso de prueba. No sé si existe una herramienta así, pero si existe, se la puedes dar a Claude para que la incorpore al ciclo de desarrollo

  • La demo de WebAssembly que corre en el navegador está muy pulida: https://pgrust.com

  • No entiendo por qué tanta negatividad. Veo este tipo de proyectos como interesantes para aprender y explorar enfoques nuevos. ¿Cuál es el problema?

    • Quizá la razón sea esta: se montan sobre una marca ya establecida como Postgres + Rust, pero no hay utilidad práctica ni avances, y falta credibilidad.
      En especial, cuando el título incluye y destaca un nombre con una señal tan fuerte como Postgres, si resulta claramente impráctico por razones como utilidad a corto y largo plazo, confianza social o efectos de red, parece que fácilmente genera rechazo.
    • Es incómodo ver cómo décadas de trabajo se copian con tanta facilidad.
    • Me pregunto qué se aprende exactamente al pedirle a un LLM que lo reescriba.
    • Parece que la gente se siente amenazada al ver que un LLM hace bien tareas para las que creían que se necesitaban sus habilidades y talentos.
      Lo entiendo, pero es una emoción negativa que no es productiva ni del todo racional. Este hilo está lleno de publicaciones que intentan sostener que esto no puede ser bueno, que no debería serlo y que al final seguramente terminará en desastre. Pero el hecho de que esta cosa haya pasado decenas de miles de pruebas sofisticadas acumuladas durante décadas sugiere lo contrario. Es difícil refutarlo.
      Claro, es muy probable que surjan problemas nuevos, pero aun así es un logro impresionante.
    • Me preocupa la calidad. Incluso con una revisión rápida del código, parece tonto. A menos que yo no esté reconociendo algún aspecto genial del código.
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...
      https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...