Last update messed up SQL consoles big time, any chance to revert?

Was about to create my own post on this issue. JetBrains guys, please provide a way back to the old way. You've totally mauled the DB plugin with this.

Hi Dmitry,

While Jump is working, I don't see any benefit compared to the old Scratches and Consoles, on the contrary (see bellow).

Why this change in the first place? What was wrong with Scratches and Consoles?

Moving ahead, couple of points:

1. Using Jump with the mouse is kind of hard, I have to select the data source then move all the way up to the toolbar. It should be available in the context menu. Remember I have 50+ data sources. I'm working on a 4K monitor. So I have a loooooong way to move the mouse for the data sources at the bottom of the list.

2. How do I rename/delete a query file?

3. Provided there is a (hidden) way to rename, can I use the same name for two different query files belonging to two different data sources?

4. “Select Opened file” button from the project view doesn't work for a query file.

Please consider offering the old way as an option to people who want it back. Don't kill it!!

Katy.

Hi Katy, 

Why this change in the first place? What was wrong with Scratches and Consoles?

You can find more about this redesign and the reasoning behind it in this blog post: https://blog.jetbrains.com/datagrip/2025/09/16/a-farewell-to-consoles/

TL;DR: Consoles, built on top of Scratch files, were unintuitive and hard to discover. It was often easier to create a new file than to find an existing one.

1. Using Jump with the mouse is kind of hard

You can use a hotkey (Shift + Command + F10 on macOS) on any database object to get the list of files attached to it.

In a few days, we will roll out a fix release with DBE-24535 Add a `query files` node to Database Explorer, which should make working with files even more convenient.

2. How do I rename/delete a query file? 

Now it's possible in a files tool window, but soon will be also avialable via Database Explorer.

You can rename files at any time using the Rename action: https://www.jetbrains.com/help/datagrip/rename-dialog-for-a-file.html

You can also adjust the naming pattern to fit your needs in Settings → Database → Query files → Template. For example, you can add $DATA_SOURCE$ (e.g., Query$DATA_SOURCE$) so each data source will have its own uniquely named query files.

To delete a file, simply select it and press Backspace.

3. Provided there is a (hidden) way to rename, can I use the same name for two different query files belonging to two different data sources?

No, currently you can’t. Could you please tell me more about your use case?

4. “Select Opened file” button from the project view doesn't work for a query file.

I wasn’t able to reproduce this so far. Could you share more details or raise an issue in YouTrack?

Please let me know if you have any more questions or suggestions, and thank you once again for your feedback!

Best regards,
Dmitry Romanov
Product Manager, DataGrip

Hi Dmitry,

About the article, there are some things that either do not fit the reality, are false or misleading:

A1: “Not part of the project. Consoles lived outside the project structure, even though users worked in a project in DataGrip.” That''s exactly what I need, to NOT be part of the project. Now you are throwing that away.

A2: “Difficult context switching. You couldn’t change the dialect, data source, or schema for a console file via the UI. If you wanted it to behave like a local file, you had to manually save or transfer it.” False: when opening a console file, at the top right there is the usual dropdown to select a data-source. It's been like that for as long as I've been using console files. Can't be easier than that.

A3: “Confusing name. The term query console didn’t communicate what the feature actually was, and we kept getting feedback that newcomers didn’t understand it.” Misleading: they could be renamed to user's desire, moreover, they could be renamed with the same name for different data sources. All in one place = mess. Why not have sub-folders there for each datasource?!

A4: “By default, query files are saved in the queries folder, which is located in the project folder.” Again false: in my case the queries folder is located inside .idea folder, which is a hidden folder, that is, not visible in the project folder. I did not touch that path.

Which begs the question: if I go in settings and change that path to something else, what happens with the existing query files? Do they get moved as well? If I have to move them manually, how is THAT not confusing?

1. A lot of people use the mouse extensively, so you do need to provide a user-friendly mouse-way as well.

2. See point 4. I can't locate the file to rename/delete unless you would have me go in the file explorer (see A4, queries folder inside .idea, not accessible in PhpStorm), manually scan the whole queries folder for a certain file and do the rename/delete outside PhpStorm. I have around 100 file as of now. So again, all in one place = mess.

3. We have a final step in our testing workflow where we do testing on individual customers' live DB, but on test data. So, I have a sql console called reset_test_data.sql which is duplicated for almost all of my 50+ DB sources containing the individual DB IDs of the records that need to be reset. We also have some tables that have customer specific names, so those scripts have even different table names. But they all do the same logical thing, reset the test data for a new round of tests. So yes, I need to have the same name for different data sources. And yes, they need NOT be part of the project as they are customer specific, not code base specific.

4. I opened a query file from DB explorer, then I opened the Project view and clicked the “Locate Opened file”. Nothing happens. Maybe because of A4?

People that are only doing development might be happy with your change. But nowadays those are rare, most are doing DevOps. And forcing those to have everything project based is just wrong, it's not DevOps, leading to quirks and difficulties. DevOps people do use multiple datasources, not just a DEV and/or a QA.

So again, don't kill the SQL Consoles, let them be. Whoever wants query files, should use query files. Whoever wants consoles, let them have those as well. Why would you remove a feature that's already in the code base and working? It's just mind boggling.

Katy

