Published: 2026-11-02

Does USE Switch the Database in SSMS, DBeaver, DataGrip and MySQL Workbench?

A USE otherdb statement always changes the database of the session it runs on. What differs between tools is whether the editor's next run goes to that same session, and whether the editor's database selector shows the change. SSMS, DBeaver, DataGrip and MySQL Workbench 8.0 keep one connection per editor (or per connection tab), so the next run uses the new database. DataGrip's schema switcher and Workbench's bold default schema follow the USE. DBeaver's selector does not by default since version 24.1.3 (July 2024), unless you turn on Refresh active schema after SQL execution. Microsoft does not document whether the SSMS Available Databases list follows. In Jam SQL Studio 1.5.8, a USE that succeeds on SQL Server or MySQL moves the tab’s database picker, and ALTER SESSION SET CURRENT_SCHEMA does the same on Oracle; versions 1.5.5 to 1.5.7 reset a USE when the run finished. PostgreSQL and SQLite have no USE. Each claim below links to the vendor’s documentation, issue tracker or source code, checked on 31 October 2026.

The short answer

“Next run” means pressing Execute again in the same editor without another USE. MySQL Workbench 26, which Oracle now offers in place of 8.0, is not in the table: we found no documentation of how its editor handles USE.

What USE changes, per database

In every engine that has it, USE changes a setting of the session, the server-side state of one connection. A GUI tool then decides which session your next run goes to.

• SQL Server. USE “changes the database context to the specified database” and “takes effect immediately”, so the statements after it in the batch run in that database (USE (Transact-SQL)). On Azure SQL Database, a USE that names a database other than the current one “doesn’t switch between databases, and error code 40508 is returned”; you connect to the other database instead.
• MySQL and MariaDB. “The named database remains the default until the end of the session or another USE statement is issued” (MySQL 8.4 manual).
• Oracle. There is no USE. ALTER SESSION SET CURRENT_SCHEMA = hr makes unqualified names resolve in hr; the setting “persists for the duration of the session” and does not change the session user or give any extra privileges (ALTER SESSION).
• PostgreSQL. There is no USE: a connection is made to one database. psql’s \c “establishes a new connection” (psql), and GUI tools switch databases by connecting to the other one. SET search_path changes schema resolution inside the current database.
• SQLite. No USE either; a connection opens one database file (plus any you ATTACH).

So the question for a tool is simple to state: is the editor’s next run sent on the same session? If it is, the USE still applies. If the tool hands each run a pooled connection and cleans it afterwards, it does not.

SSMS 22

An SSMS query window is connected to a server and holds that connection: the editor’s context menu has Disconnect, which “disconnects the current Query Editor from the server”, and the Available Databases list on the SQL Editor toolbar is described as “Change the connection to a different database on the same server” (SSMS Query Editor, updated September 2026). Because the window keeps its connection, a USE that ran in it applies to the window’s later runs and to no other window. An accepted answer on Microsoft Q&A puts it the same way: query windows are tied to a server connection, and you change the database from the drop-down.

Whether the Available Databases list itself switches to the database a USE selected is not described in Microsoft’s documentation, and we did not test SSMS 22 for this post, so the table leaves that cell open. On Azure SQL Database the question does not come up: pick the database in the list or in the connection dialog, because USE cannot switch there.

DBeaver

DBeaver opens a separate connection for each SQL editor by default, so each editor has its own session; DBeaver’s documentation says this “may allow you to have different execution context for each script”. The exceptions to that default include SQL Server with Azure Entra ID MFA, Redshift, Snowflake and BigQuery. If you set Open separate connection for each editor to Never, “DBeaver will use single connection”, and a USE in one editor applies to every editor of that connection (Separate Connections).

The editor’s database selector is a separate matter. The preference Refresh active schema after SQL execution makes DBeaver “read active schema contents after each execution”, so that “if a query or procedure changes the active schema, the schema objects are updated in the UI” (SQL Execution). Its default changed from on to off in a July 2024 commit, first released in DBeaver 24.1.3, and it is still off in the 26.2.3 source. A DBeaver team member explained the change in discussion #35822 (October 2024): “With this setting, DBeaver sends an additional query after each query execution. We decided that we shouldn’t do it by default.” The reporter in that thread confirmed with SELECT DATABASE() that the USE had switched the session while the picker still showed the old database.

So in DBeaver since 24.1.3, a USE works for the next run in the same editor, and the selector catches up only if you turn that preference on.

DataGrip

