DEV Community

Cover image for Fork, Fix, Delete: Safe Database Migrations with GitHub Copilot and Tiger Cloud
victormawira05-lgtm
victormawira05-lgtm

Posted on

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

What I Built

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.

  1. FORK: Copilot called tiger_create_fork and cloned my live service db-63453 into db-63453-test (isolated, same data)
  2. FIX: Inside the fork, I reproduced the slow query. Used 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.
  3. DELETE: Verified with docs search via MCP, then ran 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.

Demo

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.

Trial: 29 days left, $1,000 <br>
: db-63453 (Beta) — TimescaleDB Status Ready (green)Region: US East (N. Virginia)Service ID: e9nimjxigoCreated: 2 hours ago

Monitoring after fix:
Checkpoint logs are clean, no lock, fatal errors were just from the fork shutdown — expected behavior.

![monitoring]

Loom video: https://www.loom.com/share/48bb136113c14fa881559b259e4732c4

Code

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!
Enter fullscreen mode Exit fullscreen mode

Top comments (0)