BroadSQLRun the same SQL query across multiple databases and environments
August 29, 2026 · Applies to BroadSQL 5.5.0, reviewed October 17, 2026
When you manage DEV, TEST, and PROD, or Postgres, Oracle, and SQL Server side by side, the query stays the same but the tool changes every time.
The problem: one GUI per vendor, one habit per environment
A typical data steward or support engineer doesn't work against one database. They work against several: different vendors, different environments, sometimes both at once. Most graphical SQL clients are built around a connection you pick once and stay in. Switching vendors usually means switching tools entirely, and switching environments means retyping (or copy-pasting, carefully) the same query somewhere else, hoping nothing was mistyped along the way.
The BroadSQL approach: named connections, one shell
BroadSQL keeps every connection, whatever the vendor and whatever the environment, in one encrypted connections vault (the CDF), each with its own short ID. Opening one is the same command regardless of what's on the other end:
CONNECT test_orders;
SELECT count(*) FROM orders WHERE status = 'PENDING';
CONNECT prod_orders;
/The second block doesn't retype the query at all. / re-runs the last SQL statement
exactly as it was last executed, against whichever connection is now open. A query you just
validated on TEST runs on PROD by changing one word (the connection name), not by re-entering SQL.
When your connections are organized in a Database Group with one
connection per Environment, you don't even need to switch: / PROD runs the last query once
on the PROD connection of the same Database Group, and you stay where you were. The example below is
from the connections guide:
SALES_QA> SELECT COUNT(*) AS FAILED FROM ORDERS WHERE STATUS = 'FAILED';
...
SALES_QA> / PROD
Running last query on SALES_PROD [PROD]...
...
SALES_QA>If the PROD Environment is flagged Production and the statement can change data, BroadSQL asks for confirmation before sending it; see Production confirmation.
Honest scope
This isn't a data-diffing or migration tool, and it isn't trying to replace a graphical client for exploring a single database. If you're getting to know a schema, browsing tables interactively, or building a query visually, a GUI does that better. Where BroadSQL earns its place is the parts of the job that repeat: the same investigation, the same extract, the same check, run again against a different target.
Who this is for
Data stewards, support engineers, and anyone whose day involves the same SQL running against more than one environment or more than one database vendor, regularly enough that retyping it is a real cost.
Get this set up on your team
I help teams set up BroadSQL's connections vault across their DEV/TEST/PROD estate and train the team on the shell so the same query really does run everywhere, safely. Fewer retyped queries means fewer mistakes reaching production, and a faster path for new team members to become productive across every environment. Get in touch.
Found something wrong or unclear on this page? Tell us, with the page address.