pgEdge lanza Starfleet, ramas de Postgres por agente que no vuelven al origen
La plataforma da a cada agente de codificación su propia rama copy-on-write sobre Postgres comunitario, con servidor MCP y token propios por entorno y sin merge entre bases.
pgEdge ha presentado Starfleet, una plataforma gestionada que corre sobre Postgres comunitario y da a cada agente de codificación su propia rama copy-on-write de la base de datos. Varios agentes pueden atacar el mismo problema en paralelo sin compartir estado, y cada experimento queda aislado del origen: los cambios no viajan de una rama a otra y cada una tiene sus propios datos de conexión.
El detalle que importa a quien administra esto es cómo se separa el acceso. Cada entorno hereda la lista de IP permitidas de la base origen en el momento de crearse, y esa lista no se puede tocar después. Si un agente necesita entrar desde una dirección nueva, hay que añadirla a la del origen y crear otra rama, que arranca con los datos del origen y ninguno de los cambios de la rama anterior. En el plano de los agentes, cada entorno tiene su propia dirección de servidor MCP y su bearer token, así que un cliente configurado con las credenciales del origen no conecta.
pgEdge no ha explicado cómo implementa el branching por dentro. La comparación con Databricks Lakebase es inevitable: allí el almacenamiento vive en object storage y separar cómputo y almacenamiento convierte la rama en una operación de metadatos; pgEdge dice que no sustituye la capa de almacenamiento de Postgres por nada propietario ni semi, pero no ha enseñado el mecanismo.
Enlace con el proyecto y nada de merge
El CLI guarda el identificador de base de datos o de rama en .pgedge/link.yaml al enlazar una carpeta del proyecto, y pgedge env pull añade su DATABASE_URL al .env. Un agente que trabaja en una feature conecta con el entorno que le corresponde sin que nadie le pase credenciales a mano. Los comandos de lectura tiran del enlace; con una rama enlazada, solo los de conexión apuntan a ella y las escrituras exigen indicar el ID de base de datos, lo que añade una comprobación extra contra el fallo de tocar la base equivocada.
No hay merge de bases al final. Los cambios de esquema se siguen gestionando con Alembic, Flyway o lo que ya use el equipo, no con algo propio de Starfleet: si el trabajo se fusiona, los ficheros de migración viajan con el código y se ejecutan contra la base origen. Los datos de prueba se quedan atrás y se borran junto con la base del agente. Conviene automatizar esa limpieza, porque cada base tiene un límite de ramas y la facturación arranca en cuanto la rama acepta conexiones y sigue hasta que se elimina.
Starfleet incluye el Agentic AI Toolkit de pgEdge, que su consejero delegado Phillip Merrick ha descrito como totalmente open source y gratuito para cualquier usuario de Postgres. Trae un servidor MCP para que los agentes conecten con la base, una API RAG sobre pgvector para recuperar contenido alojado en Postgres y una API PostgREST que da acceso directo a clientes de navegador. El servidor MCP incorpora SafeSession, que según la empresa impide que un agente con permisos de solo lectura modifique la base.
Del alojado al air-gapped
pgEdge cita datos de IDC y Lenovo: solo el 46% de los prototipos de IA general y agéntica llegan a producción, y el 82% de las organizaciones necesita entornos híbridos o en sus propias instalaciones. Starfleet permite empezar en el alojamiento de pgEdge y llevarse la misma base al cloud del cliente o a un centro de datos aislado mediante pgEdge Enterprise Postgres, con escalado a clústeres multirregión en alta disponibilidad. El asterisco: la documentación actual cubre el branching solo en la capa gestionada, y la compañía no ha dicho si esos flujos de agentes funcionarán igual cuando la base se mueva a instalaciones del cliente. El precio arranca en 25 dólares al mes con 14 días de prueba.
El hueco que ataca Starfleet es real: los agentes crean entornos de base de datos a un ritmo que ninguna herramienta de migración clásica gestiona bien, y las alternativas no escasean. Databricks ataca el problema desde el almacenamiento y Yugabyte expone aprovisionamiento, ramas, escalado, migración y desmontaje a los agentes por MCP. La pregunta abierta es si el aislamiento por rama sobrevive al salto al centro de datos del cliente, que es justo donde muchas organizaciones dicen que necesitan desplegar.
