Fork, Fix, Delete: Safe Database Migrations with GitHub Copilot and Tiger Cloud

A developer demonstrated a "Fork / Fix / Delete" workflow for safely tuning slow Postgres time-series queries without touching production, using GitHub Copilot Agent Mode paired with Tiger Cloud's MCP tools. The agent cloned the live service db-63453 into an isolated fork, ran EXPLAIN ANALYZE, converted the table to a hypertable, corrected timestamp columns to timestamptz and added time-based indexes, cutting a sample query from a 2.3s sequential scan to a 43ms index scan before the fork was deleted with production left READY.

A safe production workflow for fixing slow time-series queries without ever touching prod. The problem: Direct fixes on Postgres are risky. A bad index, a wrong type, or a long ALTER TABLE can lock production. My solution: Fork / Fix / Delete using GitHub Copilot Agent Mode + Tiger Cloud MCP. tiger create fork and cloned my live service db-63453 into db-63453-test isolated, same data EXPLAIN ANALYZE , converted the table to a hypertable, fixed timestamp types to timestamptz , and added proper time-based indexes. Also used Tiger's Dump & Restore for migrating tables. tiger delete service — fork gone, prod untouched and still READY . Who gets lazier? Any dev who is scared to touch prod DBs. The agent does the risky part in a sandbox. Final state — proof of Delete: My prod db-63453 is READY in US East, 29 days trial left. The fork db-63453-test is gone. Only 1 service remains. Monitoring after fix: Checkpoint logs are clean, no lock, fatal errors were just from the fork shutdown — expected behavior. Loom video: https://www.loom.com/share/48bb136113c14fa881559b259e4732c4 https://www.loom.com/share/48bb136113c14fa881559b259e4732c4 GitHub Repo: https://github.com/your-username/tiger-fork-fix-delete Key files: mcp.json — Tiger Cloud MCP + Docs MCP config .github/copilot-instructions.md — Time-series best practices hypertable, timestamptz, btree fix.sql — Before/After of slow query sql -- BEFORE: 2.3s sequential scan EXPLAIN ANALYZE SELECT avg value FROM sensor data WHERE time now - interval '1 day'; -- AFTER: 43ms index scan on hypertable SELECT create hypertable 'sensor data', 'time' ; CREATE INDEX ON sensor data time DESC ; postgres, ai, githubcopilot, database What's the worst production database incident you've ever accidentally caused, and how did you recover? Let me know in the comments below