A database client always ends up accumulating surfaces: the connections sidebar, the active tab, the Query Library, the menu commands, the modal windows for federation, diffs, snapshots. Without a single entry point, every action requires guessing where it's tucked away. Global Search is QoreDB's answer to this problem: a single key combination (Cmd+K on macOS, Ctrl+K elsewhere) and a search field that indexes the app's main surfaces.
The implementation lives in a single React component, with no external command-palette dependency, and relies solely on local data. No network request, no third-party index, no connected mode. This choice is consistent with the rest of the product: everything that touches navigation stays inside the Tauri process on the user's machine.
A single keyboard entry point, several indexed sources
The shortcut is registered in the central ShortcutProvider, which guarantees that it works everywhere in the app, including when a SQL editor or a connection form has focus. When it opens, the palette shows the commands available in the current context plus the list of features. This deliberate behavior avoids the blank screen: a user who has just opened QoreDB immediately sees what they can do, even before typing.
As soon as text is entered, six sources are queried in memory: the commands (new connection, new tab, open the library, toggle the theme, etc.), the features (Notebook, Sandbox, Federation, Diff, Snapshots, Full-text search, ER Diagram, Virtual Relations), the saved connections, the favorite queries, the history of executed queries, and the items of the Query Library with their folders and their tags. Each source exposes substring filtering, without fuzzy matching. The trade-off is explicit: the search is predictable and fast, at the cost of a bit less tolerance for typos.
Sorting by intent, not by score
Results aren't ordered by a relevance score, but by intent category. The order is fixed in the code: commands first, then features, then connections, then favorites, then history, then Query Library. This choice avoids a classic pitfall of command palettes: seeing a history item rise above a structural action simply because the substring matches better. A developer who types conn wants to see the "New connection" command first, not an old query that contained the word connection in a comment.
The total number of results is capped at 15. This cap isn't a technical compromise, it's a UX choice: beyond it, the palette loses its promise of direct access to the right item. If a user sees 15 results and theirs isn't among them, they should refine their query, not scroll.
Rendering tailored to each type
Each result is rendered with an icon that signals its type at a glance: a chevron for a command, a compass for a feature, a database icon for a connection, a star for a favorite, a folder for a library item, a file for a history entry. Commands show their keyboard shortcut on the right, which serves as a reminder: the palette is also a way to learn the shortcuts without consulting the documentation.
Sections are visually separated only when the nature of the result changes, which avoids cluttering the display with headers for groups of a single item. The selected result follows both the mouse and the keyboard, with the up/down arrow keys to navigate, Enter to confirm, Escape to close.
How the palette integrates with the rest of the product
The palette doesn't handle action execution itself: it returns a typed SearchResult object (command, connection, query, favorite, library, feature) to a handler located in AppLayout. This handler decides what to do based on the type: open a tab, restore a connection, insert a favorite query into the editor, run a command. This decoupling lets plugins contribute their own commands through the contributions system, without the palette having to know their internal logic.
Contextual commands are generated on every render based on the current state. For example, the "Convert to notebook" command only appears if the active tab is a query, and "Close tab" only if there is an active tab. This approach preserves the promise of a short and relevant menu, without cluttering the user with actions they can't trigger.
In daily use
In the real workflow of a user with a few dozen connections and a history of several hundred queries, the palette quickly becomes the main interaction. A shortcut, three letters, Enter: you move from a staging connection to an exploration notebook and then to a recent query in under two seconds. The search field is reset on every opening, which avoids surprises tied to persistent state.
A random tip is shown at the bottom when the search is empty, drawn from a small list of translated suggestions (new query, sandbox, notebook, federation, shortcuts). This tip serves as progressive discovery of features: a user who opens the palette for the first time sees a useful reminder, without having to read an onboarding flow.
A central component, deliberately simple
Global Search doesn't try to be a general-purpose search engine. It doesn't index the contents of tables, doesn't dig through schemas, doesn't make suggestions based on learning. Its mission is to make the app navigable from the keyboard with minimal cognitive load. This simplicity is what keeps it predictable: the behavior depends on clear rules that the user can internalize within a few uses.
This approach suits a single-user desktop client: the indexed sources are bounded, fit in memory, and require no synchronization. QoreDB's Cmd+K remains a thin layer on top of existing components, and that is precisely what makes it an effective entry point for everything else in the product.
Stay updated on new releases
Subscribe to get product releases, new drivers notifications, and technical tutorials.