“For each query console, a database connection session is created automatically”, and consoles “can share a single session or use separate sessions” (Query consoles). The data source’s session control option chooses between Dedicated sessions (“Each new client creates a separate session”) and Single shared session (“A single session is shared across multiple clients, including introspection”) (Data Sources and Drivers dialog). With a shared session, a USE in one console applies to all of them.

The schema switcher in the console toolbar shows the session’s state. A JetBrains developer answered a 2018 report (DBE-6219, closed as Works as Intended): “What’s in the top right corner, that is current database of your current console (= connection).” An issue JetBrains filed in November 2024 for MySQL (DBE-22350) runs use schema_name_3; in a console and records as the actual result that the “IDE switches schema and runs queries but does not refresh Database Explorer”. So the switcher and the next run follow the USE; the tree on the left does not refresh. One open report to know about if you query SQL Server from a JetBrains IDE: DBE-16725 (2022.2, still Submitted), where a console switched its current database to master on execution.

DataGrip’s Switch schema option (Automatic, Manual, Disable) and Track databases/schemas creation and deletion are about the switcher and the schema list; the documentation does not connect either of them to USE.

MySQL Workbench 8.0

Workbench marks the session’s default schema in bold in the Navigator. Set as Default Schema “executes a USE schema_name statement so that subsequent statements without schema qualifiers are executed against this schema. This setting applies only to the query session” (Object Browser and Editor Navigator). A USE you type yourself moves the bold schema too: in the 8.0.47 source, the editor reads the session’s schema back after any statement it parses as USE and updates the Navigator (wb_sql_editor_form.cpp, cache_active_schema_name()).

All query tabs of one connection tab share one connection: “All query tabs in the same connection share the same transactions. To have independent transactions, you must open a new connection” (SQL Editor toolbar). The same goes for the default schema: a USE in one query tab changes it for the other tabs of that connection. The stored connection’s Default Schema field sets where a new session starts.

Oracle now offers MySQL Workbench 26.10.0 for download. Oracle’s announcement of Workbench 26 describes it as a rebuild on MySQL Shell that replaces 8.0, which gets no new releases. We found no documentation of how the new editor treats USE, so this section describes 8.0 only.

Jam SQL Studio: what changed in 1.5.8

Unless a transaction is open, Jam SQL Studio’s query tabs do not hold a connection of their own. Each run borrows a pooled connection for the tab’s connection and database, and when the run finishes, session state the run changed is reset before the connection goes back, so a SET or a temporary table from one tab never turns up in another tab (Query Editor → session settings). That is the right outcome for SET and temporary tables, and the wrong one for USE: someone who runs USE sales expects the next query to run in sales.

Versions 1.5.5 to 1.5.7 reset a USE with everything else and said so once per tab in Messages: Session settings from this run were reset when it finished. To work in another database, use the database picker.

From 1.5.8, the tab follows the USE:

• On SQL Server and MySQL, when a run contains USE, the tab’s database picker moves to the database the server reports once the run finishes, Messages shows This tab now runs in <database>., and the tab’s next run runs there. Other tabs keep their own database.
• On Oracle the picker selects a schema, so ALTER SESSION SET CURRENT_SCHEMA moves it the same way.
• The picker stays where it was when the USE failed or you stopped the run, so the 40508 error on Azure SQL Database leaves the tab where it was.
• It also follows inside an open transaction, in Auto, Manual and Smart mode, and the transaction stays open.
• On SQL Server, a USE anywhere in the script counts, also on a new line without a ; or inside IF / BEGIN … END. A database name that differs only in letter case is the same database: the picker takes the server’s spelling without a message.
• Results of a run that switched databases can’t be edited, because their rows may come from either database (which database a Save writes to).

Other session settings a run changes — SET, ALTER SESSION, SET ROLE, a temporary table — are still reset when the run finishes, and Messages still says so the first time it happens in a tab. To keep them across runs, use Manual transaction mode or a SQL Notebook. PostgreSQL and SQLite have no in-session database switch, so there is nothing for the picker to follow; choose the database in the picker.

How often it comes up: the 1.5.7 reset note

Before changing this, we counted how often the 1.5.7 note appeared. In Jam SQL Studio’s anonymous usage data for the 14 days to 31 October 2026, among usage sessions on version 1.5.7:

Read these as “changed session state in a query tab”, not as “ran USE”. The note fires when a run changes session state that does not carry over to the next run on a pooled connection: a USE, a SET that is not script boilerplate (SET NOCOUNT ON and the like don’t count), ALTER SESSION, SET ROLE, or a temporary table. Version 1.5.7 did not record which of these it was. Even so, roughly a third of the sessions that ran SQL Server queries, and more than four in ten on MySQL, ran into the rule at least once, which is why 1.5.8 makes the picker follow USE instead of explaining the reset. Version 1.5.8 also records which kind of change was reset, and when the picker followed a USE.

