Free for 30 days on Scale.Start free
Run10 steps3-7 days for a typical schema change; 2-4 weeks for a large data migration

Migrate a Postgres database without downtime

A non-trivial Postgres schema or data migration shipped to production with zero downtime, dual-write transition, verified backfill, and a rollback plan that's been tested.

Open in DockSee every step →

A non-trivial Postgres schema or data migration shipped to production with zero downtime

A non-trivial Postgres schema or data migration shipped to production with zero downtime, dual-write transition, verified backfill, and a rollback plan that's been tested.

Spin up an agent for the heavy lifting

Drafts each migration step (expand SQL, contract SQL, rollback SQL) and the corresponding application code changes.

10 steps, 13 official links, 3 agent prompts

Every external doc the agent needs to cite is pre-loaded into the workspace's Pointers table. No hunting for the right URL mid-draft.

What's inside

Pre-loaded so day one is execution.

5Surfaces
10Steps
3Agent prompts
13Official links
6Tools mapped
Surfaces
  • tableSteps
  • tableMigrations log
  • docMigration plan
  • docRollback plan
  • docStatus
See every step, link, and prompt
How the loop works

Your agent works. Dock shows you what happened.

Open this template and you get a workspace seeded with an agent prompt. Connect your agent — Claude via our MCP, Cursor, your own setup — and it reads, drafts, and posts updates as it goes. You watch Dock for the latest.

  1. 01

    Connect your agent

    Claim an agent invite at trydock.ai/agent-invites — your agent gets an API key scoped to this workspace. Paste the key into Claude Desktop, Cursor, or any MCP client.

  2. 02

    Your agent reads the workspace

    The agent prompt at the top of the workspace tells your agent its role, the cadence to follow, and the surfaces to update. No extra setup — open Dock and your agent already knows what to do.

  3. 03

    Watch Dock for the latest

    Your agent posts to the Status surface after every meaningful action — newest at top. Wire the workspace's webhooks to Slack or email to get pinged in real time.

Wire it up · Claude Desktop

Add Dock as an MCP server in 30 seconds.

{
  "mcpServers": {
    "dock": {
      "command": "npx",
      "args": ["-y", "@trydock/mcp"],
      "env": {
        "DOCK_API_KEY": "<paste from /agent-invites>"
      }
    }
  }
}

Drop into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on Windows / Linux. Restart Claude Desktop. Ask Claude:“Read trydock.ai/<org>/migrate-database-without-downtime and follow the agent prompt.”

Full MCP setup guideOther agent clients (Cursor, custom MCP)
FAQ

Common questions on this template.

When do I need expand-contract vs just ALTER TABLE?
Use ALTER TABLE directly only when the operation is fast + safe: ADD COLUMN nullable on Postgres 11+, CREATE INDEX CONCURRENTLY, ADD CONSTRAINT NOT VALID. Use expand-contract for anything that changes the meaning of an existing column, requires backfilling existing rows, or needs application code changes that can't ship simultaneously with the SQL. The rule of thumb: if the migration takes more than a few seconds OR requires app code coordination, do expand-contract.
How long should the dual-write phase last?
Minimum 24 hours to verify production-traffic dual-writes are correct. Typical 3-7 days for medium-importance data. For high-stakes data (billing, account info), 2-4 weeks is reasonable. The cost of dual-writes is small (extra column writes); the cost of premature contraction is unrecoverable data.
What's the most common zero-downtime migration mistake?
Three failures dominate: (1) ALTER TABLE with NOT NULL or DEFAULT on a large table on Postgres 10-, locking writes for hours. (2) CREATE INDEX without CONCURRENTLY, locking writes for the build duration. (3) Stopping dual-writes before reads have switched, causing silent data drift while the app reads stale data.
How do I roll back a partially-completed migration?
Each step has its own rollback. Rollback discipline: (1) During expand: just DROP the new schema additions. (2) During dual-write: revert the app deploy. (3) During backfill: stop the backfill; the new column has partial data but isn't read. (4) After read switch: revert the app deploy to read from old. (5) After contract: this is where rollback gets expensive — you need a reverse backfill new → old. Document each rollback path BEFORE starting; the rollback plan is non-optional.
Can my AI agents help with database migrations?
Yes, carefully. Agents are particularly useful for: scaffolding the expand SQL + rollback SQL, generating the backfill script with chunking + checkpointing, finding every read/write site of the affected column in the codebase, drafting the verification queries, monitoring lock waits + query latency during the migration. Do NOT auto-execute migrations with agents; humans gate every SQL run. The template ships agent prompts inline.
What about MySQL or other databases?
The expand-contract pattern is database-agnostic. The lock semantics differ — MySQL has long had online DDL via gh-ost / pt-online-schema-change; Postgres relies on careful use of CONCURRENTLY + the patterns in this template. The 10 steps map cleanly to any RDBMS. Adapt the SQL specifics; keep the discipline.
Related templates

More from Run

RunMixed
Launch on Product Hunt the right way

12-step plan from picking the launch date to shipping the post-mortem. Your agents draft the assets + run the 24-hour hunt log + flag every converting comment in real time.

RunMixed
Launch on Hacker News (Show HN guide)

10-step plan for landing on the HN front page with a Show HN. Real title rules, real comment-thread tactics, real survival guide.

RunMixed
Automate Instagram posting with your agents

10-step plan for a posting pipeline that drafts, queues, and ships 6-12 Instagram posts a week with agents drafting and a human approving.

Browse all Run templates →
Used by these teams · 1

Teams that run this template, with their full setup.

DevOps & SREUse case

Run incidents in the same place you write the postmortem.

War room doc, incidents table, postmortem library: one workspace. Agents timestamp status changes, draft the postmortem from the timeline, cross-reference past incidents on the same system.

Open the use case

Open it. Hand it to your agent. Ship.

One click mints a fresh workspace in your org with the template body seeded. Your agents, your team, your edits from there.

Open in DockBrowse all templates →

About this template

Curated by the Dock team at . Every template is a real shared workspace we run with our own agents before publishing.

Reviewed regularly by the Dock team. Each playbook step links to the upstream tool's official docs so we can re-verify the rules as platforms change.