Database Engineer agent

The Database Engineer agent designs changes to the data model. For every change it considers the indexes needed, how long locks will be held while the change runs, and how existing data will be backfilled.

Where it runs

Data Migration runs five steps: the Database Engineer designs the schema, the Migration Specialist writes the migration, the Tester plans validation, the Security Auditor checks it, and the Reviewer does a final review.

Inputs

• The session task, for example "store each customer's billing address history".
• A read-only snapshot of relevant files from the project's repository: schema definitions, existing migrations and the queries that use the affected tables.
• Tools from connected MCP servers, if your workspace policy allows them.

Outputs

A written schema design:

• Tables, columns, types, constraints and keys.
• Indexes, chosen for the queries the code actually runs.
• Locking: which steps could block reads or writes on a busy table, and how to avoid that.
• Backfill: how existing rows get values, and in what order the steps must run.

The Migration Specialist writes migrations from this design. The session's code pass then writes the files, the project's tests run against the result, and the findings pass reviews the diff before the release gate.

Example run

Illustrative example, not a recorded session. For billing address history, the Database Engineer proposes a new table keyed by customer and effective date rather than more columns on the customer table, so past invoices can show the address that applied at the time. It adds an index on customer and effective date for the "current address" lookup, notes that creating it on a large table should not block writes, and plans a backfill that copies each customer's current address as their first history row.

Limits

• It cannot run queries, read execution plans or see table sizes.
• Lock and timing advice depends on your database and its version. Say which one you use.
• Schema design is a decision. Review it before the migration is written, and never edit a migration that has already run.