Postgres en Rust: compatibilidad real y costo

Un proyecto que reescribe Postgres en Rust y ya pasa 100% de la batería de regresión no es una curiosidad de GitHub para guardar en bookmarks y olvidarla. Es una señal técnica seria. Si una implementación alternativa logra comportarse como PostgreSQL en sus pruebas más sensibles, entonces ya no estás hablando solo de “si compila”, sino de compatibilidad real, riesgo operativo y costo de mantenimiento.

La discusión importa porque Postgres no es una base de datos cualquiera. Está en producción en startups, bancos, SaaS, ERPs y sistemas internos en toda Latinoamérica. Cuando algo toca el motor, el parser, el planner o la semántica de SQL, el cambio deja de ser académico. El proyecto pgrust pone sobre la mesa una pregunta incómoda: ¿cuánto vale reescribir una base madura si el objetivo final sigue siendo exactamente el mismo comportamiento?

Qué significa pasar 100% de las pruebas de regresión

Pasar toda la suite de regresión de Postgres no significa que ya tengas una copia lista para producción en cualquier carga. Sí significa algo muy concreto: el sistema responde como Postgres en un conjunto enorme de casos que históricamente capturan comportamiento esperado, bordes raros y decisiones de compatibilidad acumuladas durante años.

En bases de datos, eso pesa más de lo que parece. Un cambio pequeño en NULL handling, en el orden de ejecución de una consulta o en una conversión de tipos puede romper aplicaciones que no controlas del todo. Si tu backend depende de ORMs, reportes SQL escritos a mano y jobs batch, la compatibilidad semántica vale más que una demo bonita.

El dato de “100% de los regression tests” no resuelve todo, pero sí cambia el nivel de conversación. Ya no estás comparando un prototipo con un motor completo, sino una implementación que al menos logró reproducir el comportamiento observable que Postgres considera crítico para no romperse a sí mismo.

Por qué la regresión importa más que una demo

Una demo suele mostrar una tabla, un SELECT 1, un INSERT y listo. La regresión, en cambio, te obliga a enfrentar décadas de decisiones acumuladas. Ahí aparecen casos como:

• conversiones de tipos que parecen obvias, pero no lo son
• subconsultas con resultados sensibles al planner
• errores que deben dispararse con mensajes y códigos específicos
• funciones agregadas con comportamiento borde
• compatibilidad con SQL que muchas apps ya dan por sentado

Si una base reescrita pasa esa batería, el mensaje es claro: el trabajo no fue solo replicar sintaxis, sino comportamiento. Y en un motor de base de datos, ese es el tipo de compatibilidad que reduce sorpresas en producción.

Lo que todavía no te dice esa cifra

También hay que ser honestos. Pasar regresión no equivale a ganar en rendimiento, observabilidad, extensibilidad o ecosistema. Tampoco te dice cómo se comporta bajo concurrencia real, con millones de filas, WAL intensivo, replicación, vacuum, checkpoints o recuperaciones después de un crash.

En otras palabras, la suite te dice que la compatibilidad básica y muchos bordes están alineados. No te dice todavía si el proyecto está listo para reemplazar instalaciones con años de tuning, extensiones y carga mixta. Ese salto exige otras métricas, no solo tests.

Rust cambia el costo de mantener un motor

Rust aparece en esta historia por razones bastante prácticas. Si vas a escribir un motor complejo, el lenguaje importa. Memoria segura, ownership explícito y menos espacio para bugs clásicos de C no son un detalle menor cuando tu software administra datos persistentes.

PostgreSQL está escrito principalmente en C. Eso no es un defecto automático, pero sí implica una superficie de riesgo conocida: punteros, lifetimes manuales, errores de memoria y una carga grande de revisión humana. Rust promete reducir una parte de ese costo, aunque no elimina la complejidad del dominio. Un motor de base de datos sigue siendo un motor de base de datos.

La pregunta real no es si Rust es “mejor” en abstracto. La pregunta es si, en un proyecto de esta clase, te ayuda a mover el costo desde bugs de memoria hacia complejidad de diseño, pruebas y arquitectura. Eso puede ser una mejora neta, pero no gratis.

Memoria segura no significa sistema simple

Es tentador pensar que Rust resuelve gran parte del problema. En la práctica, solo cambia la naturaleza del problema. Ya no peleas tanto con segfaults y use-after-free, pero sigues lidiando con:

• concurrencia y locks
• estructuras de datos de alto rendimiento
• compatibilidad con SQL y sus bordes
• persistencia duradera y recuperación
• costos de abstracción en rutas críticas

Eso importa porque una base de datos no falla solo por memoria. También falla por decisiones de diseño, por I/O mal gestionado, por algoritmos ineficientes o por una semántica que no coincide con lo que esperan tus aplicaciones.

El costo de reescribir algo maduro

Reescribir una base de datos madura tiene un costo oculto que suele subestimarse: cada comportamiento heredado es una promesa. Postgres no solo ejecuta SQL. También conserva compatibilidad con herramientas, extensiones, clientes y hábitos de uso. Si cambias demasiado, dejas de ser Postgres para convertirte en otra cosa.

Por eso este tipo de proyecto es interesante y difícil al mismo tiempo. Si copias demasiado poco, rompes compatibilidad. Si copias demasiado, heredas buena parte de la complejidad original. El margen para innovar sin romper nada es más pequeño de lo que parece.

Compatibilidad: el verdadero campo de batalla

La compatibilidad no se mide solo por si una consulta funciona. Se mide por si funciona igual, con los mismos errores, el mismo orden de resultados cuando importa, y el mismo comportamiento en casos raros. Para equipos que usan Postgres como dependencia invisible, eso es lo que define si una migración es viable o no.