Thanks a lot for taking the time to write such a detailed comment, Katy. It really helps us understand where the changes feel misaligned with real workflows. I’d like to clarify a few points that might address some of the concerns.

A1. “Not part of the project”

Please treat query files as a new default, not a forced workflow. If you prefer working with files outside the project you can:

• Change the folder where query files are stored (Settings → Tools → Database → Query Files).
• Use Query Scratches, which behave exactly like other scratches in JetBrains IDEs:
  • They live outside any project.
  • They’re accessible from any project within the same IDE session (useful when you have global data sources).
  • They aren’t saved if left empty.

This keeps the “not part of the project” workflow fully possible.

A2. Data source switching

You are right that you could switch schemas within the same data source. But switching to a different data source wasn’t possible.

Also, when a data source was deleted, all consoles and their history tied to it were deleted as well. This created real data-loss situations. Query files avoid this problem because the file is not owned by the data source.

A3. Naming and folder structure

We understand the naming flexibility was useful, but for many newcomers “console” implied something like a command-line terminal, not a file stored somewhere. 

As for folder organization. The replacement is coming: DBE-24535 Add a `query files` node to Database Explorer. This will restore a familiar folder-like structure, but with much clearer behavior and discoverability.

A4. Default location of query files

The default location does differ between DataGrip and the Database plugin inside other IDEs (like PhpStorm). This is intentional and based on how these IDEs treat project configuration. And it's just a default, so you can change this any time.

If you change the path, DataGrip does not automatically move existing files. For now, manual move is needed.

Your example of workflow with many customer-specific databases is extremely helpful — thank you. Could I ask a few clarifying questions to better understand it?

• How are these SQL files executed in practice? Do you run them manually from the IDE during each test cycle?
• Are the differences mostly in parameters (IDs, table names, schema names)? Or do you maintain fully separate script files because the logic differs per customer?

If “Locate Opened File” is doing nothing, that’s not expected behavior. I can’t reproduce it, so please create an issue so the team can investigate.

Best regards,
Dmitry Romanov
Product Manager, DataGrip

Hi Dmitry,

This is getting ridiculous.

A1. “Not part of the project”

“This keeps the “not part of the project” workflow fully possible.” No, it doesn't. With Database Consoles a console is assigned to the corresponding data source and kept that way. A scratch file is just a file, not attached to anything, and again, all in one place, with no obvious and organized visual cue on who owns what. Try working with 100 sql files, all in the same folder. Impossible!! Not being able to have the same name, different data source, show stopper.

A2. Data source switching

What you see in my screenshot in the dropdown are datasources, not schemas. It's right there, with bolded text, at the top of the dropdown. Get your things straight.

A3. Naming and folder structure

The folder structure you are talking about is virtual, that is, not allowing duplicate file names. Useless to us. On DBE-24535 I can see that I'm not the only crying out for duplicate names.

Please understand: this change completely broke our testing flow. All SQL Consoles we have lost their data source upon upgrading to 2025.3, the top right dropdown has no selection now. On the next test cycle me and a couple of other colleagues will have to go over each one and reassign the correct data source … and keep our fingers crossed they will stay that way on the next upgrade. And hope you will not delete at some point the Database Consoles node from Project View. 

We need out-of-project files, attached to currently configured data sources and allowing duplicate names. Yes, we need Database Consoles!!

I keep asking and you avoid the answer: why can't these two features live together?! Why do you have to cut out Database Consoles?! It's old code, stable, functionality wise pretty much independent from the rest of the framework, maintenance effort should be close to nothing. Make Query Files the default but give the user a setting to switch to Database Consoles.

Katy

Hi Katy,

I completely understand that these changes may have disrupted your team’s workflow, and I’m really sorry for the frustration this has caused.

To be fully transparent: we won’t be returning to the old behavior. The redesign was intended to address long-standing UX issues, reduce complexity, and make the workflow more consistent, flexible, and maintainable across the product. Files and scratches now form the supported workflow, and this is the direction we’re moving forward with.

That said, we absolutely want the new workflow to support your needs. Could I ask you to take another look at the suggestions I shared and let me know:

• Would having a node with files attached to each data source help you organize your work more effectively?
• Regarding duplicate file names - is this something your workflow depends on (e.g., automation), or is it primarily a preference?

Thanks again for helping us.

Best regards,
Dmitry Romanov
Product Manager, DataGrip

Hi Katy,

You were absolutely right about everything. We will be rolling files and consoles redesign back in the upcoming bug-fix release (2025.3.1) across all IDEs this week, restoring consoles to their pre-migration state - both in the UI and on disk.

You can keep the query files created during or after the migration, move any needed ones into consoles, or delete them if you prefer. We will reintroduce the query files scenario later as a complementary option.

I sincerely apologize to you and all affected users for the inconvenience this change has caused. We’ll do our best to prevent issues like this in the future. Thank you again for bringing this to our attention! Your feedback was one of the key signals that helped us recognize that the direction we had chosen was far from optimal.

Best regards,
Dmitry Romanov
Product Manager, DataGrip

Wow, the best news I've heard in a long while. Frankly, we were exploring alternatives.

Thank you!!!

Katy.

This is commendable. Thank you for taking the time to consider our feedback. A true product owner actively listens to their users’ input.

Hi Dmitry,

Just upgraded to 2025.3.1, everything is back to normal.

Thanks again,

Katy.