Recover Lost SQL Scripts in DataGrip with Local History

Problem: “I deleted a query I just wrote”

In a fast‑moving database project you often tweak or delete SQL scripts in the IDE. A typo, a copy‑paste error, or a sudden “undo” can erase a whole block of code. If you’re not using Git, SVN, or another external VCS, you may feel stuck. DataGrip’s Local History feature is a lightweight safety net that can recover lost code without a repository.

What Is Local History?

Local History is an IDE‑level change tracker. Every time you open, edit, or close a SQL file or run a query in the console, DataGrip writes a snapshot of the editor state to a local file store. The snapshots are time‑stamped and can be compared side‑by‑side with the current content. They live on the machine where you run DataGrip, not in a remote server.

• Automatic: no manual commits needed.
• Granular: you can revert a single line or the entire file.
• Persistent: snapshots survive IDE restarts until the retention policy expires.

How to Use Local History

1. Open a SQL file or a console window.
2. Right‑click anywhere in the editor and choose Local History > Show History. The History pane opens on the right side of the IDE.
3. The pane lists snapshots by timestamp. Clicking an entry opens a diff view showing changes between that snapshot and the current file.
4. To revert, right‑click the desired snapshot and select Revert. You can choose Revert Selection to restore only the highlighted lines.

For console queries, the process is identical: right‑click inside the console, choose Local History > Show History, then compare or revert.

Configuration and Limits

DataGrip stores snapshots in ~/.DataGrip/LocalHistory (Linux/macOS) or %APPDATA%\JetBrains\DataGrip\LocalHistory (Windows). The retention policy can be tuned under Settings > Appearance > System Settings > Local History:

Setting	Default	Recommended
Maximum size (MB)	200	500–1000 for active projects
Maximum age (days)	30	60 for long‑running scripts
Maximum number of snapshots per file	100	200 for heavily edited files

Concrete Example: Recovering a Deleted Query

Assume you just deleted a complex INSERT statement from orders.sql. Here’s how you restore it:

# 1. Open orders.sql in DataGrip
# 2. Right‑click → Local History → Show History
# 3. In the History pane, find the snapshot from "yesterday 14:32".
# 4. Click the snapshot to open the diff view.
# 5. In the diff view, locate the deleted block (marked with a minus sign).
# 6. Right‑click the block and choose "Revert Selection".
# 7. Save the file.

After step 6, the previously deleted INSERT statement reappears in the editor. The diff view shows the exact line numbers and context, so you can verify that nothing else got corrupted.

Trade‑offs and Limitations

• Local only – Snapshots are stored on your machine. If you switch devices or lose your hard drive, the history is gone.
• No schema tracking – Changes made directly to the database (e.g., via a CLI) are not recorded.
• Retention limits – If you delete many snapshots or exceed the size limit, older entries are purged automatically.
• Not a VCS – You still need Git or another system for collaborative branching, tagging, and long‑term archival.

Because of these constraints, use Local History for quick recovery of accidental edits, but treat it as a complement rather than a replacement for a full version‑control strategy.

Actionable Takeaway

Enable Local History, adjust the retention settings to match your workflow, and remember:

• Right‑click > Local History > Show History whenever you need to inspect or roll back a change.
• Use the diff viewer to confirm the exact lines you’re restoring.
• Keep an external VCS for long‑term safety and collaboration.

With these steps, you’ll rarely find yourself staring at an empty editor after a mistake. Local History gives you a safety net that’s always on, without the overhead of committing to a repository every time you tweak a query.