Query Tabs

Open a table while the sidebar is on app and that tab keeps querying app, and its schema, for the rest of its life. Changing the database in the sidebar moves what the sidebar lists and where the next tab opens; it retargets nothing already open. The tab strip sits below the toolbar and lists only the current connection’s tabs. One tab, no strip. Tabs are named after the object they show. When two would draw the same name, both gain their database: two tables called orders become app.orders and staging.orders. A name nothing else uses stays short, and hovering names the database either way.

​

Tab types

Both stage cell edits as pending changes. A query tab does it only when its query is a SELECT from one table; joins, aliases, and schema-qualified names like public.users come back read-only. See Change Tracking.

​

Keys

Close Other Tabs, Close All Tabs, and Close Tabs for Other Databases ship unbound. Bind them in Settings > Keyboard under Navigation.

​

Preview tabs

Clicking a table opens it immediately in a preview tab, which the next click reuses. Double-click a table, or select it and press Return, to keep its tab: the next table then opens in one of its own, so double-clicking down a list gives you a tab each. Double-clicking a table already open switches to its tab. A preview tab’s title is italic, which marks the tab the next click takes over. The strip appears once a window holds more than one tab; from there, double-click a preview tab or choose Keep Open from its contextual menu to keep it. It holds its place in the strip, and the next table opens in a tab of its own. A preview tab turns permanent as soon as you sort it, filter it, or edit data, and a tab in any of those states is never replaced by a click. One still open at quit comes back permanent, and a table opened from Favorites is permanent from the start. Turn the behavior off in Settings > General > Tabs > Enable preview tabs.

​

Two tabs on one table

Open in New Tab, on the table’s contextual menu in the sidebar, opens a second tab for a table already open, and the two are independent: filter, sort, and page one without touching the other. Per-table filters are stored per table rather than per tab, so the one that comes back next time is whichever of the two you set last.

​

Closing tabs

Closing the last tab leaves the connection open on its empty state. Cmd+W again closes the connection; Keyboard Shortcuts has the rest of that cascade. Close Tabs for Other Databases takes only tabs opened against a database other than the one the connection is browsing now, never the tab in front of you, and never another connection’s tabs. On engines that switch schemas instead, such as BigQuery and Oracle, it reads Close Tabs for Other Schemas. Closing asks Do you want to save changes? when the tab holds unsaved cell edits, a .sql file that differs from disk, or staged structure, Create Table, or user and role changes. Save closes the tab once the save lands, except for user and role changes, where it opens the review sheet instead and leaves the tab open. Closing one tab selects it first, putting the work in front of you before you answer. A bulk close asks once, and Cancel stops the rest. Save writes what it can reach in every tab it is closing: their .sql files and their staged structure changes, plus everything in the tab on screen. Cell edits, Create Table drafts, and staged user and role changes can only be saved from their own tab, so those tabs stay open instead and the alert says so. Don’t Save closes all of them. A dot on the tab marks unsaved text or unsaved edits. It is deliberately wider than the prompt: a scratch query tab shows the dot and still closes without asking.

​

Reopening closed tabs

Cmd+Shift+T, or File > Reopen Closed Tab, brings back the last query or table tab you closed, with its SQL, cursor position, and database context. The last 20 are kept for 30 days, and deleting a connection deletes its closed tabs with it. Server Dashboard, Users & Roles, and structure tabs are not candidates. Pending cell edits are the one thing that does not come back: they are never written to disk, so Don’t Save on the close prompt is final.

​

Reordering tabs

Drag a tab along the strip to move it; the others slide out of the way as it passes their middle. Press Esc before letting go to put it back where it started. The new order is saved when you release, so a drag you abandon leaves nothing behind. Hold the drag near either end of the strip and the track scrolls under it, so a tab reaches a place that is not currently on screen. Right-click a tab for Move Tab Left and Move Tab Right, which move it one place at a time, dim at the ends of the strip, and are offered to VoiceOver as actions on the tab.

​

Moving a tab to its own window

Drag a tab down out of the strip, or right-click it and choose Move Tab to New Window, to open it in a window of its own. Both windows work on the same connection and the same session, so closing one leaves the other connected. The command dims for a window’s only tab, for a tab with a query or a table load still running, and while the connection is down. Move Connection to New Window, on the connections strip, moves a whole connection instead. Tabs with unsaved work stay put. A move carries the tab, not the edits pending in the grid or the ALTERs staged in the structure editor, so save those first and the command comes back.

​

Tabs that stop fitting

The strip keeps one row and scrolls it, the way every macOS tab bar does. Scroll over it with two fingers to reach the rest. Settings > General > Tabs > When tabs stop fitting switches to Wrap onto more rows, which lays the tabs out over as many rows as they need and grows the strip to match. Nothing is off screen, and the window has that much less room for the table below.

​

Switching tabs

Cmd+1 through Cmd+9 jump by position, Cmd+Shift+[ and Cmd+Shift+] step, and Window > Show Previous Tab and Window > Show Next Tab do the same from the menu bar. A tab scrolled out of sight is pulled back into view. Switching keeps SQL, cursor, results, scroll position, sort, filters, and pending changes. Loaded rows are the exception, and only in bulk. Background table tabs keep their rows up to a budget read from the Mac’s memory: two under 8 GB, three at 8 GB, five at 16 GB, eight at 32 GB or more, halved under memory pressure. Past that, the tabs you touched longest ago drop their rows and re-query when you return. Thirty table tabs cost one query on return, not thirty resident result sets.

​

Where a tab points

A tab is bound to one connection, database, and schema, and every query, refresh, filter, sort, structure read, and structure save it runs uses that binding. Switching tabs never changes the connection’s saved default database. To point an existing tab somewhere else, use the database picker in the query editor’s toolbar: it rebinds that one tab and reruns it. The window subtitle names the frontmost tab’s database, and its schema on engines that have one. That is how you tell two tabs on one connection apart.

​

What survives a restart

The tab set is written when you switch tabs, a second after you stop typing, and every 30 seconds otherwise, so a crash costs at most the last half minute. On relaunch only the frontmost tab runs its query; the others load the first time you switch to them, and one that fails shows the error inline. A connection that cannot be reached shows the driver’s error with Try Again, Manage Connections…, and Copy Details, and stays in the next session’s list. Whether the last session reopens at all is Startup Behavior.

​

Row limits

Table tabs page; query tabs stop at a row cap. Both limits, and what Fetch All does about them, are in Settings > Data.

​

From external clients

MCP clients list open tabs with list_recent_tabs, bring one forward by id with focus_query_tab, and open new ones with open_table_tab and open_connection_window. See MCP Tools for the schemas, and Raycast’s Recent Tabs command.

​

Related

• Connections strip for switching connection and for disconnecting
• Keyboard Shortcuts for every default binding