pgEdge launched Starfleet, a Postgres platform that gives every coding agent its own database branch

Three coding agents fixing the same bug against one Postgres database will overwrite each other's work within the hour. pgEdge launched Starfleet on 2026-09-28, a Postgres cloud whose central move is that every agent gets its own copy-on-write branch of the source database, with its own connection string and its own agent tooling. CEO Phillip Merrick wrote the launch post; The New Stack covered it the same day, quoting a starting price of $25 per month with a 14-day free trial.

A Starfleet branch begins as a copy of the source and then diverges. pgEdge says the branching is done "without any changes to the Postgres storage layer", which separates it from Databricks Lakebase, which runs on Neon and stores Postgres pages in object storage to make branching a metadata operation. pgEdge has not published how its own branching works underneath.

A separate MCP address per branch

Each branch inherits the source database's IP allowlist at creation, and gets its own MCP server address and its own bearer token. An agent configured with the source database's credentials cannot connect to a branch, and an agent configured with the branch cannot reach the source. The tooling ties into git through a .pgedge/link.yaml file at the project root and a pgedge env pull command that writes the branch's DATABASE_URL into the folder's .env. An agent working on a feature branch of the code then connects to the matching database branch without a person passing credentials. Writes require the agent to name the database ID, which is a check against changing the wrong one.

No merge at the end

Starfleet branches do not merge back. Developers handle schema changes using Alembic, Flyway, or another migration tool, so the migration files travel with the code when a feature is merged and run against the source database. Test data stays behind and is deleted with the branch. pgEdge notes that billing starts as soon as a branch is ready to accept connections and continues until it is deleted, so a team running several agents in parallel will probably automate that cleanup.

The MCP server includes pgEdge SafeSession, which the company says prevents an agent with read-only access from changing the database. Starfleet also includes pgEdge's Agentic AI Toolkit for Postgres, which Merrick has described as fully open source and free for all Postgres users, including a RAG API on pgvector and a PostgREST API for browser clients.

The reason for the pitch

pgEdge cites research from IDC and Lenovo reporting that 46% of general AI and agentic prototypes reach production, and that 82% of organisations need hybrid or on-premises environments for AI workloads. Those are the figures pgEdge quotes to explain the deployment story: Starfleet is designed to start on pgEdge's hosted service and later run in a customer's own cloud, or in an air-gapped data centre through pgEdge Enterprise Postgres. One limit noted by The New Stack: pgEdge's current documentation covers branching on the hosted tier only, and the company has not said whether the agent workflow carries over when a database moves into a customer's own environment.

For a shop where agents already run against a shared staging database, the Starfleet decision is whether the per-branch price is less than the time lost to two shared-database failure modes: agents overwriting each other, and agents with production credentials writing where they should not.

Source

• pgEdge: Why We Built pgEdge Starfleet, by Phillip Merrick, 2026-09-28.
• The New Stack: pgEdge's new agent database branches never merge back into the source, by Amanda Caswell, 2026-09-28.