• Source. Jam SQL Studio’s anonymous in-app usage events, events from version 1.5.7 that arrived in the 14 days to 31 October 2026.
• Sessions. A session is the anonymous usage-session identifier, which in the desktop app is close to one per installation. A session counts for an engine when it ran at least one query on that engine, and as having seen the note when the note was shown at least once. The note is shown at most once per tab.
• Not collected. No SQL text and no database, schema or table names. Usage analytics can be turned off in Settings → Privacy; the privacy policy describes what is sent.
• Who is in the sample. Jam SQL Studio users. The shares describe this app, not SSMS or Workbench users in general. PostgreSQL (0 of 21 sessions) and Oracle (0 of 6) are left out of the table: the samples are small, and PostgreSQL has no USE.

Quick Answers

Q: Does USE change the database dropdown in SSMS?

A: Microsoft's documentation does not say. It describes the Available Databases list only as the way to change the query window's database. What is documented is that each query window keeps its own connection, so a USE that ran in the window applies to the window's later runs and not to other windows. On Azure SQL Database, a USE that names another database fails with error 40508; pick the database in the list or connect to it directly.

Q: Why doesn't DBeaver switch the database after USE?

A: Since DBeaver 24.1.3 (July 2024), the preference Refresh active schema after SQL execution is off by default, so the editor's database selector keeps showing the old database. The USE still changes the editor's session, and the next statement in that editor runs in the new database. Turn the preference on to make the selector follow; DBeaver then runs an extra metadata query after each execution, which is why it was turned off.

Q: Does DataGrip follow a USE statement?

A: Yes. The schema switcher in a query console shows the current database of that console's session, and a JetBrains-filed issue from 2024 records that after a USE the IDE switches schema and runs the following queries there. The Database Explorer tree is not refreshed. With the Single shared session option, all consoles share one session, so a USE in one console applies to the others.

Q: Does USE in one MySQL Workbench query tab affect the other tabs?

A: In MySQL Workbench 8.0, yes: the query tabs of one connection share a single connection, so a USE in one tab changes the default schema for all of them, and the schema shown in bold in the Navigator moves. Open a second connection for an independent session. Oracle now offers Workbench 26, a rebuild on MySQL Shell; we found no documentation of how its editor handles USE.

Q: Is there a USE statement in PostgreSQL?

A: No. A PostgreSQL connection is made to one database and cannot switch to another. In psql, \c opens a new connection, and GUI tools switch databases by connecting to the other one. Within a database, SET search_path changes which schemas unqualified names resolve to.

Q: Does USE switch the database in Jam SQL Studio?

A: From version 1.5.8, yes. On SQL Server and MySQL, when a run's USE succeeds, the tab's database picker moves to the database the server reports, Messages shows This tab now runs in <database>., and the tab's next run runs there. On Oracle, ALTER SESSION SET CURRENT_SCHEMA moves the schema picker. In versions 1.5.5 to 1.5.7 a USE lasted only until the run finished, and a note in Messages said so.

Q: How often do people change session settings in a query tab?

A: In Jam SQL Studio 1.5.7, over the 14 days to 31 October 2026, the note that a run's session settings were reset appeared in 31 of the 100 usage sessions that ran SQL Server queries (31%) and in 18 of the 42 that ran MySQL queries (43%). The note fires for a USE, a SET that is not script boilerplate, ALTER SESSION, SET ROLE or a temporary table, and 1.5.7 did not record which of them it was, so these are not counts of USE alone.

Summary

A USE changes the session, in every tool. SSMS, DBeaver, DataGrip and MySQL Workbench 8.0 send the editor’s next run on the same session, so it runs in the new database; in DBeaver with a single shared connection, DataGrip with a shared session and Workbench across query tabs, other editors get it too. DataGrip and Workbench move their database indicator, DBeaver does so only with Refresh active schema after SQL execution turned on, and Microsoft does not document what the SSMS list does. Jam SQL Studio 1.5.8 moves the tab’s database picker after a USE on SQL Server and MySQL, and after ALTER SESSION SET CURRENT_SCHEMA on Oracle, and keeps resetting the other session settings when a run finishes.

Last verified against Microsoft Learn (USE, SSMS Query Editor), the MySQL 8.4 and Workbench manuals and the Workbench 8.0.47 source, Oracle’s ALTER SESSION reference, the DBeaver documentation, source and GitHub discussions, and JetBrains’ DataGrip help and YouTrack on 2026-10-31.