Saved SQL queries

SQL tabs begin as session-only drafts. Varc writes SQL text to disk only when you explicitly save it, because query literals may contain sensitive keys or values.

Drafts and dirty tabs

New tabs use the first available Untitled-N name. The tab’s source, result state, and recent-query history live only in the current workspace-owned SQL tool session until you choose Save.

An edit that differs from the tab’s last saved or initial source marks the tab dirty. Closing a dirty tab offers three choices:

• Save writes or updates the query, then closes the tab.
• Don’t Save discards the local edits and closes the tab.
• Cancel returns to the editor.

Closing an unchanged tab does not show the prompt. Query results, progress snapshots, cursors, plans, and value handles are never part of a saved query.

Save a query

Choose Save. For an unsaved tab, enter a name and choose Save query. A saved tab adopts that name; later saves update the same record and clear only the exact saved source revision’s dirty state.

Names are trimmed and must contain 1 to 256 UTF-8 bytes. SQL source must be non-empty after trimming and may contain at most 1 MiB. A separate repository safety ceiling permits at most 10,000 saved-query records even when the plan allowance is unlimited.

Open and organise saved queries

Choose Saved queries in the SQL action bar. The library lets you:

• search names without changing the stored order;
• open a saved query in a new tab;
• move a query up or down; and
• delete a saved query.

Screenshot plannedSaved-query libraryThe Open query dialog showing searchable saved SQL queries with open, reorder, and delete actions.

Saved queries are scoped to the connection profile. Deleting that profile removes its saved queries. The record does not store a logical database: when opened, it runs against the database currently selected in the workspace. Redis Cluster remains on database 0.

Local storage and privacy

Saved queries are local to this machine in this release. They are excluded from Varc sync adapters. Recent queries are even shorter-lived: the SQL tool keeps at most 50 admitted executions in process memory and loses them when the tool session ends.

Varc never stores SQL results, resolved keys, execution plans, value handles, progress, or continuation state with the query. Review SQL literals before saving if they contain production identifiers or other sensitive text.

Allowances

SQL access and the saved-query allowance come from Varc’s canonical entitlement manifest. The SQL tool does not compare plan names or carry its own quota table. Creating a query consumes one unit from the current authority-issued allowance; updating an existing query consumes no additional unit, and deletion remains available after a downgrade. Varc rechecks the allowance transactionally before insertion and also enforces the independent repository safety ceiling.

If entitlement changes, saved queries, open source, and resident results are retained. Already admitted finite work reaches a safe truthful terminal, while new SQL and save admission is denied until the capability is available again. Re-entitlement never opens or runs a query automatically.

Conflicts and deletion

Saved records use optimistic revisions so two windows cannot silently overwrite one another. If another window changes or deletes the record first, Varc reloads the latest library and reports the conflict. Reordering uses the same revision checks.

Deleting a saved record does not close an already open tab. That tab becomes a local draft; save it again to create a new record if you still need it.