How the palette decides what to show

The palette makes three kinds of decision on every keystroke: which rows to show, in what order, and what a row is allowed to do. This page explains the rules behind them so the list stops looking arbitrary.

Why a short table name beats a long one that also matches

Every row has a name, hidden keywords, and details it already shows such as the profile and region. The name counts for most, keywords for a little less, and the visible details for about half. So east on a table named orders in us-east-1 is a weak match through the region, while east on a table named east-coast-orders is a strong match through the name, and the second row ranks first.

Inside the name, letters that start a word or run together outrank scattered letters. cre ranks Create table above Describe table because cre starts the first word of one and is spread across the other. A shorter name also scores slightly higher than a longer one with the same match, which is why a table’s own name is kept separate from its workspace and region rather than joined into one string: joined, a long scoped name would always lose to a short one.

A multi-word query is a set of independent matches. Each word must land somewhere on the row, but not in the same place, so orders east needs a row where one part matches orders and another matches east.

Why the row you used yesterday sits higher

The palette records every row you choose. Each record is a score that grows by one on each choice and halves every seven days, so ten choices last month weigh less than two this morning. When you type, that score adds at most a small fixed bonus to the text match. The bonus is enough for a command you use daily to beat a slightly better text match, and never enough for a poor text match to jump a good one.

A row you have not chosen for about three weeks ranks on text alone. With nothing typed, the score is all there is, which is why Recents and a lone prefix list your most used rows first.

Choices made in the palette count. Tables also count when you open them anywhere else in the app, because the dashboard already records those opens and the palette reads the same record.

Why some rows are missing rather than grayed out

A command that cannot run right now is not in the list. Close Tab is absent with no tab open. Delete rows is absent with nothing selected and absent on a read-only result set. Refresh results is absent unless a query tab is in front of you. The palette reads the app’s state when it opens and again when you press Enter, so a command runs against the tab that is active at that moment, not the one that was active when you started typing.

A row that is grayed out would sit in the list, take a keystroke to skip, and answer nothing when chosen. Absence is the honest version of the same fact.

The two exceptions are deliberate. A command behind a plan feature shows a lock and opens the upgrade page, because the fix is one click away. A command that needs a live session while the session has expired is replaced by the repair, because the fix is one click away too.

Why destructive rows are never first

A destructive row is one whose command deletes or discards something. In Recents and Suggested it sorts to the end of its group, and a group that would hold only destructive rows is left out. On a production table, or on one whose classification could not be read, destructive rows do not appear in the empty state at all. The number keys skip a destructive row rather than renumber past it.

The reason is the empty state. It shows before you have typed anything, so the first row is the one a stray Enter runs. Nothing that deletes belongs there.

Every destructive command asks before it acts, and the confirmation is the app’s own dialog wherever one exists, so deleting a table from the palette still means typing its name. Deleting rows is the one command that does not ask on the spot, because it stages the deletion into pending changes, and Commit pending changes asks before it writes.