# Can two coding agents use the same development database?

> Find which database each agent worktree really uses, choose shared or isolated state deliberately, and review competing migrations before integration.

Canonical HTML: https://canopyide.dev/guides/parallel-coding-agents-share-development-database
Article date: 2026-09-28

Two agents can edit different Git worktrees and still connect to the same development database. One agent's seed or migration may change what the other sees, so a green test can describe the wrong state. This guide uses a hypothetical profile-settings branch and billing-history branch to show when shared state is acceptable, when to isolate it, and how to bring the changes back together. A worktree separates files; the database endpoint, volume, and data need their own decision.

## Prove whether the agents share state

Before either agent runs a migration or mutating test, record the working directory, branch, service command, effective database host and database name or project reference. Compare nonsecret connection identifiers, not credentials. A different frontend port does not imply a different database. Check Docker Compose project names, published ports, named or external volumes, and any shared cloud development project. Git documents that worktrees are separate working directories attached to one repository; it does not provision a second database. In Canopy, the Servers panel can identify which process belongs to the task, but the app cannot infer that two connection strings reach separate data stores without your configuration and a live check.

- If both agents see the same disposable marker row, they share data; remove the marker after the check.
- If one agent must use a shared service, give it read-only work or schedule mutating tests sequentially.
- Never test isolation by writing a marker into production or an unapproved shared environment.

## Pick an isolation level that fits the work

For a static UI change against a stable API, sharing a read-only backend may be enough. For tests that insert, delete, reset, seed, or migrate data, use distinct databases or run one branch at a time. Separate schemas inside one server may still share roles, extensions, or configuration; verify what your tests actually touch. Docker Compose's project name is designed to distinguish copies of an environment, but it does not solve published host-port collisions or intentionally external volumes. Give each copy a distinct project name, port mapping, and database target, then verify the resulting container and volume identities. If you use a hosted service, check whether it offers true per-branch environments and what they copy; Supabase documents that its branches have separate database instances, API endpoints, Auth settings, and storage, while branch creation and migrations have their own rules.

*Choose from the smallest arrangement that protects the test result.*

| Task | Possible state setup | Evidence required |
| --- | --- | --- |
| Read-only UI work | One shared dev API | No writes or schema changes; both branches identify the same endpoint |
| Independent mutating tests | Separate local databases or branch environments | Distinct targets and seed data; tests do not alter the other branch |
| One local database available | Run migrations and mutating tests sequentially | Recorded order, reset plan, and clean baseline before each run |
| Related migrations | One integration owner and ordered migration review | Both migrations apply to a fresh baseline in the intended order |

## Keep migrations reviewable while agents work

For the example, let the profile agent own its profile migration and the billing agent own its billing migration. Each should say which schema objects it changes, what existing data it assumes, how it tested the migration, and whether the app works with the previous schema during rollout. Do not let both agents independently reset or push to the same remote development project. Supabase's local workflow keeps migration files in version control; its branch workflow applies committed migrations in order and can expose conflicts when branches combine. File isolation cannot guarantee schema compatibility: two separately passing branches can add conflicting constraints, duplicate columns, or incompatible policy changes. Review the SQL and combined order before any shared or production apply.

- Reserve one person or agent as integration owner for migrations that touch the same table or policy.
- Check generated migration filenames and contents, not just whether the files have different names.
- Test against representative existing rows as well as an empty database when data preservation matters.

## Run each branch and then the combined result

In Canopy, save the app, API, worker, and database commands with each checkout or component and verify their working directories, process output, and reported URLs. In each branch, run the same feature acceptance check against the database target recorded for that branch. For the profile task, save and reload a name, then confirm another account cannot edit it. For billing history, verify a user sees their own entries and not another user's. After reviewing and combining the code, create a clean integration database from the common baseline, apply both migration sets in intended order, seed approved test data, and repeat both journeys. An isolated branch test proves only that branch's assumptions; the integrated run tests whether those assumptions coexist.

- Record the checkout, commit, database target, migration set, run command, and result for each branch.
- Inspect the final diff and current PR checks after integration, not only the two agent summaries.
- Keep production migration approval with the designated owner and the project's deployment process.

## Clean up without deleting the wrong data

Stop the processes for the finished branch and identify its database, Compose project, and volumes before cleanup. A Compose down command with volume removal is destructive for that project, so use it only after checking the exact project and whether its data is disposable. External volumes and shared hosted projects may outlive a branch by design. Keep a short setup note with safe variable names, branch-to-environment mapping, migration order, and accepted result; do not put connection secrets into the PR or a public agent transcript.

## Copyable resources

### Two-agent database map

Record endpoint identifiers and test results, never database passwords or service-role keys.

````text
Task A / branch / worktree / commit: [ ]
Task B / branch / worktree / commit: [ ]
A app and database target (nonsecret identifiers): [ ]
B app and database target (nonsecret identifiers): [ ]
Compose project, host port, volume, or hosted branch for A: [ ]
Compose project, host port, volume, or hosted branch for B: [ ]
Shared state deliberately allowed? [what and why]
Mutating tests, seed, resets, and migration owner: [ ]
A feature check and database state: [ ]
B feature check and database state: [ ]
Combined migration order on clean integration state: [ ]
Combined feature and cross-user checks: [ ]
Cleanup target verified by: [ ]
Production apply owner and approval path: [ ]
````

## Frequently asked questions

### Do Git worktrees give coding agents separate databases?

No. They provide separate checked-out files and branch state. Connection settings, database instances, volumes, and data remain whatever your project configures.

### Is a different Docker Compose project name enough?

It distinguishes Compose project resources, but check host ports, bind mounts, external volumes, and connection strings. Those can still point two projects at the same state.

### Can I let two agents write migrations at once?

They can draft changes in separate branches and isolated test environments. Assign an integration owner to review overlapping schema changes and run both migration sets together before a shared or production apply.

### What if I cannot afford a second database?

Run mutating tests and migrations sequentially on a disposable database. Record the order and restore a known baseline between branch trials; avoid treating concurrent results as independent.

## Sources and further reading

- [Git: worktree documentation](https://git-scm.com/docs/git-worktree)
- [Docker: Compose project names and isolation](https://docs.docker.com/compose/how-tos/project-name/)
- [Docker: Compose named and external volumes](https://docs.docker.com/reference/compose-file/volumes/)
- [Supabase: local database migration workflow](https://supabase.com/docs/guides/local-development/database-migrations)
- [Supabase: branch isolation and migration behavior](https://supabase.com/docs/guides/deployment/branching/working-with-branches)
- [Canopy README: worktrees, Servers, and project context](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)

## Related Canopy pages

- [Is my local AI-built app using the production database?](https://canopyide.dev/guides/is-local-ai-built-app-using-production-database.md)
- [How do I stop two agent worktrees from using the same port?](https://canopyide.dev/use-cases/avoid-dev-server-port-collisions-with-worktrees.md)
- [Why a new agent worktree cannot build: env files and dependencies](https://canopyide.dev/guides/fix-missing-env-and-dependencies-in-agent-worktree.md)
- [Git worktrees for parallel coding agents: commands and cleanup](https://canopyide.dev/guides/git-worktrees-for-parallel-coding-agents.md)
- [Review an AI-generated Supabase migration before deployment](https://canopyide.dev/guides/review-ai-generated-supabase-migration-before-deploy.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.