En Latinoamérica esto pega fuerte. Muchas empresas no tienen equipos grandes de plataforma. Tienen dos o tres personas de backend que además mantienen infraestructura, reportes y pipelines. Para ellas, cambiar de motor de base de datos no es una decisión estética. Es una operación con costo real, horas de validación y riesgo de caída.

Por eso el hecho de pasar regresión es relevante: reduce incertidumbre. No la elimina, pero ayuda a trazar una línea entre “esto parece Postgres” y “esto se comporta como Postgres en un conjunto serio de casos”.

Compatibilidad SQL vs compatibilidad operativa

Hay dos capas que conviene separar:

1. Compatibilidad SQL: consultas, tipos, funciones, errores, planner.
2. Compatibilidad operativa: backups, replicación, monitoreo, extensión, tooling, migraciones.

Un motor puede hacer bastante bien la primera y quedarse corto en la segunda. Y para producción, la segunda suele ser la que más duele. Porque no solo tienes que leer y escribir datos, también tienes que operarlos durante meses o años sin sorpresas.

Un ejemplo práctico

Imagina un SaaS de facturación en Ecuador que usa Postgres con un ORM, jobs nocturnos y algunos reportes SQL manuales. Si cambias de motor y una consulta agrega filas en distinto orden, quizá el problema no sea visible en el dashboard principal. Pero sí puede romper un export, una conciliación o un proceso que asume una semántica concreta.

Ese tipo de fallos no se detecta con una prueba feliz. Se detecta con regresión, carga real y uso prolongado. Por eso un proyecto que pasa la suite completa merece atención, pero no una adopción impulsiva.

Rendimiento: lo que sí puedes medir y lo que todavía no

El rendimiento es el lugar donde muchos proyectos alternativos se desinflan. Pasar tests no implica ser rápido. A veces un motor correcto termina siendo impráctico por latencia, uso de memoria o throughput insuficiente.

En el caso de una reescritura en Rust, hay razones para ser optimista y razones para esperar datos. Rust puede ayudar a evitar overheads de seguridad en runtime, pero también puede introducir complejidad en abstracciones si el diseño no está muy afinado. El lenguaje no te regala performance por sí solo.

Si quieres evaluar este proyecto de forma seria, necesitas pensar en tres niveles: consultas simples, cargas mixtas y operación sostenida. La suite de regresión cubre compatibilidad. El benchmark debe cubrir el resto.

Qué métricas mirar primero

Si tú fueras a probar algo así en un entorno controlado, estas métricas te darían una primera foto útil:

• latencia p50, p95 y p99 en SELECT, INSERT y UPDATE
• TPS bajo concurrencia moderada y alta
• uso de memoria por conexión y por proceso
• tiempo de arranque y recuperación
• comportamiento en consultas con joins y agregaciones

No necesitas 40 gráficos para empezar. Con 5 o 6 métricas bien elegidas ya puedes detectar si el motor compite o si solo pasa tests.

Tabla comparativa de evaluación inicial

Qué aprendemos si un Postgres en Rust funciona

Si un Postgres reescrito en Rust logra compatibilidad alta, la lección no es “vamos a reescribir todo”. La lección es más incómoda: gran parte del valor de una base madura está en su comportamiento acumulado, no solo en su código fuente. Ese comportamiento se puede reproducir, pero cuesta mucho.

Eso abre una conversación útil para equipos de producto e infraestructura. A veces el problema no es que Postgres sea viejo. El problema es que cualquier reemplazo tiene que igualar años de decisiones, y eso requiere tiempo, disciplina y una definición muy clara de qué significa “compatible”.

También obliga a mirar el costo de oportunidad. Cada hora invertida en reescribir un motor es una hora que no va a features del negocio, observabilidad, automatización o hardening del stack actual. Si no hay una ganancia clara en seguridad, mantenimiento o rendimiento, la reescritura puede convertirse en una deuda nueva.

Cuándo sí tendría sentido apostar por algo así

Hay escenarios donde una base en Rust sí puede tener sentido:

• equipos que priorizan seguridad de memoria por encima de compatibilidad total con el ecosistema existente
• productos nuevos que necesitan un motor pequeño, controlado y auditable
• casos donde el aprendizaje técnico o la investigación justifican el esfuerzo
• sistemas embebidos o especializados donde el stack completo se controla de punta a punta

Fuera de eso, el costo sube rápido. Si ya dependes de extensiones, replicación madura y tooling estándar, el camino de migración se vuelve largo.

Cuándo no conviene ni mirar la idea

No te conviene si tu principal problema es otro. Por ejemplo:

• necesitas reducir costos ya, no en seis meses
• tu equipo no tiene capacidad para validar un motor nuevo
• dependes de extensiones específicas de Postgres
• tu operación ya está estable y el riesgo de cambio supera el beneficio

En esos casos, optimizar lo que ya tienes suele dar más retorno que perseguir una reescritura completa.

Tabla resumen

La mejor lectura de este experimento es sobria. No estamos ante una excusa para abandonar Postgres ni ante una rareza sin valor. Estamos ante una prueba fuerte de que una base de datos madura puede reimplementarse con un lenguaje distinto y aun así respetar una compatibilidad muy exigente.

Para ti, como lector técnico, la pregunta útil no es si esto “reemplaza” a PostgreSQL. La pregunta es otra: ¿qué tan caro es mantener la confianza que ya te da un motor maduro, y qué tendrías que ganar para justificar empezar de cero?

Eso es lo que hace interesante a pgrust. No porque prometa magia, sino porque obliga a medir con más honestidad el costo real de reinventar una base de datos que ya funciona.