Recovering Lost SQL Logic with DataGrip Local History

The 'I Forgot to Save' Panic

Every database engineer has been there: you spend an hour refining a complex CTE (Common Table Expression) or a multi-join migration script in a console buffer, only to accidentally overwrite it, close the tab without saving, or realize the version you just executed was actually better than the one you have now. When these scripts aren't yet committed to a version control system (VCS) like Git, they often feel gone forever.

The solution is Local History. Unlike Git, which tracks intentional commits, Local History is an automatic, high-frequency recording of every change made to your SQL files and console buffers. It acts as a safety net that captures the state of your code every time you save a file or execute a query, allowing you to recover logic without needing a manual backup.

How Local History Differs from Git

It is important to distinguish Local History from a standard VCS. While Git tracks the evolution of a project across a team, Local History tracks the evolution of a file on a specific machine. It records changes in the background without requiring you to stage files or write commit messages.

• Automaticity: It triggers on file saves and query executions.
• Granularity: It captures minute changes that are often too small for a formal commit.
• Scope: It applies to both physical .sql files and the temporary buffers used in the Query Console.

Recovering a Lost Query: A Worked Example

Imagine you are optimizing a slow-running report. You have a working version of a query, but after several attempts to add window functions, the logic breaks and you can't remember the exact join condition that worked ten minutes ago.

Step-by-step recovery:

1. Access the History: In the DataGrip editor or the Database explorer, right-click the specific SQL file or the active Console tab.
2. Navigate: Select Local History → Show History.
3. Analyze the Timeline: A dialog appears showing a vertical list of timestamps on the left. Each entry represents a state change (e.g., "External change" or "Executed").
4. Compare Versions: Select a timestamp from the list. DataGrip opens a side-by-side diff viewer. The left pane shows the historical version; the right pane shows your current, broken code.
5. Restore Logic: Instead of reverting the whole file, you can click the >> chevron next to the specific lines of the working join condition to merge only those lines back into your current editor.

Configuration and Storage Risks

Local History is powerful, but it is not a permanent archive. Because it stores data locally in the IDE's system folder, there are specific limitations to keep in mind:

Limitation	Technical Impact	Mitigation
Local Storage	History is tied to the IDE profile, not the project folder. Moving the project to another PC loses the history.	Commit stable code to Git immediately.
Retention Period	The IDE purges old history based on a configured time limit to save disk space.	Adjust retention settings in Settings | Appearance & Behavior | System Settings | Local History.
Cache Clearing	Using "Invalidate Caches" may purge some local history data.	Ensure critical scripts are saved as files rather than just console buffers.

Verifying Your Safety Net

To ensure Local History is working as expected in your environment, run this quick diagnostic check:

1. Open a new Query Console.
2. Type a simple statement: SELECT 1; and execute it.
3. Change the statement to SELECT 2; and execute it again.
4. Right-click the console → Local History → Show History.
5. Verify that two distinct timestamps appear, reflecting the change from 1 to 2.

If the history appears, you have a functional recovery mechanism for your ad-hoc SQL development.