Database Specialist Subagents

You get most of the value with both together, but each is useful alone:

• The MCP gives Claude the ability to actually read your schema and test queries — the biggest single quality lift for database code.
• The subagent adds a senior-DBA mental model on top: which indexes to reach for, how to interpret EXPLAIN, when to prefer MERGE over ON CONFLICT.

Alone, the MCP is a tool without a specialist. Alone, the subagent is a specialist without hands. Together, they behave like a DBA working with the database open.

Opus. DBA work is analytical, multi-step, and consequential — the wrong index choice can produce a silent 50x write-cost regression that takes weeks to detect.

The token cost delta between Sonnet and Opus is small relative to the cost of an unnoticed schema mistake. This is the same argument for /review-security using Opus: correctness matters more than routing efficiency.

Because they think in different units:

• DBA agent — query plans, tuples, buffers. What actually happens in the engine.
• ORM agent — schema files, migration conventions, generated types. What the abstraction layer produces.

A slow Prisma query needs both: the Prisma agent explains what SQL got generated, the DBA agent explains why that SQL is slow. Combining them into one agent produces a middling generalist; keeping them separate produces two sharp specialists.

Read-oriented plus MCP query tools. For postgres-dba:

• Read, Grep, Glob
• Bash(psql:*) — narrow psql access
• mcp__postgres__query, mcp__postgres__schema — MCP tools

Do not give it Write access to source files by default — a DBA agent should recommend schema changes, not implement them silently. Point it at a read-only MCP connection; for actual migration work, invoke migration-planner which has narrower write scope.

Yes, scoped to your migrations directory. That's the whole point — it produces up.sql and down.sql pairs plus a risk assessment.

Configure:

• Write(prisma/migrations/**)
• Write(migrations/**)
• Write(db/migrate/**)

Do not give it general Write access; a migration planner that can rewrite arbitrary source files is a bug factory.

It reads the database's own statistics:

• Postgres — pg_stat_user_indexes gives per-index scan counts.
• MySQL — sys.schema_unused_indexes.
• MongoDB — the $indexStats aggregation.

The analyst joins these stats with index size and estimated write cost to rank recommendations, so you see the highest-impact removals first.

Yes, and it works cleanly. Each agent's description names the database it specializes in, so Claude Code's auto-routing sends the right work to the right agent.

Give each a database-specific tool restriction so they can't cross into each other's territory. Common for full-stack projects where Postgres is the primary store, Redis is the cache, and MongoDB holds the event log.

Hooks fire regardless of who calls the tool. If you have:

• A PostToolUse hook that runs pg_format
• A PreToolUse hook that blocks CREATE INDEX without CONCURRENTLY on large tables

… they apply uniformly whether the SQL came from postgres-dba, migration-planner, or your main conversation.

This is the layered-defense pattern: agent for expertise, hook for enforcement, MCP for reality.

Yes, the underlying database is still Postgres or MySQL. Install the DBA agent for the actual engine.

On top of it, install the platform-specific MCP (Supabase's own, Neon's own, PlanetScale's own) rather than the generic Postgres/MySQL MCP — you get platform features (auth, branches, deploy requests) plus the standard SQL surface.

The DBA agent doesn't care whether the connection is direct or platform-mediated.

Just the DBA agent for your primary database, paired with the read-only MCP. That's it.

Skip the ORM agent, migration-planner, and index-analyst until the project is large enough that a wrong choice actually costs something.

As the project grows:

• Schema changes get consequential → add migration-planner.
• Queries slow down → add index-analyst.
• ORM patterns get complex → add the matching ORM agent.