Tools
SQL results and limits
Understand resident SELECT and UPDATE results, virtual windows, continuation, partial commits, topology, and bounded execution.
SQL Query keeps typed results and working state in memory. It does not use a temporary database or file spill. Redis work and result delivery are divided into bounded segments, so a large query can pause at a safe checkpoint and continue without imposing an arbitrary total key or row limit.
Result cell types
| Result | What Varc displays |
|---|---|
| NULL | An explicit NULL marker |
| Boolean | true or false |
| Integer | Exact decimal text, including values outside JavaScript’s safe integer range |
| Real | A Redis score or finite SQL real |
| Text | UTF-8 text |
| Binary | A bounded binary-safe preview with the exact total length |
| JSON scalar | JSON null, Boolean, string, integer, or real |
| Redis value | A bounded type summary backed by an opaque exact-value handle |
One Redis key remains one SQL row. Collections and RedisJSON documents are not flattened or eagerly copied into the grid. A collection cell normally contains a bounded summary and an opaque handle for opening the exact value through the existing Keys document viewer.
Rows that still represent one source key can open that exact binary-safe key. Grouped and aggregate rows are synthetic and do not expose an Open Key action.
Resident results and virtual windows
The SQL run owns one finite resident result. The shared grid asks that result for only the currently visible row range and formats only mounted cells. Scrolling one million logical rows does not create one million GPUI rows or entities, and changing progress or moving the tool does not clone the complete result.
Result-window identity belongs to one run and revision. Rerunning or releasing a result invalidates stale window and exact-value capabilities instead of merging data from different runs. A result remains available after cancellation or a safe pause until you release it, rerun the tab, close the tab, close the SQL tool, or close the workspace.
Query states
| State | Meaning | Available action |
|---|---|---|
| Ready | No statement is running in the tab. | Run or Explain |
| Running | Varc is discovering candidates, reading values, evaluating, or finalizing. | Cancel |
| Paused safely | One bounded segment ended at a resumable checkpoint; retained results remain readable. | Continue |
| Approval needed | UPDATE discovery and preflight completed; no write has started. | Approve or cancel |
| Complete | The source finished, or LIMIT ended work where the query semantics permit early stop. |
Run again |
| Cancelled | Work stopped at the strongest safe boundary; retained SELECT rows remain readable. | Run again |
| Failed | A typed SQL, connection, capability, topology, or resource failure stopped the run. | Correct the cause, then run again |
| Unknown outcome | An UPDATE may have been dispatched but its result cannot be proved by safe exact reads. | Inspect and resolve; do not replay |
Progress reports candidates examined and evaluated, rows retained and finalized, groups formed, missing or changed candidates, indeterminate values, collection items read, source bytes, and conclusive UPDATE outcomes. It does not expose Redis commands or internal cursor details.
Screenshot plannedPaused SQL results with ContinueThe SQL results table showing retained rows, progress counters, a paused status, and a Continue action.
Execution segments and product limits
Native SQL currently starts a SELECT segment with these internal work bounds:
| Boundary | Default | Purpose |
|---|---|---|
| Candidate identities examined | 1,024 | Reach a responsive pause or completion checkpoint |
| Collection items inspected | 4,096 | Bound collection work and in-flight payloads |
| String preview requested per row | 4 KiB | Avoid eager whole-value reads when a preview suffices |
These are segment and preview bounds, not total product ceilings. Choose Continue to process another segment. A valid large keyspace, million-row result, or 512 MiB Redis String is not rejected merely because it exceeds one internal batch.
The SQL source is limited to 1 MiB. Direct key IN (...) lookup accepts at most 1,000 constants, projections at most 256 expressions, ORDER BY at most 32 terms, and GROUP BY at most 32 terms. These language and source limits are separate from result size.
If resident working state cannot obtain memory, the run fails explicitly and preserves any previously retained result. Varc does not silently truncate the query, spill SQL truth to disk, or claim a partial sort or aggregate is globally final.
ORDER BY, DISTINCT, and aggregation
Without ORDER BY, matching rows may be emitted in traversal order and LIMIT can stop early when semantics allow it. ORDER BY and scalar DISTINCT retain candidates until traversal completes.
Aggregate queries traverse the complete candidate source. They then finalize grouping, HAVING, projection, ordering, and LIMIT before publishing the final rows. Finalization is supervised CPU work with cancellation checkpoints. A paused or cancelled global operation is never labelled complete, globally ordered, or globally distinct.
Plain EXPLAIN SELECT and EXPLAIN UPDATE allocate no query run and perform no Redis I/O.
UPDATE results and failure semantics
Before writing, UPDATE completes read-only discovery and evaluation. A key-changing Cluster statement also computes every exact destination and proves every source/destination pair is same-slot. Any cross-slot or indeterminate pair rejects the statement before the first write, with no override.
After single-use approval, each row is baseline-checked and atomically applied through the canonical Native mutation plane. The statement is not globally transactional. If an early row commits and a later row conflicts or fails, the earlier commit remains. The result reports committed and not-attempted rows truthfully; there is no statement-wide rollback.
A possibly-dispatched write is never retried automatically after a lost reply, timeout, reconnect, failover, or route change. Safe exact reads may resolve it; otherwise the run remains Unknown outcome. Every conclusive applied mutation is reconciled through the same Keys and document authority used by ordinary key edits.
An UPDATE with RETURNING publishes typed rows for conclusive committed values. Without RETURNING, the outcome reports affected-key counts. LIMIT counts selected update attempts, not successful commits or result rows.
Indeterminate and missing values
A value is indeterminate when Varc cannot safely prove its result—for example, the key changed type during evaluation. Indeterminate predicates are not silently counted as false. Keys that disappear or expire are counted separately.
A stable key of the wrong type follows the documented function result, such as NULL or false; a concurrent type race remains indeterminate.
Consistency and topology
Broad queries inherit Redis SCAN’s weak consistency. Keys can be added, removed, changed, or expire while a query is running. Varc deduplicates retained identities and reports races honestly, but it does not claim a transactional database snapshot.
- Standalone: scans the selected logical database.
- Sentinel: follows the current primary through the shared generation-aware DeploymentSession.
- Cluster: scans all current primaries, deduplicates exact keys, and uses database 0. A key-changing UPDATE is admitted only after the complete same-slot preflight succeeds.
TLS, mTLS, SSH, redirects, reconnects, and topology ownership are inherited from the existing workspace DeploymentSession. SQL has no separate transport, connection pool, topology map, or retry system.
Exact key = ... and bounded key IN (...) predicates can avoid a keyspace scan. Eligible key LIKE and canonical type predicates may narrow discovery without changing SQL byte semantics. RedisJSON functions require an actual compatible module; Varc does not claim them on a server where the module is unavailable.