pgEdge’s agent database branches end without a merge, and that’s by design

AI coding agents can get an application running quickly, but taking that prototype into production is another problem. The database setup that works during development may not meet an organization’s security, compliance, or deployment requirements.

On Monday, pgEdge launched Starfleet, a Postgres cloud platform designed to close that gap, pairing database branching and agent tooling with deployment options ranging from pgEdge’s hosted service to air-gapped on-premises environments — all on standard community Postgres.

A database branch per agent

Running multiple coding agents in parallel lets each one try a different approach to the same problem. That gets especially tricky when they’re all working against the same database, so Starfleet gives each experiment its own copy-on-write branch without, pgEdge says, replacing Postgres’ storage layer with a proprietary or semi-proprietary alternative.

Starfleet gives each experiment its own copy-on-write branch without replacing Postgres’ storage layer with a proprietary or semi-proprietary alternative.

Databricks takes a different approach with Lakebase. It runs on Neon, where separating storage from compute makes branching a cheap copy-on-write metadata operation, with Postgres pages stored in object storage.

pgEdge hasn’t said how its branching system works. From the developer’s side, a new database starts as a copy of the source and then becomes its own isolated environment. Changes don’t move between the two, and each has its own connection details.

That separation carries into the agent tooling, with each environment getting its own MCP server address and bearer token, so a client configured with the source database’s credentials won’t be able to connect. It also inherits the source’s IP allowlist at creation, which can’t be changed afterward.

If an agent later needs access from a new address, developers must add it to the source database’s allowlist and create a new database branch, which starts from the source’s data and none of the old branch’s changes.

Linking branches to Git workflows

Linking a project folder through the CLI saves the database ID, or a branch ID, in .pgedge/link.yaml, while pgedge env pull adds its DATABASE_URL to the folder’s .env. An agent working on a feature can then connect to the matching database environment without someone manually passing it credentials. Most read commands automatically use the linked database, though with a branch link only the connection commands point at the branch, while writes require the agent to specify a database ID, adding an extra check against changing the wrong one.

There’s no database merge at the end. Developers handle schema changes the same way they already do, using tools like Alembic or Flyway rather than something built into Starfleet. If the work gets merged, the migration files go with the code and run against the source database. Test data stays behind and is deleted with the agent’s database.

There’s a practical reason to clean up those environments when an experiment is over, since each database can have a branch limit and billing starts as soon as one is ready to accept connections and continues until it’s deleted. Teams running several agents in parallel will probably want to automate that cleanup. Yugabyte is tackling a similar problem from the fleet side with a platform that exposes provisioning, branching, scaling, migration, and teardown to agents through MCP.

Developers handle schema changes the same way they already do, using tools like Alembic or Flyway rather than something built into Starfleet.

MCP access with guardrails

Starfleet ships with pgEdge’s Agentic AI Toolkit for Postgres, which pgEdge CEO Phillip Merrick has described as fully open source and free for all Postgres users. The toolkit includes an MCP server that lets coding agents connect directly to the database. It also includes a RAG API that uses pgvector to retrieve content stored in Postgres, plus a PostgREST API that gives browser clients direct database access, which is an approach used by Lovable and similar app builders.

The MCP server includes pgEdge SafeSession, which the company says prevents an agent with read-only access from changing the database. It works alongside the separate credentials and IP allowlist each database environment inherits.

The MCP server includes pgEdge SafeSession, which the company says prevents an agent with read-only access from making changes to the database.

From prototype to air-gapped production

pgEdge cites IDC and Lenovo research finding that only 46% of general AI and agentic AI prototypes reach production and that 82% of organizations need hybrid or on-premises environments to deploy AI workloads.

Starfleet is designed to let developers start on pgEdge’s hosted infrastructure and later run the same database in their own cloud or on-premises, including air-gapped deployments through pgEdge Enterprise Postgres, with the option to scale to highly available multi-region clusters.

One limitation, however: pgEdge’s current documentation covers branching only for the hosted tier, and the company hasn’t said whether those agent workflows will carry over when a database moves into a customer’s own cloud or data center.

Starfleet starts at $25 per month with a 14-day free trial.

The post pgEdge’s agent database branches end without a merge, and that’s by design appeared first on The New Stack.