DataGrip Query Console: Capture PostgreSQL Execution Plans

The Problem: A Query Slowed Down and No One Knows Why

A report that ran in two seconds yesterday now takes forty seconds. The application logs show the SQL, but not what PostgreSQL did with it. Opening a separate terminal to run EXPLAIN breaks focus, and copying plans between windows makes it hard to compare before and after.

Thesis: DataGrip's Query Console Can Capture and Compare Execution Plans Inline

DataGrip integrates PostgreSQL EXPLAIN output directly into the SQL console. You can run EXPLAIN (ANALYZE, BUFFERS) against a connected database, view the plan text in the results panel, and keep the output as a reference while you adjust indexes or rewrite the query.

Run an execution plan from the console

Open a query console attached to your PostgreSQL data source. Highlight the statement you want to inspect, then run EXPLAIN. DataGrip sends the command to the server and renders the plan text in the console output panel.

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT id, customer_id, created_at
FROM orders
WHERE created_at >= '2026-10-01'
ORDER BY created_at DESC;

Run this in the DataGrip SQL console, not in a shell. The database user needs SELECT access to the table and the EXPLAIN privilege, which is typically granted to any role that can read the table.

Worked Example: Confirming Whether an Index Is Used

Suppose the orders table has an index on created_at, but the planner still chooses a sequential scan. Run the EXPLAIN command above and look for these nodes in the output:

• Seq Scan on orders - the planner read every row
• Index Scan using orders_created_at_idx - the planner used the index
• Sort Method: external merge - the sort spilled to disk, which may indicate low work_mem

If the plan shows a sequential scan on a large table, test a targeted change in the same console:

SET enable_seqscan = off;
EXPLAIN (ANALYZE, BUFFERS)
SELECT id, customer_id, created_at
FROM orders
WHERE created_at >= '2026-10-01'
ORDER BY created_at DESC;

Setting enable_seqscan to off forces the planner to consider index paths for this session only. Compare the actual time in milliseconds between the two plans. If the index scan is materially faster, the missing or stale statistics may be the cause, and you can run ANALYZE orders in the console to refresh planner statistics.

Practical verification

After running EXPLAIN (ANALYZE, ...), check the first line of the plan output. It should show Planning Time and Execution Time. Execution Time includes the actual query work, so if the statement is a SELECT, running it is safe. If the statement is an UPDATE or DELETE, EXPLAIN ANALYZE will modify data.

Trade-Offs and Limitations

• EXPLAIN ANALYZE executes the statement. Do not use it on data-modifying queries in production unless you intend to apply the changes.
• Large plans with many joins can fill the console output and make the IDE feel sluggish while rendering.
• DataGrip's plan viewer is text-based for PostgreSQL; it does not generate a graphical plan diagram for every PostgreSQL version.
• Metadata fetching for very large schemas can slow down schema introspection, though this is separate from running EXPLAIN.

Closing: Make Plans Part of the Code Review

Copy the EXPLAIN output into a comment above the query in your migration or application code, or save it as a scratch file in DataGrip. When a query regresses, you have a baseline plan to compare against the current one. Enable EXPLAIN (ANALYZE, BUFFERS) for slow SELECT statements during investigation, and turn it off once you have confirmed the fix.