One Agent, One Database: Fixtures and Seed Data for Parallel Work

Schema-per-branch means one physical database server, one namespace per agent. Agent A gets agent_a, agent B gets agent_b, and each connection string includes a search_path or schema option so every unqualified table name resolves inside that namespace. Migrations then run against separate sets of tables and cannot alter each other.

A minimal setup on PostgreSQL looks like this:

# one schema per agent, created before the agent starts
AGENT=agent_a
createdb --host=db.internal --owner=app parallel_dev
psql --host=db.internal -d parallel_dev -c "CREATE SCHEMA IF NOT EXISTS $AGENT AUTHORIZATION app;"

# point the agent's environment at its namespace
export DATABASE_URL="postgres://[email protected]:5432/parallel_dev?options=-csearch_path%3D$AGENT"

From the agent's point of view it is the only tenant. Migration tools write schema_migrations inside agent_a, seed scripts fill agent_a.orders, and teardown is a single DROP SCHEMA agent_a CASCADE. The cost is one CREATE SCHEMA per task and one drop at the end, which is negligible next to the setup time of a dependency install.

Two caveats decide whether this technique fits. First, schema-per-branch shares the server, so a heavy query from one agent still competes for CPU and connections with the others; keep a connection limit per schema and watch memory as the trigger.dev team warns when they describe per-worktree services multiplying (Trigger.dev). Second, extensions and roles are cluster-wide, so an agent that needs CREATE EXTENSION must run it once as an administrator rather than inside its own schema. If your application hardcodes schema names in SQL, or you need isolated storage and connection limits, move to a database-level branch instead, either through PostgreSQL's template-database copy or a managed branching service (SpecStory).

The fastest reset is the one that never touches disk. Wrap each test in a transaction, run it, then roll back. One team replaced per-test truncation of more than 20 tables with rollback and reported their 447-test suite falling from 245.87 seconds to 2.84 seconds (dev.to). The old approach paid roughly 40 to 60 milliseconds per test in truncate operations, sequence resets and connection overhead; rollback costs a few milliseconds of memory work.

The mechanics matter more than the number. Setup that loads schema and reference data should run outside the transaction, once, so it is not repeated per test. Only the test body runs inside it. Teardown that clears caches runs after the rollback, because the transaction that the test saw is already gone. Spring's test framework does exactly this declaratively: a @Transactional test is rolled back by default, and method-level lifecycle hooks such as @BeforeEach run inside the test-managed transaction while class-level hooks do not (Spring Framework).

Rollback has hard limits, and knowing them prevents silent false positives:

• Code under test that commits. If the application opens its own transaction and commits, the outer rollback cannot undo it. Spring's documentation warns that propagation settings other than REQUIRED or SUPPORTS behave unexpectedly in test-managed transactions, and that preemptive timeouts run the test in a new thread where the transaction is not visible, so writes get committed instead of rolled back (Spring Framework).
• Background jobs and queues. A worker that picks up a job on another connection writes outside your transaction.
• Anything testing the commit itself. Migration tests, constraint checks after commit, and end-to-end flows need a real reset.

For those cases, drop the schema or re-copy the database from a seeded template, which is the same pattern used to give each task a disposable database built from a parent filled by a seed script (SpecStory).

A fixture is a named data set with a purpose. "User with expired card" tells a reviewer and an agent what the test assumes; "user_8391" does not. Named fixtures earn their keep in parallel runs because two agents can each insert customer_with_expired_card into their own schema without guessing at ids or counts.

Keep fixtures as code in version control, one file per story, and load them by name. A practical layout:

fixtures/
  customers.yaml
  catalog.yaml
  orders_expired_card.yaml
  orders_partial_refund.yaml

# load only what a test declares, inside the test's schema
fixtures.load("customers", "orders_expired_card")

Three rules keep named fixtures from becoming a second database:

