El desarrollo rápido con agentes de inteligencia artificial en la codificación permite lanzar prototipos con agilidad, pero el salto a producción suele encontrarse con obstáculos importantes. Las configuraciones de base de datos que funcionan en fase de desarrollo a menudo no cumplen con las estrictas necesidades de seguridad, cumplimiento normativo y despliegue de las organizaciones.
Con el objetivo de superar ese reto, pgEdge presentó el pasado lunes Starfleet, una plataforma en la nube Postgres que combina la creación de ramas en la base de datos con herramientas específicas para agentes, ofreciendo distintas opciones de despliegue desde el servicio alojado por pgEdge hasta entornos aislados on-premises, todo basado en Postgres comunitario estándar.
Una rama de base de datos para cada agente
La ejecución paralela de múltiples agentes de IA permite que cada uno pruebe distintos enfoques ante una misma tarea. Esto se complica cuando todos operan sobre una sola base de datos compartida. Starfleet resuelve esta dificultad generando para cada experimento su propia rama de base de datos basada en la técnica copy-on-write, sin necesidad de reemplazar la capa de almacenamiento de Postgres por soluciones propietarias o híbridas, según informa pgEdge. 
Como ejemplo comparativo, Databricks utiliza con Lakebase la separación del almacenamiento y computación sobre Neon, lo que optimiza el branching como una operación ligera de metadatos, almacenando las páginas de Postgres en almacenamiento de objetos.
Aunque pgEdge no ha detallado públicamente el funcionamiento interno de su sistema de branching, desde la perspectiva del desarrollador, cada nueva base de datos empieza como una copia del origen y luego se convierte en un entorno completamente independiente donde los cambios no se comparten entre ramas y cada una dispone de sus propias credenciales de conexión.
Esta separación también se aplica en las herramientas para agentes, asignando a cada entorno un servidor MCP y un token de acceso exclusivos. Esto implica que un cliente configurado con credenciales de la base original no puede acceder a las ramas creadas. Además, la lista de direcciones IP permitidas, heredada del origen, se fija durante la creación y no puede modificarse.
Cuando un agente requiere acceso desde una nueva IP, el desarrollador debe primero añadirla a la lista del origen y luego generar una nueva rama de base de datos, que partirá de los datos iniciales, sin incluir cambios realizados en ramas anteriores.
Integración con flujos de trabajo Git
La vinculación de una carpeta de proyecto a través de la interfaz de línea de comandos permite guardar el ID de la base o rama en el archivo .pgedge/link.yaml. El comando pgedge env pull añade automáticamente la URL de conexión (DATABASE_URL) al archivo .env del proyecto. Así, un agente que trabaje sobre una característica concreta puede conectarse a la rama correspondiente sin necesidad de transmisión manual de credenciales.
La mayoría de las consultas de lectura utilizan por defecto la base enlazada, aunque para acciones de escritura el agente debe especificar explícitamente el ID de la base, añadiendo una barrera para evitar modificaciones inesperadas en ramas erróneas.
No existe un proceso de fusión automática entre las ramas al final de un trabajo. Los cambios en el esquema se gestionan con las herramientas habituales para migraciones, como Alembic o Flyway, integrándolos junto con el código en los sistemas de control de versiones. Los datos de prueba permanecen únicamente en la rama del agente y se eliminan al borrar dicho entorno.
Es recomendable limpiar estas ramas temporales una vez finalizada la experimentación, ya que cada base tiene un límite de ramas y la facturación se activa en cuanto la rama está lista para aceptar conexiones hasta que se elimina. Equipos con múltiples agentes concurren probablemente automatizarán estas tareas. De manera paralela, empresas como Yugabyte abordan este problema desde la gestión de flotas ofreciendo plataformas que permiten que los agentes realicen provisión, branching, escalado, migración y cierre a través de MCP.
Control de acceso protegido mediante MCP
Starfleet incluye el Agentic AI Toolkit para Postgres desarrollado por pgEdge, un conjunto de herramientas totalmente open source y gratuito para usuarios de postgres, según su CEO Phillip Merrick. Este toolkit incorpora un servidor MCP que habilita la conexión directa de agentes con la base de datos, además de APIs complementarias como RAG para recuperar contenido mediante pgvector y PostgREST para acceso directo desde clientes de navegador, empleadas por constructores de apps como Lovable.
El servidor MCP cuenta con la funcionalidad pgEdge SafeSession, que impide que agentes con acceso sólo de lectura puedan modificar datos, reforzando la seguridad junto a las credenciales individuales y la lista de IPs permitidas heredada en cada entorno.
Del prototipo a la producción aislada
pgEdge cita estudios de IDC y Lenovo que señalan que solo el 46% de los prototipos de IA general y agentes IA llegan a producción, mientras que el 82% de las organizaciones requieren entornos híbridos o locales para ejecutar sus cargas de IA.
Starfleet nace para que los desarrolladores inicien proyectos en la infraestructura alojada de pgEdge y luego puedan migrar la misma base de datos a su propia nube o a instalaciones on-premises, incluyendo entornos aislados air-gapped con pgEdge Enterprise Postgres y con posibilidades de escalar a clusters multi-región con alta disponibilidad.
No obstante, la documentación actual de pgEdge sólo detalla el branching para el nivel alojado y no aclara si estos flujos de trabajo para agentes se mantendrán al trasladar una base a infraestructuras propias.
El plan inicial de Starfleet tiene un coste a partir de 25 dólares mensuales, con una prueba gratuita de 14 días.
