Revisado por Iván Quintas, Editor de IA News
PGX: miles de bases Postgres desechables para agentes, en Rust
PGX mete miles de bases compatibles con Postgres en un solo proceso para agentes, CI y previews. Qué es, qué cifras da el repo y por qué no es para producción.
“Postgres for AI agents. In Rust”, anunciaba Alex Shapalov en X. Su proyecto, PGX, mete miles de bases de datos compatibles con Postgres en un solo proceso, para que cada agente, test o rama tenga la suya sin levantar un contenedor. La idea es buena. Pero conviene leer el README antes que el tuit: ni las cifras coinciden ni es Postgres en sentido estricto.
Qué hace
Un servidor Postgres normal reserva memoria por cada base y cada conexión. PGX va al revés: un proceso, un hilo por conexión y bases que apenas ocupan mientras no se usan.
- Bases separadas por nombre, roles y límites de memoria y conexiones, con un cgroup de Linux como último respaldo.
- Clonación copy-on-write con ZFS: copias una plantilla y solo ocupa espacio lo que cambia.
- Compatible con el ecosistema: según el README, pasa 36 de 36 pruebas con Rails 8.1, Django 5.2, Prisma 6, SQLAlchemy 2 y node-postgres.
El caso de uso es claro: un agente que necesita una base limpia para probar una migración, tirarla y empezar de nuevo.
No es el Postgres de siempre
PGX no es un fork del código C de PostgreSQL. Es una reimplementación en Rust basada en pgrust, de Michael Malis, que sigue de cerca a Postgres 18.6: misma arquitectura, formatos, catálogo y mensajes de error. Pasa 219 de 231 tests de regresión byte a byte; los otros 12 solo difieren en el texto de EXPLAIN.
La parte más llamativa, reescribir Postgres en Rust, es de pgrust. Lo que aporta PGX es la densidad, el ciclo de vida de las bases y las ramas.
Y una consecuencia práctica: no carga extensiones en C. Trae los módulos contrib integrados, pgvector entre ellos, pero nada de PL/Python, PL/Perl ni PL/Tcl.
Las cifras: el tuit y el README no dicen lo mismo
El tuit promete 1.000 bases en 659 MB, unos 0,7 MB por base y clonar una base de 674 MB en 85 ms. Ninguna de esas cifras aparece en el README. Las del repo, medidas en un VPS de 4 vCPU y 8 GB:
| Medida | PGX | PostgreSQL 18 |
|---|---|---|
| 1.000 bases inactivas | 128-155 MB | - |
| Por base sin tocar | ~70 KB | 16,6 MB |
| Por base ya consultada | ~128 KB | - |
| Rama de una plantilla de 10 GB | 674 ms | - |
| Consultas cortas | 0,05-0,15 ms más lentas | referencia |
| Escaneos grandes | 1,5-2,2 veces más lentos | referencia |
Son pruebas del propio proyecto, sin auditoría externa. Pero el mensaje es coherente: mucho más ligero en reposo, algo más lento trabajando.
La letra pequeña
Beta. La única versión es la v0.1.0-beta.1, del 19 de octubre. El repo se creó el 8 de octubre y tiene 177 estrellas.
No es para producción, y lo dice el propio proyecto: corre con fsync = off, no sobrevive a caídas y no tiene alta disponibilidad ni PITR. Además, al ser un solo proceso, un fallo tumba todas las bases a la vez.
Licencia AGPL-3.0. Gratis y libre, sí, pero copyleft fuerte: si lo modificas y lo ofreces como servicio, tienes que publicar tus cambios.
Ojo con el nombre. No tiene nada que ver con pgx (hoy pgrx), el framework de tcdi para escribir extensiones de Postgres en Rust.
Merece la pena si…
- Tus agentes o tu CI crean y destruyen bases constantemente y los contenedores se te comen la RAM.
- Quieres una base por pull request o por preview sin pagar una instancia por cada una.
- No dependes de extensiones en C.
Para agentes que trabajan en paralelo, encaja con herramientas como Orca y sus worktrees aislados.
¿Te ha servido? Márcanos como fuente preferida en Google y verás antes nuestros artículos en Noticias destacadas, AI Overviews y AI Mode.
📎 Fuente original: GitHub / pgrundev ↗