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.
- FORK: Copilot called
tiger_create_forkand cloned my live servicedb-63453intodb-63453-test(isolated, same data) - FIX: Inside the fork, I reproduced the slow query. Used
EXPLAIN ANALYZE, converted the table to a hypertable, fixed timestamp types totimestamptz, and added proper time-based indexes. Also used Tiger's Dump & Restore for migrating tables. - DELETE: Verified with docs search via MCP, then ran
tiger_delete_service— fork gone, prod untouched and stillREADY.
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.
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
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!


Top comments (0)