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
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!