1. Fixed, readable identifiers. Assign primary keys explicitly in the fixture file (customer 1001, order 5001) so assertions can name rows instead of querying for them. Explicit ids also make failure output legible when five agents' logs are interleaved.
2. One story per fixture. A fixture that seeds customers, products, carts and refunds couples every test that touches any of them. Small fixtures compose; large ones rot.
3. Fixtures are additive, tests are not. A test may add rows on top of a fixture, but it never edits the fixture. If a test needs different starting data, that is a new fixture, not a mutation of the old one.

Named fixtures also solve the review problem that parallel agents create. When three agents produce diffs, a fixture name in a test file tells the reviewer which scenario the agent believed it was covering, which is exactly the kind of intent a diff of code alone does not carry (Augment Code).

A reset script should be boring: drop the namespace if it exists, create it, run migrations to head, load the base fixture set. The same script runs on a developer laptop, in the agent sandbox and in CI, so a migration that fails for one agent fails identically for all of them.

#!/usr/bin/env bash
set -euo pipefail
SCHEMA="${1:?usage: reset.sh <schema>}"

psql "$ADMIN_URL" -v ON_ERROR_STOP=1 <<SQL
DROP SCHEMA IF EXISTS "$SCHEMA" CASCADE;
CREATE SCHEMA "$SCHEMA" AUTHORIZATION app;
SQL

export DATABASE_URL="${BASE_URL}?options=-csearch_path%3D${SCHEMA}"
migrate up
seed --fixture customers --fixture catalog

Three habits make resets trustworthy at parallel scale. First, version the reset separately from application code only if you must; the most common failure is a reset script that drifts from the migrations and seeds a column that no longer exists. Second, reset at the start of a task, never at the end, so a crashed agent cannot leave a half-cleaned schema that the next agent inherits. Third, delete the schema and the worktree in the same cleanup step, the discipline that keeps branches from accumulating as orphans (database branching notes).

Isolation of the database is not the same as isolation of the environment. An agent that can read your .env can reach the production connection string regardless of which schema it is supposed to use. Sandboxing guidance is blunt about the blast radius: a coding agent with filesystem and shell access is an execution environment, and the goal is to bound what it can touch when it is wrong, not to assume it never will be (Penligent). Production credentials, cloud keys and deploy hooks do not belong in any workspace an agent can write to, which is the central argument for keeping agents in an isolated runtime rather than on a laptop with broad permissions (Robert Brennan, OpenHands).

A worked example with numbers shows why the combination matters. Suppose you run three agents, each with 120 tests, and each test touches six tables. With truncation at roughly 40 to 60 milliseconds per test from the earlier report, cleanup alone costs 3 agents × 120 tests × 50 milliseconds, about 18 seconds per full run. With rollback at 2 to 4 milliseconds, cleanup drops to under 1.5 seconds. That difference compounds every time an agent reruns the suite after a fix, which in practice is many times per task.

The techniques layer rather than compete. Schema-per-branch separates agents; transaction rollback separates tests inside one agent's run; named fixtures give both a shared vocabulary; the reset script guarantees that every agent starts from the same known state.

The order of operations for one agent task is then fixed: record the base commit, create the worktree, create the schema or branch, run the reset, hand the agent its connection string, let it work, run tests under rollback, and delete the schema and worktree together. Record the base commit with git rev-parse HEAD so every workspace shares a known comparison point, and give each agent a bounded acceptance check that says what to run and what not to touch (Superset). Limiting each agent to a spec-scoped task with explicit file ownership is the other half of the coordination, because isolation prevents collisions during work but not incompatible changes at merge time (Augment Code).

Where multiple agents must agree on a shared contract, such as an API shape or a schema change, consider having them negotiate that contract before any of them writes code. The spec-first pattern routes proposals through a mediator so conflicts surface as disagreements about intent rather than as broken files (Spec-Driven multi-agent workflow). That is cheaper than resolving a migration conflict after three agents have each altered the same table.

When your agents need to generate or check data with a model as part of the test loop, such as classifying fixture records or generating edge-case rows, Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, so the seed tooling talks to one endpoint instead of several SDKs. Teams that want the setup work itself handled end to end, from worktree scripts to reset pipelines, can put a Quanta expert on the job through Quanta Experts.